# Triage Issue

> Use when a new GitHub Issue arrives and no one has yet decided how heavy it is — before clarify-expectation, and before anyone starts investigating causes or proposing fixes

- Skill: `yannsugi/triage-issue` (Agent Skill)
- Install (CLI): `npx skillmds@latest add yannsugi/triage-issue`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yannsugi/triage-issue/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yannsugi (https://skillmd.com/u/yannsugi)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/yannsugi/triage-issue

---


# triage-issue

Issue を S / M / L に判定し、根拠を一行で Issue に残す。判定はゲート①で人間の目に入る。
思想は `${CLAUDE_PLUGIN_ROOT}/DESIGN.md` の「解明フェーズの規律」冒頭。

**核**: 判定と根拠一行だけを出す。原因の仮説・修正案・次の一手は出さない(それは後続フェーズの仕事で、ここで書くと解明を汚染する)。

## 入力契約

読んでよいもの: 対象 Issue の本文(`gh issue view <n>`)、対象 repo のディレクトリ構成と README、`docs/system-map.md`(あれば)。
読んではいけないもの: 他 Issue、実装コードの中身(構成を見るのはよいが、原因を追って読み込まない)。README を読んで原因の仮説が浮かんでも、根拠には書かない。

## 判定基準

| 判定 | 基準 | 後続 |
|---|---|---|
| S | 影響が1領域・1入口に閉じ、Asis/Tobe が報告文からほぼそのまま書ける | 解明と実現案を1コメントに畳む軽量経路。承認は省かない |
| M | 影響領域は見当がつくが、期待を書くには現状調査が要る | 標準経路(clarify-expectation →) |
| L | 影響領域が複数に跨る、または跨るかどうかが分からない。分割が必要になりそう | survey-codebase を前置してから標準経路 |

迷ったら上へ倒す。L 相当を M と誤ると、調査不足のまま分割して多単位で前提崩壊する(NG 調査の帰属先の一つ)。

領域 = FE / BE / IaC / データ。repo に無い領域は数えない(compose とスクリプトだけの repo なら IaC とデータの2領域で見る)。入口の数と領域の数が食い違うときは領域の数を優先する。判定に使った領域と、改修か新規かを根拠に含める。

## 手順

1. Issue 本文を読み、報告されている入口(画面・API・ファイル経路)と領域を挙げる
2. ディレクトリ構成と README、システムマップから、その入口に関わる領域が1つか複数か、それとも分からないかを見る。ここで所要時間の目安は5分。原因を探し始めたら止める
3. 判定と根拠一行を決める(目安100字)。根拠の型: `<判定>: <改修/新規>・領域=<…>・<複数領域か/不明か/1領域か>・<迷った点があれば一語>`
4. 次のブロックを成果物として利用者に提示する。GitHub への投稿(`gh issue comment <n>`)とラベル付け(`gh issue edit <n> --add-label triage:<S|M|L>`)は、利用者が明示的に「投稿して」と指示した場合にのみ実行する。指示が無ければ文面を出して止まる

```
## トリアージ
- 判定: L
- 根拠: 改修・領域=IaC+データ・対象環境が検証用か運用系か本文から確定せず影響領域不明・上に倒した
- 次: survey-codebase
```

試走でローカルファイル `<name>.md` を対象にする場合は、同じディレクトリの `<name>.triage.md` に上記ブロックを書く。`gh` の投稿とラベル付けは行わない。

## よくある失敗

- 根拠が3行を超える → 解明を始めている。判定に効いた事実だけ残して削る
- 「仮説 A/B」「切り分け順」「推奨する次の一手」を書く → 実現案の語彙。全部削る
- 「1行直せば終わりそう」で S にする → 修正量は基準ではない。影響領域の数と確定度が基準
- S の理由に「急いでいるから」が混じる → 判定は Issue の性質で決める。速度は経路の畳み方で出す