Triaging Board

triaging-board

This is the Producer's triage routine. It scans Blocked cards (3-class blocker remediation) and stale claim branches (>72h flag; >7 days release recommendation), then recommends or takes unblocking actions.

Required sub-skills:

• board-superpowers:board-canon — state machine; Blocked status semantics; WIP counting.
• board-superpowers:operating-kanban — dispatch the read_board protocol action (with status filter Blocked), release_claim for stale-claim cancellation, and transition_card for Blocked → In Progress unblock; resolves the active projection from settings.
• board-superpowers:composing-siblings — consult before any sibling-plugin handoff (rare in triage; included per mandatory declaration).
• board-superpowers:classifying-actions + board-superpowers:auditing-actions — applied at every mutating action in this routine.

Overview

The triage routine answers two questions:

1. What is blocked and why? — for each Blocked card, classify the blocker (external-dependency / decision-pending / stale-block) and recommend an action.
2. What is stale? — for each claim branch older than 72h with no progress, flag or recommend release.

This routine does NOT resolve blockers itself (except stale-block, which is a simple Status flip). Architecture decisions go back to intake; external dependencies get surfaced to the Producer for status check.

The triage routine is the board's health check: it surfaces problems and recommends remediation paths, but the Producer makes the actual decisions. No card transition or branch delete happens without explicit approval.

Step 1 — Scan Blocked cards

Invoke board-superpowers:board-canon to load the Blocked status semantics. Then invoke board-superpowers:operating-kanban with action read_board and status filter Blocked. This returns only Blocked cards.

For each Blocked card:

1. Read the card body. Find the blocker (per board-superpowers:board-canon § state machine, Blocked entries name their blocker in a card comment or in the card body Notes section).

2. Classify the blocker per the 3-class schema:

   • External-dependency (waiting on another team / service / vendor / external PR): Keep blocked. Surface to the Producer for a status check or escalation decision.
   • Decision-pending (architect needs to decide something before the Consumer can continue): Surface to the Producer for an explicit decision. If the decision maps to a fresh requirement, route to board-superpowers:intaking-requirement.
   • Stale-block (the blocker resolved long ago but the card was never moved back): Unblock. Propose the transition Blocked → In Progress and wait for Producer acknowledgement.

3. Report the classification and recommended action.

See references/triage-detail.md for blocker detection mechanics and the stale-block evidence criteria.

Step 2 — Scan stale claim branches

List all claim/N-... branches on origin:

git branch -r --list 'origin/claim/*'

For each branch, compute age and progress:

# Age since first commit (or branch creation):
git log origin/<branch> --not main --format="%cr" | tail -1

# Progress: count commits beyond the initial claim marker:
git log origin/<branch> --not main --oneline | wc -l

Interpretation:

• Count = 0 or 1 (empty claim or initial marker only): branch is stale.
• Age > 72h AND count ≤ 1: flag with warning.
• Age > 7 days AND count ≤ 1 AND the original Consumer was previously notified: recommend release.

Surface the flagged list to the Producer.

Step 3 — Recommended actions

For each item in the triage output:

Step 4 — Stale-claim release procedure

If the Producer approves a release, apply the 5-step governance sequence (action_id = 8 — cancel claim). Then:

git push origin --delete claim/<N>-<slug>

And transition the card Status: In Progress → Ready via operating-kanban transition_card action (separate mutating action, action_id = 7).

Both actions — branch delete AND status transition — must be covered by separate audit entries. See references/triage-detail.md § "Claim release procedure" for the exact shell command sequence and error handling.

How mutating actions are handled

Every mutating action this skill performs (Status transition, branch delete) follows the 5-step governance sequence:

At each mutating action point:

1. Resolve the action_id (from board-superpowers:classifying-actions references/action-id-catalog.md).
2. Invoke board-superpowers:classifying-actions with that action_id; receive A (auto), R (requires approval), or N (forbidden).
3. If A: act → invoke board-superpowers:auditing-actions to record one entry.
4. If R: a. Invoke board-superpowers:auditing-actions to record the proposal. b. Surface the proposal to the Producer. c. Wait for the Producer's reply (approve / decline). d. On approve: act → invoke auditing-actions to record the result. e. On decline: invoke auditing-actions to record the decline; abort.
5. If N: refuse the action and surface the block reason; no audit entry.

Typical autonomy class for this routine:

• Status flip Blocked → In Progress (stale-block) → R-class.
• Stale-claim release (branch delete + Status flip to Ready) → R-class.

Summary format

## Triage summary — <YYYY-MM-DD>

### Blocked cards (<count>)
- #<N> <title> — <blocker class>: <one-line>. Recommended: <action>

### Stale claims (<count>)
- #<N> <title> — <age>, <commit count> commits. Recommended: <action>

If nothing is blocked or stale: "Triage clean — no Blocked cards, no stale claims. Board health is good."

Sibling-plugin handoffs in this routine

The triage routine has two sibling-plugin handoff points. Both go through board-superpowers:composing-siblings before routing.

Handoff 1 — Decision-pending blocker that needs investigation

When a card's blocker is classified as decision-pending AND the blocking question is technically complex (e.g., "we don't know which cache invalidation strategy is correct"), the Producer may need systematic investigation help before making the decision.

1. Invoke board-superpowers:composing-siblings with the "technical investigation" intent to confirm sibling routing.
2. Surface the routing decision: "Card #'s blocker is a technical decision ('which cache strategy?'). Routing to gstack:/investigate for a structured investigation."
3. Route to gstack:/investigate with the blocking question and relevant context (the card body, the blocked card's spec pointer).

After gstack:/investigate completes with a recommendation, re-enter triage at Step 1: the decision is now available, the blocker may have resolved to a stale-block or a new intake requirement.

Handoff 2 — Decision-pending blocker that generates a fresh requirement

When the decision-pending blocker surfaces a new design requirement (e.g., "we need to decide on the schema before this card can proceed"), route it to intake rather than investigate:

1. Invoke board-superpowers:composing-siblings with the "new-requirement" intent.
2. Surface: "The blocking question for # is a new requirement. Routing to board-superpowers:intaking-requirement."
3. Route to board-superpowers:intaking-requirement with the new requirement as input. The blocker card stays in Blocked status until the intake requirement's card lands and is addressed.

Autonomy defaults for this routine

Both the branch delete and the status flip are proposed together as a single R-class unit — do NOT propose them separately. The Producer approves or declines the pair as one atomic action.

Failure modes

What this triage routine does NOT cover

Per design, this routine focuses on Blocked + stale-claim sweep. It does NOT:

• Backlog grooming (rotating items between Backlog and Ready).
• Cross-card dependency cycle detection.
• Estimate calibration (S/M/L drift).
• Velocity tracking.

Those are out of scope. See references/triage-detail.md for the full list with rationale. The triage routine is intentionally narrow; scope creep degrades its speed and reliability as a health-check primitive.