triage

# 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 ```markdown ## 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> </details> <details> <summary><strong>2. <sub-issue title></strong> — <code>size/M</code></summary> ...same structure... </details> ### Related work <bullet list of related todos, issues, PRs, design docs — with brief relationship notes> ### Suggested groupings <which items to tackle together> --- *Analysis generated by Claude Code from [`.issues/<filename>`](link-or-note)* ``` **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: ```bash gh issue edit <number> --add-label "size/<S|M|L>" ``` Remove any existing size labels first to avoid conflicts: ```bash 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: ```bash gh issue edit <number> --add-label "triaged" ``` ### Step 4: Post the comment ```bash 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.