yannsugi 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領域で見る)。入口の数と領域の数が食い違うときは領域の数を優先する。判定に使った領域と、改修か新規かを根拠に含める。
手順
- Issue 本文を読み、報告されている入口(画面・API・ファイル経路)と領域を挙げる
- ディレクトリ構成と README、システムマップから、その入口に関わる領域が1つか複数か、それとも分からないかを見る。ここで所要時間の目安は5分。原因を探し始めたら止める
- 判定と根拠一行を決める(目安100字)。根拠の型:
<判定>: <改修/新規>・領域=<…>・<複数領域か/不明か/1領域か>・<迷った点があれば一語> - 次のブロックを成果物として利用者に提示する。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 の性質で決める。速度は経路の畳み方で出す