Triage Status

Triage Status Skill

status: * ラベルがまだ付いていない open Issue に、初期 status ラベルを付与する。 新規に作られた Issue は誰も status を付けないまま溜まりがちで、pick-issue の 着手可否判定や優先度付けが効きにくくなる。本 skill はその空白を埋め、内容から 妥当な初期 status を推論して「提案 → 確認 → 付与」する。

前提条件

• gh auth status で GitHub 認証済みであること
• repo に status: * ラベルが定義されていること（status: ready / status: blocked / status: designed など）。未定義なら本 skill は何もできない — その旨を伝えて 終了する（/hane:init でのラベル作成を案内する）。ラベルは捏造しない。

スコープと責務の分離

• 付与するのは「初期 status」だけ — status: * ラベルが 1 つも付いていない Issue に対して、最初の 1 つを付ける。付与しうるのは静的に判断できる status: ready / status: blocked / status: designed の 3 つ。
• lifecycle の遷移は対象外。status: designing / status: implementing / status: in-review は「今まさに誰かが作業している」ことを表す active な状態で、 start-dev / ship が work の進行に合わせて更新する。本 skill はこれらを 付与しない（誰も着手していない Issue にこれらを付けると実態とずれる）。
• status: on-hold（塩漬け）も付与しない。これは「コンセプト再検討などで 意図的に着手を止める」という人間の判断で付ける保留状態であり、Issue 本文から 静的に推論できるものではない（blocked と違い依存 Issue のような明示トリガも 無い）。初期付与で判断できるのは ready / blocked / designed の 3 つだけ。on-hold の 付け外しは人間が明示的に行う（pick-issue は on-hold を候補から除外する）。
• 既に status が付いた Issue は触らない。上書き・遷移は lifecycle skill の責務。 本 skill は「status 空白の Issue」だけを対象にする。
• 責務分離のまとめ: 本 skill = 初期 status の付与 / start-dev・ship = その後の 遷移 / pick-issue = status を読んで着手対象を選ぶ。

ホスト repo に依存する慣習について

• repo の status: * ラベルの存在で gating する（他 skill と同じ流儀。新しい ホストマーカーは導入しない）。ラベルが無ければ終了する。
• どの status 名が定義されているかは repo により異なる。取得したラベル集合の中から、 意味的に対応するもの（着手可能 → ready 相当、依存待ち → blocked 相当、設計承認済み → designed 相当）を選ぶ。定義されていない status は提案しない。

手順

1. 対象 Issue の決定

• 引数で Issue 番号が指定されていれば、それ（複数可）を対象にする。 例: /triage-status 123、/triage-status 123 456。

• 指定が無ければ、status: * ラベルが 1 つも付いていない open Issue を対象に する。

  gh issue list --state open --limit 100 --json number,title,labels,body,url
  

  対象が多い場合は、まず件数を伝えて、全件処理するか / 番号を絞るかを確認する （黙って一部だけ処理しない）。既に status が付いた Issue が引数指定に含まれて いたら「既に status あり」として skip する（上書きしない）。

2. status ラベルの把握

repo の全ラベルを取得し、status: * family を洗い出す。

gh label list --limit 200

• status: * が 1 つも無ければ、ここで終了する（前提条件参照）。
• 定義されている status 名を確認し、ready / blocked / designed 相当がそれぞれ どの名前かを把握する（repo により名称が違いうる）。

3. 各 Issue の初期 status を推論

対象 Issue ごとに title + body を読み、以下の順で初期 status を決める。

• active な状態（designing / implementing / in-review）は付与しない。これらは 実際に着手したときに lifecycle skill が付ける。
• 依存先 #X が既に closed なら「解決済み」とみなし blocked にしない。
• 各提案に1 行の根拠を添える（本文のどの記述・どの依存から判断したか）。判定に 迷う場合は安全側の ready に倒す（blocked は open な依存の根拠が明確なときだけ）。

4. 確認

提案を提示し、AskUserQuestion で付与内容を確認する。

• 対象が 1 件: 推論した status と根拠を提示し、そのまま付与 / 別の status に変更 / 中止 を選ばせる。
• 対象が複数件: Issue ごとに #番号 タイトル → status: X（根拠） を一覧提示し、 全件承認 / 個別に見直し / 中止 を選ばせる。
• ユーザーが status を変えたい場合はそれを反映する。

5. 付与

承認された内容だけを適用する。

gh issue edit <N> --add-label "status: <ready|blocked|designed>"

• 対象 Issue には status が無い前提なので --remove-label は不要。
• active な状態（designing / implementing / in-review）は付けない。
• repo に無い status ラベルは付けない（捏造しない）。

6. 結果の報告

付与した Issue と status を 1 行ずつ報告する。skip した対象（既に status あり・ 判断不能）があれば件数と理由を添える（黙って絞らない）。付与後は pick-issue で 着手対象を選べる旨を一言添えてよい。

注意

• active な状態を付けない。 designing / implementing / in-review は「作業中」を 意味し、着手していない Issue に付けると pick-issue の除外判定を誤らせる。初期 付与で静的に判断できるのは ready / blocked / designed の 3 つだけ。
• 既に status が付いた Issue を上書きしない。 遷移は start-dev / ship の責務。
• status: * ラベルが無い repo では動かない。 ラベルを捏造せず、定義を促して終了する。
• 本 skill は初期 status の付与に徹し、Issue の選定（pick-issue）や開発着手 （start-dev）は行わない。