SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsprioritize-backlog

prioritize-backlog

General & other

View repository

Updated 10-16 06:50

About this skill

Skill: Prioritize Backlog

Purpose

Evaluate a batch of backlog items in parallel using multiple value frameworks, surface disagreements between frameworks, and let the user make the prioritization decision and record the rationale.

Core Objective

Primary objective: Perform amandatory full re-evaluationon a batch of backlog items (ignoring current priority status), produce the user-confirmed new priority and priority_decision, and write them back to their respective backlog forms (multi-file directory or single file).

Success criteria(all must be met):

  1. ✅ Each item has scores from 4 frameworks (RICE / WSJF / MoSCoW / ICE)
  2. ✅ Disagreements between frameworks are explicitly surfaced (≥ 2 level difference triggers human decision)
  3. ✅ Each item's final priority is confirmed by the user, not an algorithm output
  4. ✅ Each item is written back to the priority_decision field (including a previous snapshot of the old value, for reviewing what was overwritten this time)
  5. ✅ Output a batch results table so the user can compare across items
  6. ✅ The report header declares the detected backlog form (multi-file / yaml-list / h2-yaml / table), and write-back is performed according to that form

Acceptance test: Can the reader directly see the new priority + decision rationale + overwritten old value from the backlog item's frontmatter / yaml block / table row, without cross-referencing the conversation?

Scope Boundaries

This skill is responsible for：

  • Automatically detecting the backlog form (multi-file directory / single-file yaml-list / h2-yaml / table) and readingallitems
  • Forcibly re-running RICE / WSJF / MoSCoW / ICE scoring for each item (ignoring the original priority and priority_decision)
  • Surfacing disagreements between frameworks
  • Capturing user decisions and writing them back according to the detected form (multi-file: modify frontmatter; single file: modify the corresponding yaml block / table cell)

