Triage

Move requests through a small state machine of triage roles. Read planning artifact contracts and Work Tracker context assembly before acting. Preserve standalone behavior when the configured Work Tracker or Domain Orientation bindings do not exist.

If this repository treats external Review Proposals as a request surface (see the Work Tracker binding), triage applies the same roles and states to those proposals, with the differences marked below. Resolve a bare #42 through the configured binding rather than Git-remote inference.

Every comment or request posted to the Work Tracker during triage must start with this disclaimer:

> *This was generated by AI during triage.*

Reference docs

• Read AGENT-BRIEF.md when drafting or validating a brief.
• Read OUT-OF-SCOPE.md when matching or recording a rejected concept.

Roles

Two category roles:

• bug — something is broken
• enhancement — new feature or improvement

Five state roles:

• needs-triage — maintainer needs to evaluate
• needs-info — waiting on reporter for more information
• ready-for-agent — fully specified, ready for an AFK agent
• ready-for-human — needs human implementation
• wontfix — will not be actioned

For a Review Proposal, the same states read against the attached code: ready-for-agent means a brief is attached and an agent should take the next step on the diff; ready-for-human means it's ready for a human to merge.

Every triaged request should carry exactly one category role and one state role. If state roles conflict, flag it and ask the maintainer before doing anything else.

These are canonical role names — the actual Routing Label strings used in the Work Tracker may differ. Use docs/agents/triage-labels.md when present; ask the maintainer to run the applicable setup skill if no mapping has been configured.

State transitions: an unlabeled request normally goes to needs-triage first; from there it moves to needs-info, ready-for-agent, ready-for-human, or wontfix. needs-info returns to needs-triage once the reporter replies. The maintainer can override at any time — flag transitions that look unusual and ask before proceeding.

Requests

Interpret the maintainer's natural-language request and act. Examples:

• "Show me anything that needs my attention"
• "Let's look at #42" (request or Review Proposal)
• "Move #42 to ready-for-agent"
• "What's ready for agents to pick up?"

Show what needs attention

Query the configured Work Tracker and present three buckets, oldest first:

1. Unlabeled — never triaged.
2. needs-triage — evaluation in progress.
3. needs-info with reporter activity since the last triage notes — needs re-evaluation.

When Review Proposals are in scope, include external proposals in these buckets and tag each line [proposal] or [request]. Discovery surfaces only external proposals (the Work Tracker binding defines who counts as external) — a collaborator's in-flight proposal is not triage work. This filter is discovery-only; an explicitly named proposal is always triaged regardless of author.

Show counts and a one-line summary per item. Let the maintainer pick.

Triage a specific request or Review Proposal

1. Gather context. For Work Tracker delivery work, invoke the shared Context Assembly contract with the Ticket Origin Repository, Delivery Context, and the exact request's permanent reference. Retain the returned file path unchanged. At this clarification boundary, use the diagnostics in an Incomplete file only to diagnose, reject, or repair the request. It may end in needs-info or wontfix, but it cannot enter an execution-ready state until a fresh post-brief assembly passes. Ambiguous stops for maintainer direction. Triage does not repeat provider reads outside the binding-directed assembly.

   For a Review Proposal, read its full body, comments, review state, and diff through the configured request surface. Resolve the exact authority under review through an explicit permanent reference and invoke shared Context Assembly for the contract-selected review profile. Follow any non-complete result at this triage boundary. Retain the selected profile and root for outcome validation.

   Parse prior triage notes so you don't re-ask resolved questions. After the applicable Context Assembly gate, perform configured Domain Orientation before exploring canonical contexts, accepted Domain Model Deltas, ADRs, and code in the referenced repositories.

   Run both checks before completing context gathering:

   • Redundancy. Search the codebase for an existing implementation by domain concept, not just the request's wording, and report where you looked. If found, classify it as already-implemented wontfix in step 5.
   • Prior rejection. Run out-of-scope matching.
2. Recommend. Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the request — including whether it's already implemented. Wait for direction.
3. Verify the claim. Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a Review Proposal, confirm the diff does what it claims — check it out, run the relevant tests or commands. Report what happened: confirmed (with code path), failed, or insufficient detail (a strong needs-info signal). A confirmed verification makes a much stronger agent brief.
4. Grill (if needed). If the request needs fleshing out, use the grill-with-docs skill without granting canonical capture. Keep returned Domain Model Deltas in the current triage context. Before a cross-session needs-info pause, move confirmed deltas into the established-so-far triage notes; before ready-for-agent, move relevant deltas into the Agent Brief.
5. Apply the outcome:

   • ready-for-agent — post and validate an Agent Brief through AGENT-BRIEF.md, then finish by request surface:

     • For a Work Tracker request, invoke fresh shared Context Assembly for Delivery Context at that exact permanent reference after the complete Agent Brief is public. This new file must show that every material gap named by the initial Incomplete result is repaired.
     • For a Review Proposal, re-read the proposal and invoke fresh shared Context Assembly for the same selected profile and permanent authority root. Use Decision Context for a Decision Ticket or Specification and Delivery Context for delivered work.

     Enforce the planning readiness invariant and apply the mapped Routing Label only when the selected branch's Context Assembly gate passes. A settled cross-repository or standalone request may go directly here; cross-repository scope alone does not require a Specification or Wayfinder Map.

   • ready-for-human — use the same request-surface profile validation and brief structure, then note why the work can't be delegated, such as judgment calls, external access, design decisions, or manual testing.
   • needs-info — post triage notes (template below).
   • wontfix — close, with the comment depending on why:
     • Already implemented — the change already exists in the codebase. Point to where it lives; do not write to .out-of-scope/ (that KB is for rejected requests, not built ones).
     • Rejected (bug) — polite explanation, then close.
     • Rejected (enhancement) — write to .out-of-scope/, link to it from a comment, then close (OUT-OF-SCOPE.md).
   • needs-triage — apply the role. Optional comment if there's partial progress.

Requests with unresolved design or decomposition return to discovery or planning. Missing reporter facts use needs-info. Do not invent authority merely to make a request executable.

An execution-ready outcome is complete when the Agent Brief validates, the applicable Context Assembly gate passes at its retained selection, and the configured state role matches the outcome.

Quick state override

A maintainer's direct ready-for-agent request selects that outcome and skips step 4 only. It does not skip the initial diagnostic read, Agent Brief validation, or the post-brief Delivery Context rebuild. If settled information cannot repair the initial assembly diagnostics, use needs-info instead of applying ready-for-agent.

Needs-info template

## Triage Notes

**What we've established so far:**

- point 1
- point 2

**What we still need from you (@reporter):**

- question 1
- question 2

Capture everything resolved during grilling under "established so far" so the work isn't lost. Questions must be specific and actionable, not "please provide more info".

Resuming a previous session

If prior triage notes exist on the request or Review Proposal, read them, check whether the reporter has answered any outstanding questions, and present an updated picture before continuing. Don't re-ask resolved questions.