triage

name	triage
description	Triage issues through the repository's Issue Tracker Contract Orbit state machine. Use when the user wants to create, inspect, classify, move, or prepare issues for implementation or review.

Triage

Move issues on the project issue tracker through the repository-defined triage workflow.

Every comment or issue posted to the issue tracker during triage must start with this disclaimer:

> _This was generated by AI during triage._

Repository Rules

Before acting, read the repository's issue tracker contract and the repository docs it points to. Treat those repository rules as the source of truth.

Roles

Use the issue type/category roles and state roles defined by the repository.

Every triaged issue should carry exactly the role cardinality required by the repository contract. If state roles conflict, issue facts are missing, or the tracker disagrees with the contract, handle it according to the repository's hard-stop rules.

Prefer AFK when the slice can be implemented, reviewed, and landed through objective repository gates. Use HITL only when safe advancement requires human interaction such as judgment calls, external access, design decisions, architecture decisions, or manual testing.

The maintainer can override at any time. Apply requested overrides according to repository rules.

Invocation

The maintainer invokes this skill and describes what they want in natural language. Interpret the request and act. Examples:

• "Show me anything that needs my attention"
• "Let's look at #42"
• "Move #42 to the agent-ready state"
• "What's ready for agents to pick up?"

Show What Needs Attention

Query the configured issue tracker and present three buckets, oldest first:

1. Issues that have not yet been triaged under the repository rules.
2. Issues currently in the repository's triage/evaluation state.

Show counts and a one-line summary per issue, then triage according to repository rules.

Triage a Specific Issue

1. Gather context. Read the full issue: body, comments, configured metadata, role facts, reporter, dates, and relevant repository-defined sections. Parse prior triage records so you do not re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Read the repository's out-of-scope records and surface any prior rejection that resembles this issue.

2. Recommend. Decide the type/category, state, and delegation suitability recommendation using repository terminology, with reasoning and a brief codebase summary relevant to the issue. Continue toward the best valid outcome allowed by the repository rules.

3. Reproduce defects. For issues that the repository taxonomy treats as defects, attempt reproduction before choosing an outcome: read the reporter's steps, trace the relevant code, and run focused tests or commands. Report what happened: successful repro with code path, failed repro, or insufficient detail.

4. Handle missing information. If required information is missing, move the issue to the repository-defined missing-information state and record the specific questions in the repository-defined triage record. If the repository does not define a missing-information state, use a relevant available skill to ask the user for those facts; if no relevant skill is available, ask directly.

5. Apply the outcome. Use the repository's configured sections, templates, metadata, and state machine. Do not invent missing facts or skip required gates.

Apply Outcomes

• If the issue is ready for delegated implementation, write the repository-defined agent/development brief before moving it to the appropriate ready state. When supported, mark or mirror delivery mode as AFK.
• If the issue needs human interaction, use the same repository-defined brief structure and note why delegation is not appropriate. When supported, mark or mirror delivery mode as HITL.
• If more information is required, move the issue to the repository-defined missing-information state when one exists, and post triage notes using the repository's configured triage record format.
• If the issue is too large, record the split reason and intended decomposition before any state change.
• If the issue is blocked, record the blocker in the repository-defined place before any state change.
• If the issue should not be actioned, follow the repository's configured cancellation, resolution, out-of-scope catalog, duplicate, and closure rules.
• If review workflow is involved, follow the repository's review evidence, optional human-review state, AFK advancement rules, and human decision gates exactly.

Quick State Override

If the maintainer says to move an issue directly, trust them after checking the repository hard stops. Apply the exact role/metadata changes and write any required brief or record. Do not stop mid-flow except when the repository hard-stop rules require it.

Information Request Shape

When asking a reporter or owner for information, keep the repository-defined triage record structure and include:

• what has already been established
• what is still needed from the reporter or owner

Questions must be specific and actionable, not "please provide more info".

Resuming a Previous Session

If prior triage records exist on the issue, read them, check whether the reporter or owner has answered any outstanding questions, and present an updated picture before continuing. Do not re-ask resolved questions.