This skill is not responsible for：

  • Creating new backlog items (use capture-work-items）
  • Promoting items into the roadmap (use promote-roadmap-items）
  • Scoring a single item (this skill is abatchworkflow; scoring a single item would lose comparability)
  • Archiving old evaluation history (only the previous single field is retained; if history is needed, the caller is responsible)

Handoff point: After scoring is complete, hand off to promote-roadmap-items for backlog → roadmap promotion.

Use Cases

  • capture-work-items Recommended to trigger after batch capture
  • Do a clean full re-evaluation of the backlog before a planning ceremony
  • After a strategy refresh, re-run directly at any point (no extra switch needed — the default is overwrite-style re-evaluation)
  • plan-next Large gaps output by capture enter scoring
  • Single-file backlogs (e.g., a lightweight project maintaining a backlog.md) can also be handled directly

Behavior

Phase 0: Read input and detect form

  1. Form detection (try in priority order, stop on first hit)

    Priority Form Detection condition
    1 multi-file docs/process-management/backlog/ or docs/backlog/ exists, and at least one *.md file contains artifact_type: backlog-item or priority: frontmatter field
    2 yaml-list Single-file docs/process-management/backlog.md or docs/backlog.md exists, frontmatter or top-level YAML contains items: array
    3 h2-yaml Same as single-file above, the body contains ## <title> heading immediately followed by yaml … code block
    4 table Same as single-file above, the body contains a Markdown table with Title and Priority(or equivalent columns)

    Prefer the project's custom path (if .ai-cortex/artifact-norms.yaml or docs/ARTIFACT_NORMS.md in backlog-item.path_pattern）。

    None matched → halt and report "no recognizable backlog form found", and suggest running capture-work-items。

    Mixed forms detected(both a directory and a single file) → by default use multi-file and inform the user in the report that the single file was ignored; do not dual-write, to avoid inconsistency.

  2. Read docs/project-overview/strategic-goals.md(used for WSJF's Cost of Delay judgment and MoSCoW's Must judgment).

  3. Enumerate all items(no longer filter priority: unset): the existing priority / priority_decision is shown only as an audit log,does not participate in new scoring, to avoid anchor bias.

  4. If total item count = 1 → halt and warn: "Scoring a single item loses comparability. It is recommended to score at least 2 items together. Continue?"

Stage 1: Multi-framework parallel scoring

For each item, compute simultaneously:

RICE

RICE = (Reach × Impact × Confidence) / Effort
  • Reach: number of people or instances affected (quantitative)
  • Impact: 1 (low) / 2 (medium) / 3 (high)
  • Confidence: 0-100% (confidence in the Reach × Impact estimate)
  • Effort: person-weeks

Map to priority levels:

RICE score Level
≥ 1000 P0
200-1000 P1
50-200 P2
< 50 P3

(The thresholds are default examples; projects may customize them)

WSJF

WSJF = Cost of Delay / Job Size
  • Cost of Delay = Business Value + Time Criticality + Risk Reduction / Opportunity Enablement
  • Job Size = relative effort (Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20)

Map to priority levels (by the current backlog's WSJF quantiles):

WSJF quantile Level
Top 10% P0
10-30% P1
30-70% P2
Bottom 30% P3

MoSCoW

Classify by commitment level:

  • Must: not doing it this cycle would severely block or violate compliance → P0
  • Should: doing it this cycle would significantly increase value → P1
  • Could: do it if there is time → P2
  • Won't: explicitly not doing it this cycle → P3

ICE

ICE = Impact × Confidence × Ease
  • Qualitative score of 1-10 per dimension
  • Impact: impact on strategic goals
  • Confidence: confidence in the estimate
  • Ease: ease of implementation (higher is easier)

Mapping:

ICE score Level
≥ 500 P0
200-500 P1
50-200 P2
< 50 P3

Stage 2: Surface disagreements

For each item, computemaximum disagreement across frameworks：

Disagreement level gap Handling
≤ 1 level (e.g., P1 vs P2) By default use the RICE result, no human decision needed
≥ 2 levels (e.g., P0 vs P3) Explicitly surface it; human decision is required

The disagreement threshold can be customized per project (default 2 levels).

Stage 3: Present batch results

Output format:

## Batch Scoring Summary

| # | Title | RICE | WSJF | MoSCoW | ICE | 分歧 | 建议 |
|---|---|---|---|---|---|---|---|
| 1 | ... | P1 | P1 | Should | P2 | 1 级 | 自动采 P1 |
| 2 | ... | P3 | P1 | Could | P3 | 2 级 | **需人工** |
| ... |

## 需人工决策的条目（分歧 ≥ 2 级）

### Item #2: <title>

- RICE=P3 理由：Reach 仅 10 人、Effort 8 周
- WSJF=P1 理由：Q3 里程碑依赖本项，Cost of Delay 高
- MoSCoW=Could
- ICE=P3

**分歧焦点**：时间敏感性（WSJF）vs 规模（RICE）

**请决策**：P? 理由？

Phase 4: Capture decisions and write back (dispatch by form)

For each entry:

  1. Determine the final priority(auto-adopt or user input).

  2. Construct the priority_decision field content,must include previous：

    priority_decision:
  final: P<N>
  previous: P<N> | unset
  frameworks:
    rice: P<N>
    wsjf: P<N>
    moscow: Must | Should | Could | Won't
    ice: P<N>
  rationale: <one-sentence reason if disagreement was ≥ 2 levels>
  decided_by: auto | user
  decided_at: <ISO date>

  3. Write back by form：

    Form Write-back method
    multi-file Update the *.md frontmatter of each file's priority + priority_decision
    yaml-list Modify the items[i].priority + items[i].priority_decisionin a single file, preserving YAML indentation and key order
    h2-yaml Replace the yaml within the code block corresponding to that entry's priority + priority_decision, preserving the code block position
    table Update the table Priority cell;priority_decision write to the ## Priority Decisions subsection below the table, listed by entry anchor

    Before writing back, confirm: the old value has been recorded in priority_decision.previous, to avoid being silently swallowed.

Phase 5: Output the final report

The report header must include:

  • Backlog mode: multi-file | yaml-list | h2-yaml | table
  • Re-scored items: N (含 X 条覆盖了原 priority；Y 条原为 unset)

Report body:

  • Total processed, auto-decision count, manual decision count
  • Distribution statistics for each priority
  • Suggested next steps (e.g., promote-roadmap-items batch promotion)

Input & Output

Input: see frontmatter input_schema — backlog directory, strategic-goals.md, optional threshold overrides.

Output: conversation batch scoring table + each backlog file's frontmatter updated (priority and priority_decision fields).

Restrictions

Hard Boundaries

  • Force full re-evaluation: by default, overwrite all entries' priority and priority_decision, with old values retained only as the previous single field, without historical archiving (maintain the skill's single responsibility; archiving is the caller's responsibility)
  • Do not mix forms: once multi-file is detected, do not scan single files, and vice versa, to avoid double-write inconsistency
  • Do not automatically aggregate multiple frameworks into a single score (preserving divergence signals is the core value)
  • When divergence ≥ threshold, a manual decision is required; do not fall back to a default
  • Do not create new backlog entries (that is the responsibility of capture-work-items )

Skill Boundaries

Not done (handled by other skills)：

Action Owner
Create new backlog entries capture-work-items
Promote backlog entries into the roadmap promote-roadmap-items
Task breakdown AgentFabric runtime (outside AI Cortex scope)
Detailed requirement records capture-work-items

Anti-Patterns

  • ❌ Do not take a weighted average of the four framework scores — aggregation equals losing divergence signals and undermines the core value of this skill
  • ❌ Do not score a single entry independently — without a comparison group, the relativity of RICE / WSJF fails
  • ❌ Do not hide divergence — even if RICE is auto-adopted by default, still show each framework's score in the report table
  • ❌ Do not ignore strategic_goal_id — strategic goals determine the Must judgment in MoSCoW
  • ❌ Do not use vague wording("probably", "maybe") write priority_decision.rationale — must specifically cite the framework or data
  • ❌ Do not, during re-evaluation, "compare whether the old priority is reasonable before deciding whether to overwrite" — this amounts to adding anchoring bias to framework scoring, violating this skill's design intent of "mandatory clean re-evaluation"
  • ❌ Do not discard the old value —— priority_decision.previous must be written; let the user see in one place what was changed this time
  • ❌ Do not attempt to dual-write between the two forms — choose one of multi-file or single-file to avoid data drift

Self-Check

  • has declared the backlog form (multi-file / yaml-list / h2-yaml / table) and written back according to the form
  • halted when form detection failed, and guided capture-work-items
  • scanned all entries, old priority is only for display and does not participate in scoring (no anchoring bias)
  • ran all 4 frameworks for each entry
  • entries with divergence ≥ threshold were surfaced, and manual decision was required
  • entries with divergence ≤ threshold automatically adopted RICE, but scores from each framework are still visible
  • each entry priority_decision written back, including frameworks results, rationale (if divergent),previous old value snapshot
  • batch summary report includes Backlog mode, coverage statistics, priority distribution, next-step recommendations
  • did not automatically call promote-roadmap-items

Examples

Example 1: Full re-evaluation of a multi-file backlog (mainstream scenario)

Input：docs/process-management/backlog/ 5 entries under , mixed states — 3 priority: unset, 1 priority: P2(old), 1 priority: P3(old).

Form detection: hit multi-file。

Output summary：

Backlog mode: multi-file
Re-scored items: 5 (含 2 条覆盖了原 priority；3 条原为 unset)

## Batch Scoring Summary

| # | Title | 旧 | RICE | WSJF | MoSCoW | ICE | 分歧 | 建议 |
|---|---|---|---|---|---|---|---|---|
| 1 | 支付 API 响应时间优化 | unset | P1 | P1 | Should | P1 | 0 级 | **自动 P1** |
| 2 | ARTIFACT_NORMS 格式升级 | P3 | P3 | P3 | Could | P3 | 0 级 | **自动 P3（与旧值一致）** |
| 3 | Q3 支持多币种 | unset | P2 | P0 | Must | P2 | 2 级 | **需人工** |
| 4 | 登录错误 500 修复 | P2 | P1 | P2 | Should | P1 | 1 级 | **自动 P1（覆盖旧 P2）** |
| 5 | 新增技术债：重构 auth 模块 | unset | P3 | P2 | Could | P2 | 1 级 | 自动 P3 |

## 需人工决策：Item #3
（同前略）

Write-back result snippet(Item #4, the overwritten entry):

priority: P1
priority_decision:
  final: P1
  previous: P2
  frameworks:
    rice: P1
    wsjf: P2
    moscow: Should
    ice: P1
  decided_by: auto
  decided_at: 2026-04-17

Example 2: Single-file backlog (h2-yaml form)

Input：docs/backlog.md maintains a "lightweight backlog", where each entry is an H2 heading + inline yaml block:

## 支付 API 响应时间优化
```yaml
strategic_goal_id: goal-1
priority: P2

Reason: …

Login error 500 fix

strategic_goal_id: goal-1
priority: unset

…


**形态探测**：multi-file 路径不存在 → yaml-list 不命中 → **命中 `h2-yaml`**。

**写回方式**：替换每条对应的 yaml 代码块内的 `priority` + `priority_decision`，保留代码块外的描述正文不变；`priority_decision.previous` 写入旧值（一条原为 P2，一条为 unset）。

报告头：`Backlog mode: h2-yaml`、`Re-scored items: 2 (含 1 条覆盖了原 priority；1 条原为 unset)`。

---