triage

name	triage
description	Fire-and-forget issue triage. Runs the analyze workflow, posts findings as a GitHub comment with expandable sections, and sets the size/* label. Use when the user wants to quickly triage a GitHub issue without interactive discussion.
allowed-tools	Agent, Read, Write, Edit, Glob, Grep, Bash(gh issue view *), Bash(gh issue edit *), Bash(gh issue comment *), Bash(gh issue list *), Bash(gh pr list *), Bash(gh label create *), Bash(gh api graphql *), Bash(tractor *), Bash(task install)
argument-hint	<issue-number> [or GitHub URL]

Triage GitHub Issue

Automatically analyze a GitHub issue and post the findings. This is the fire-and-forget version of /analyze — it runs the full analysis, posts a structured comment to GitHub, and sets the appropriate size label.

Input

$ARGUMENTS should be a GitHub issue number or URL. If missing, print an error and stop.

Process

Step 1: Run the analysis

Perform the full analysis workflow as described in the analyze skill (.claude/skills/analyze/skill.md). This produces a detailed report at .issues/<number>-<slug>.md.

Critical depth requirement: Every sub-issue in the analysis MUST have its code path traced through the actual codebase with file:line references. Do not write surface-level descriptions like "would need data model changes" — instead, read the actual types, trace the actual call chain, and report what specifically exists and what's missing. For each sub-issue:

1. Read the relevant source files — use Grep/Glob/Read to find and read the actual code
2. Trace the execution path — from input (CLI/config) through processing to output, noting each file:line
3. Identify the gap — what specific struct/function/enum would need to change and why
4. Report what you found — include the actual field names, function signatures, and data flow

A sub-issue analysis that doesn't reference specific code locations is incomplete. If you can't trace a code path, say so explicitly rather than hand-waving.

Step 2: Prepare the GitHub comment

Using the analysis report, create a condensed comment with expandable sections at .issues/<number>-<slug>-comment.md. This file will be posted to GitHub.

Comment structure

## Triage: complexity analysis

**Overall: `size/<S|M|L>`**

### Sub-issues

| # | Issue | Size | Rationale |
|---|-------|------|-----------|
| 1 | <description> | `size/S` | <1 sentence> |
| 2 | <description> | `size/M` | <1 sentence> |

<details>
<summary><strong>1. <sub-issue title></strong> — <code>size/S</code></summary>

#### Problem
<concise problem description with key file:line references>

#### Solution direction
<brief approach — not full design, just shape>

#### Key locations
- `path/to/file.rs:123` — <role>




2.  — size/M

...same structure...











---

Constraints for the GitHub comment:

• Keep the top-level summary scannable — table + one line per sub-issue
• Put all detail inside <details> blocks so it doesn't overwhelm
• Include file:line references — they're the most useful part for implementation
• Target the comment body at under 40k tokens when loaded back into a conversation
• Do NOT include raw code traces or full execution path walkthroughs in the comment — those stay in the local .issues/ file only

Step 3: Set the size label

Determine the overall size label for the issue:

• If all sub-issues are the same size → use that size
• If mixed → use the largest size (the issue is as complex as its hardest part)
• If the issue has no sub-issues → use the single assessment

Apply the label:

gh issue edit <number> --add-label "size/<S|M|L>"

Remove any existing size labels first to avoid conflicts:

gh issue edit <number> --remove-label "size/S" --remove-label "size/M" --remove-label "size/L" 2>/dev/null

Also add the triaged label to mark the issue as analyzed:

gh issue edit <number> --add-label "triaged"

Step 4: Post the comment

gh issue comment <number> --body-file .issues/<number>-<slug>-comment.md

Step 5: Confirm

Print a one-line confirmation:

Triaged #<number> as size/<X> — comment posted, label set.

Error handling

• If the issue doesn't exist, print an error and stop.
• If label creation fails (permissions), warn but continue with the comment.
• If the comment fails to post, print the error and note the local file path as fallback.

Guidelines

• This is fire-and-forget — do NOT ask the user questions. Make reasonable decisions autonomously.
• The local .issues/ report is the detailed artifact; the GitHub comment is the condensed view.
• Always write both files — the local report serves as the implementation reference.