Triage

Before reading relative links, run cd '<loaded-skill-directory>' && pwd -P with this loaded file's directory to obtain the physical base, then resolve links against that printed directory. Resolve the source symlink before applying ... Read linked files even when their skills are absent from the discovery list.

Move tracker items through the category and state roles below. When the issue-tracker configuration treats external pull requests as a request surface, apply the same process to them: a PR is an issue plus attached code. Resolve a bare reference such as #42 according to that configuration.

Prefix every issue body or comment posted during triage with:

> _This was generated by AI during triage._

Reference docs

• AGENT-BRIEF.md — required structure for durable agent briefs
• OUT-OF-SCOPE.md — rules for the .out-of-scope/ knowledge base

Roles and transitions

Assign exactly one category role:

• bug — existing behavior does not match its contract or expected behavior
• enhancement — requested behavior is new or changes an existing capability

Assign exactly one state role:

• needs-triage — maintainer evaluation is pending
• needs-info — information required from the reporter is pending
• ready-for-agent — validated implementation contract regardless of availability; execution still requires explicit authorization
• ready-for-human — implementation requires a human
• wontfix — the request will not be actioned

For a PR, evaluate the states against its attached code: ready-for-agent means an agent brief identifies the next action on the diff; ready-for-human means a human can merge it without another triage step.

These are canonical role names. Read their tracker-specific label mapping. If the mapping is missing, follow setup-omskills and its scoped authorization gate before continuing, including in headless runs. Respect read-only roles and return unresolved prerequisites to the responsible caller. If an item has multiple category roles or multiple state roles, report the conflict and obtain maintainer direction before any other triage action.

Normal transitions are:

• no state role → needs-triage;
• needs-triage → needs-info, ready-for-agent, ready-for-human, or wontfix; and
• needs-info → needs-triage after reporter activity.

A maintainer may override any transition. Explicit direction authorizes the requested exceptional transition without another confirmation; state the exception and exact changes before applying them. Ask only when the target state or intended consequences remain materially ambiguous. The ready-for-agent audit boundary below still applies.

Invocation routing

Map natural-language requests to one of these branches:

• attention query, such as “Show me anything that needs my attention” → Show items needing attention;
• a specific item, such as “Let's look at #42” → Triage a specific item;
• an explicit state change, such as “Move #42 to ready-for-agent” → Quick state override; or
• a ready-work query, such as “What's ready for agents to pick up?” → query the configured ready-for-agent role and report eligible items without selecting any into a Mission.

Show items needing attention

Query the tracker and return three buckets, each ordered oldest first:

1. items with no state role, including items that already have a category role;
2. items with needs-triage; and
3. needs-info items with reporter activity newer than the latest triage notes.

When external PRs are configured as a request surface, include only external PRs as defined by the tracker configuration and prefix each result with [PR] or [issue]. This author filter applies only to discovery; always process an explicitly named PR.

Show the count for each bucket and one line per item, then wait for the maintainer to select an item.

Triage a specific item

1. Gather context. Read the full body, comments, labels, author, and dates; for a PR, also read the complete diff. Extract conclusions and unanswered questions from prior triage notes. Inspect the affected code using the project's domain terms and applicable ADRs. Perform both checks:
   • Redundancy: search by domain concept, not only the reporter's wording, for an existing implementation of the requested behavior. Record the locations searched. If the behavior already exists, use the already-implemented wontfix outcome in step 5.
   • Prior rejection: read .out-of-scope/*.md and report entries that reject the same requested outcome or establish a scope boundary applicable to it. Use actor, domain concept, and constraints to determine whether the rejection applies.

2. Verify. Test the claim before recommending a state:

   • for a bug, follow the reporter's reproduction steps;
   • for an enhancement, confirm the current behavior or interface state that the request wants changed;
   • for a PR, check out the diff and run the commands or tests that exercise its stated behavior.

   Report one result: confirmed, with the exercised code path and observed result; failed, with the command or step that contradicted the claim; or insufficient detail, listing the exact missing input. Treat insufficient detail as evidence for needs-info, not as automatic authorization to change state.

3. Grill when required. Use grill-with-docs whenever the request needs fleshing out, including when an unresolved answer could change scope, externally observable behavior, acceptance criteria, or a durable architecture decision. Apply its bounded Question-frontier rounds only within the one issue or PR currently being triaged: a round may group no more than three independent Questions about that request, and must never combine Questions from separate requests or tracker items. Update CONTEXT.md or ADRs as that skill requires.
4. Recommend. After verification and any required grilling, present one category, one state, the evidence for each, and the relevant codebase findings. Wait for maintainer direction. If later evidence changes the recommendation, obtain new direction before applying it.
5. Apply the maintainer-approved outcome:
   • ready-for-agent — stabilize the complete execution contract in the Ticket body or an incorporated Agent Brief, without duplicating it. Reuse a current applicable PASS or explicit maintainer BYPASS; otherwise keep or restore needs-triage and run prompt-comprehension-audits. Only that current gate applies readiness, equally for Assisted and Unattended work.
   • ready-for-human — use the same brief structure and identify the specific human requirement, such as judgment, external access, design approval, or manual testing.
   • needs-info — post the needs-info template.
   • wontfix — select exactly one reason:
     • Already implemented: link the implementation and close. Do not add an .out-of-scope/ entry.
     • Rejected bug: post the rejection reason and close.
     • Rejected enhancement: create the entry required by OUT-OF-SCOPE.md, link it in the comment, and close.
   • needs-triage — apply the role; add a comment only when partial findings need to persist.

Outside a maintainer-approved quick state override, the item is triaged when it has exactly one category role, exactly one state role, and the required comment, brief, close action, or out-of-scope entry for that state. A code or behavior-changing item cannot finish at ready-for-agent without a current Prompt Audit PASS or explicit maintainer BYPASS. Remove readiness when its audit fails or becomes materially stale. Readiness does not select the item or authorize implementation.

Triage and readiness are not prerequisites for direct delivery unless the accepted task or repository requires them. The maintainer may select one Ticket for the current conversational owner and stay or authorize continuation while away. Neither absence nor that selection adds a Prompt Audit or dispatcher. The confirmed conversation is the active contract; material changes to existing governing authority update that authority.

For authorized multi-Ticket Mission delivery, dispatch-tickets tracks the selected finite queue, checks live dependencies and delivery evidence, and starts or resumes a technical owner per Ticket. Supply required order, relations, delivery boundaries, and availability; discovery of ready work remains separate from selection. For one Ticket, implement loads orchestrate in the current conversation rather than launching another owner. Pass resolved skill paths to fresh dispatched owners. These routes preserve applicable execution gates, exclusive ownership, orchestrate's review policy, and verified delivery.

Quick state override

When the maintainer explicitly requests a state, use that state without verification or grilling. Preserve the existing category. If no category exists, ask the maintainer to choose bug or enhancement before applying the state.

Before acting, list the exact role changes, comment to be posted, and whether the item will close. A request to apply ready-for-agent does not waive contract completeness or Prompt Audit: use the complete Ticket body or incorporated brief, keep needs-triage unless a current gate already exists, and transition only with PASS or explicit BYPASS. Then apply the listed changes.

Needs-info template

## Triage Notes

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

- point 1
- point 2

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

- <a question that identifies the missing fact or reproduction input>

Record every resolved conclusion under What we've established so far. Each outstanding question must identify a specific fact, artifact, command result, or reproduction input the reporter can provide.

Resume prior triage

When triage notes already exist, compare their outstanding questions with reporter activity after those notes. Present which questions are answered and which remain before continuing. Do not ask an answered question again.