Menu
Route incoming issues through a 5-state workflow (needs-triage โ needs-info / ready-for-agent / ready-for-human / wontfix) with bug/enhancement categorization. Applies labels, adds context notes, reproduces bugs. Usage: /triage <issue-id>
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Adversarial evaluation of code changes โ runs build, tests, plan compliance, and security review. Use after implementing changes or before creating a PR. Usage: /evaluate [story-id] [--quick]
Build a feature from a tracker task (local task, GitHub issue, or Todoist task) or plain description โ understand, plan, execute, evaluate, and PR in a streamlined flow, or loop back on a rejected PR with `--rework <PR#>`. Lighter than /story โ designed for solo devs and small teams. Usage: /implement <issue-id, task-title, or description> [--discuss] [--research] [--quick] [--auto] [--full] [--autonomous] [--rework <PR#>]
Goal-driven story execution โ understand โ define goal โ plan โ execute โ verify โ e2e gate โ PR. Done = goal met (acceptance + e2e gate green), not just compiles. Use when starting a sprint story, implementing a feature, or picking up a task. Usage: /story <story-id> [--auto] [--autonomous]
Reconcile merged PRs and completed work against open tracker items. Mode-aware: works in local, tracker, and both modes. Supports --dry-run and --import-backup [file]. Usage: /sync-tracker [--dry-run] [--import-backup [file]]
Execute XML tasks from the story plan wave by wave (Phase 3 only โ no understand, no plan, no PR). Use when resuming a story that already has a task plan. Usage: /run-tasks <story-id> [--auto]
Root cause diagnosis when the 3-attempt rule triggers โ stop retrying and diagnose. Builds a deterministic feedback loop first, then generates ranked falsifiable hypotheses. Mandates regression tests and instrumentation cleanup. Aliases: /debug, /diagnose. Usage: /debug
| name | triage |
| description | Route incoming issues through a 5-state workflow (needs-triage โ needs-info / ready-for-agent / ready-for-human / wontfix) with bug/enhancement categorization. Applies labels, adds context notes, reproduces bugs. Usage: /triage <issue-id> |
Core Philosophy: Every incoming issue deserves a routing decision within one pass. Gather context, categorize, attempt reproduction if it's a bug, grill for missing details, then route to the right state. One issue per invocation.
Triggers: "triage this issue", "route this issue", "categorize this bug", "what should we do with this issue", "/triage"
You are the issue triage facilitator. Your job is to take a single incoming issue, gather context, categorize it, attempt to reproduce bugs, and route it to the correct state by applying labels.
One issue per invocation. AI-generated comments must include the disclaimer.
Read triage label overrides from tasks/tracker-config.md (enterprise) or tasks/notes.md (solo). Look for a triage_labels section. If present, use the custom labels. If not, use defaults:
5 states (default labels):
| State | Default label | Meaning |
|---|---|---|
| Needs triage | needs-triage | New issue, not yet categorized |
| Needs info | needs-info | Missing details โ can't route without more from the reporter |
| Ready for agent | ready-for-agent | Well-defined, can be picked up by /story or /implement |
| Ready for human | ready-for-human | Requires human judgment, domain expertise, or manual testing |
| Won't fix | wontfix | Intentional behavior, duplicate, or out of scope |
2 categories:
| Category | Default label |
|---|---|
| Bug | bug |
| Enhancement | enhancement |
Parse $ARGUMENTS for an issue ID.
If missing, ask: "Which issue should I triage? Give me an issue ID or number."
Fetch the issue using the tracker adapter:
bash trackers/active/get-issue.sh <ID>
Read the full issue: title, description, labels, state, comments. If the issue doesn't exist, stop and report.
Based on the issue description, explore the relevant area of the codebase:
This context informs your categorization and reproduction attempt.
Recommend a category and state:
Category recommendation: [Bug / Enhancement]
- Reasoning: [1-2 sentences โ why this is a bug vs. enhancement]
State recommendation: [one of the 5 states]
- Reasoning: [1-2 sentences โ why this state]
Wait for user confirmation before applying labels. (Gate type: escalation)
If categorized as a bug:
If not reproduced, recommend changing state to needs-info.
Skip this step for enhancements.
If the issue is missing critical information for routing:
Ask targeted questions (one at a time, with recommendations):
Q1: [Missing detail] My recommendation: (A) [suggested answer based on codebase exploration] Other options: (B) Mark as
needs-infoand ask the reporter
Common missing details:
If you can fill in the gaps from codebase exploration, do so. Otherwise, recommend needs-info.
After user confirms the category and state:
bash trackers/active/add-label.sh <ID> "<category-label>"
bash trackers/active/add-label.sh <ID> "<state-label>"
bash trackers/active/remove-label.sh <ID> "<old-state-label>"
ready-for-agent or ready-for-human:For ready-for-agent, draft a structured note:
**Triage summary:**
- Category: [bug/enhancement]
- Reproduction: [confirmed/not-reproduced/can't-test]
- Relevant code: [file paths explored]
- Suggested approach: [1-2 sentences]
_Generated by AI during triage. Verify before acting on this summary._
For needs-info, draft a question to the reporter:
Could you provide more details on [specific missing information]?
_Generated by AI during triage._
Show the draft to the user before posting. (Gate type: escalation)
If the user approves, post the triage note in a mode-aware way. Never use create-issue.sh here โ it CREATES A NEW ISSUE and cannot comment on an existing one.
tracker: local): append the triage note to the task file body tasks/issues/<ID>.md (task-specific notes live in the task body, D12).gh issue comment <ID> --body ..., az boards work-item ... --discussion ..., td comment ...). The 8-script adapter interface has NO add-comment script, so this must be a native call, not an adapter call.After triage is complete:
todo.md โ never hand-edited. It is a generated dashboard (D9); in local/both mode the label changes you applied via the adapter are reflected automatically the next time the renderer (trackers/lib/render-todo.sh) runs โ in local mode add-label.sh/remove-label.sh already trigger regeneration. In tracker mode todo.md does not exist. No manual todo.md action in any mode.flags-and-notes.md โ if the issue is a high-priority bug or blocker, add to "Active Blockers":
- [TRIAGE] Issue #<ID>: <title> โ routed to <state> โ <what's needed next>
flags-and-notes.md ships only in the team pack. If it is absent (the solo pack ships only notes.md + tracker-config.md), route the same - [TRIAGE] ... line to tasks/notes.md instead (D12: ad-hoc scratch โ notes.md). Keep the same line format.wontfix: always explain why โ "Intentional behavior: [reasoning]" or "Duplicate of #[ID]" or "Out of scope: [reasoning]".ready-for-agent when possible. If you can't reproduce, say why.