getty104 Triage Created Issue
着手可能と判断されたIssueに対して、確認事項の有無や実行準備の整合性を判定するトリアージスキルです。
Instructions
前提
- 依存Issueの着手判定（このIssue自体が着手可能な状態にあるかどうか）はすでに解決済みであり、再確認は不要である
- ただし、これは「このIssueに向けた依存関係の解決状況」に限定される。確認事項の本文内で個別に参照されているIssue/PR（例:「#1404はマージ済みか」といった言及）の現在の状態まで解決済みとみなしてよいわけではなく、実行ステップ2で別途検証する
責務
- コメント履歴の精査による人の確認要否の判断と
cc-need-human-checkラベルの付与 - Issue内容の精査によるクローズ判断
- 確認事項への未回答チェックによる
cc-answer-issue-questionsラベルの付与 - コメント履歴で確定した内容がdescriptionに未反映な場合の
cc-update-issueラベルの付与 - 着手準備が整っている場合の
cc-exec-issueラベルの付与
注意事項
- Issueに付いているラベルは絶対に外さないこと。
gh issue editで--remove-labelは使用を禁止する
実行モードの制約: サブエージェント・サブスキル・Bashをバックグラウンド実行しないこと
本スキルは claude-task-worker の triage-created-issue ワーカー（cc-issue-created + cc-triage-scope ラベル）から自動起動される想定で、ワーカーはスキルプロセスの同期完了を根拠にラベル遷移（cc-answer-issue-questions / cc-exec-issue の付与や Issue のクローズ）を進める。本スキル内部で呼び出す Agent / Skill / Bash を絶対にバックグラウンド実行しないこと。
Agentツールは既定がrun_in_background: true（バックグラウンド）。呼び出しごとに 必ずrun_in_background: falseを明示指定 し、フォアグラウンドで同期的に結果を受け取ってから次の処理に進む。指定を省略した場合はバックグラウンドで走り、本スキルが未完のまま終了するSkillにrun_in_background: trueを指定しない。既定の同期実行（フォアグラウンド）で最終出力を受け取ってから次の処理に進む- 同一メッセージ内で複数の
Agent/Skillを並列に投げるのは「並列実行」であって「バックグラウンド実行」ではないため許容される（各サブエージェントの完了はその場で同期的に待つ） Bashにもrun_in_background: trueを指定しない。コマンド末尾に&を付けたり、nohup/disown/setsidでデタッチしたりしないScheduleWakeupなどで処理を後回しにしない
理由: バックグラウンド化すると子処理の完了前に本スキルが終了し、ワーカーが「トリアージが完了した」と誤認する。判定未確定のまま cc-answer-issue-questions や cc-exec-issue が付与されず Issue が次のワーカーに引き継がれない（あるいは判定と異なるラベルが付与される）といった状態壊れを防ぐため、内部処理はすべて同期実行で完結させる。
実行ステップ
スキルが呼び出された時は、以下のステップで処理を行なってください。
1. Issueのdescriptionとコメント履歴の確認
対象Issueのdescription・ラベル・コメント履歴全体を取得する。
gh issue view $0 --json body,labels,comments
2つの観点で内容を読む。
- コメント履歴全体: 人の確認が必要なシグナル（議論の未決着、明示的な相談・承認依頼、高リスクな判断など）が含まれていないか
- 最後のコメント: 確認事項が含まれているか、含まれている場合に未回答の項目があるか
2. 確認事項内で参照されるIssue/PRの現在状態の検証
最後のコメントの確認事項本文の中で、他のIssueやPRが参照されている場合（Issue番号・PR番号・URLでの言及、「依存Issue」「関連PR」といった表現を含む）、その参照先の現在の状態をghコマンドで検証する。本文やコメントの記述はスナップショット時点のものであり、その後クローズ・マージされている可能性があるため、鵜呑みにせず必ず最新状態を取得する。
gh issue view <参照先のIssue番号> --json state,title
gh pr view <参照先のPR番号> --json state,title,mergedAt
- ここで得られた事実（例: 参照先がすでに
CLOSED/MERGEDになっている）は、次のステップの確認事項の判定、特に「事実確認で解消可能かどうか」の判断材料として用いる - 確認事項がIssue/PRを参照していない場合は、このステップをスキップする
3. 判定と処理
以下の優先順で判定と処理を行う。
- コメント履歴全体から見た人間確認シグナル（確認事項の内容とは独立に判定する。未決着の議論、明示的な承認依頼など）に該当する場合は、他の判定に先立ってパターンAとして処理し、以降の判定はすべて打ち切る。この「最初に該当したら以降は評価しない」という排他ルールは、この人間確認シグナルの判定にのみ適用される
- 上記に該当しない場合、パターンB（対応不要判断）を評価する。該当すればクローズして終了する
- どちらにも該当しない場合、最後のコメントの確認事項を項目ごとに個別評価し、事実確認で自動回答可能かどうかに応じてパターンAまたはパターンCを判定する（判定基準はパターンAとパターンCを参照）。未回答の確認事項が残りパターンCに該当する場合はそこで終了する
- 確認事項がない、または全て回答済みで着手可能に見える場合は、着手（パターンE）に進む前にパターンD（コメント履歴のdescription反映チェック）を評価する。コメントで確定した内容がdescriptionに未反映であれば
cc-update-issueを付与して終了し、反映済みで整合している場合に限りパターンE（cc-exec-issue）を付与する - ラベルの排他性として、各トリアージ実行で付与する遷移ラベル（
cc-need-human-check/cc-answer-issue-questions/cc-update-issue/cc-exec-issue）は同一Issueに複数付与しない。特にcc-need-human-checkとcc-answer-issue-questionsは同時に付与しない
パターンA: 人の確認が必要と判断できる場合（最優先）
このラベルは「自動化を一旦止めて人に渡す」ためのセーフティバルブ。曖昧なまま、あるいは影響の大きい判断を自動で押し進めると手戻りや事故につながるため、確信が持てない・人間の意思決定が要るケースはここで止める。
パターンAに該当するケースには次の2つの経路があり、最終的な処理内容（コメント＋ラベル付与）はどちらも同一である。
経路1: コメント履歴全体の人間確認シグナル（確認事項の内容とは独立に判定）
以下のようなシグナルが該当する（例であり網羅ではない。最終的には文脈に基づいて判断する）：
- 人間同士の議論が未決着、または意見が対立したまま残っている
- 人間が明示的にレビュー・承認・相談を求めている（「要相談」「確認お願いします」「@担当者 確認して」など）
- 過去に確認事項への回答を試みたが解消されず、堂々巡りになっている
- AI自身がクローズすべきか着手すべきか、確認事項の内容によらず判断に確信を持てない
この経路に該当した場合は、確認事項の内容を精査するまでもなくパターンAとして処理し、以降（経路2を含む）の判定はすべて打ち切る。
経路2: 確認事項の個別評価による人間判断の要否
最後のコメントの確認事項のうち、まだ回答が記載されていない各項目について、事実確認（コードベース調査やghコマンド。ステップ2で検証したIssue/PRの現在状態を含む）で自動回答可能かどうかを個別に評価する。
以下のようなシグナルに該当し、かつ事実確認では解消できないと判断した項目は、人間判断が必要な項目として扱う（例であり網羅ではない）：
- 仕様・要件に矛盾や曖昧さがあり、コードベース調査だけでは解消できない
- 破壊的変更・セキュリティ・データ移行・課金・外部公開など、影響が大きい／不可逆な判断が絡む
- Issueのスコープを超える、優先度やビジネス判断など人間の意思決定が必要
反証シグナル（人間判断が必要とは判断しない条件）: 以下のいずれかに該当する場合、表面上は上記シグナルに一致していても、その項目は事実確認で解消可能な項目として扱う。
- Issue本文（実装プラン等）がすでに根拠付きの結論を示しており、確認事項がその結論を裏付け・再確認するだけの内容である
- 確認事項がコードベース調査や
ghコマンドによる事実確認（ステップ2で検証したIssue/PRの現在状態を含む）だけで解消できる内容である - ステップ2で検証したIssue/PRの現在状態から、確認事項の前提となる事実がすでに判明している
まだ回答が記載されていない項目全てが、反証シグナルに該当せず事実確認でも解消できない人間判断必要な項目と判断された場合に限り、経路2としてパターンAに該当する。一部の項目のみが該当する場合はパターンAには該当せず、パターンC（後述）で扱う。
該当する場合の処理
経路1・経路2のいずれかに該当する場合、以下を実行してこのIssueの処理を終了する。他のラベル（クローズ・cc-answer-issue-questions・cc-update-issue・cc-exec-issue）は付与しない。
人の確認が必要と判断した理由を、根拠となるコメントを引用しつつ簡潔にコメントする
gh issue comment $0 --body "<人の確認が必要と判断した理由>"cc-need-human-checkラベルを付与するgh issue edit $0 --add-label "cc-need-human-check"
パターンB: Issueの内容が対応不要と判断できる場合
Issueの内容を精査した結果、以下のいずれかに該当する場合：
- すでに別のIssueやPRで対応済み・重複している
- 要件や仕様の変更により不要になった
- 誤って起票されたIssueである
- その他、明らかに対応不要と判断できる
以下を実行する：
Issueにクローズ理由をコメントで記載する
gh issue comment $0 --body "<クローズ理由の説明>"Issueをcloseする
gh issue close $0
パターンC: 確認事項への回答が必要な場合
最後のコメントに確認事項が存在し、まだ回答が記載されていない項目がある場合（パターンAの経路2で全項目が人間判断必要と判断されたケースを除く。一部の項目のみ事実確認で自動回答可能な場合と、全項目が自動回答可能な場合の両方を含む）：
gh issue edit $0 --add-label "cc-answer-issue-questions"
未回答項目の一部が人間判断を要すると評価された場合でも、本スキルではcc-need-human-checkは付与しない。人間判断が必要である旨を回答として明示する対応は、answer-issue-questionsスキル側の回答フェーズに委ねる。
パターンD: コメント履歴で確定した内容がdescriptionに未反映の場合
パターンA〜Cのいずれにも該当せず着手可能に見える状態でも、実行担当（executor）はdescriptionを唯一の入力として作業する。そのため、コメント履歴で確定した実質的な内容（確認事項への回答、合意された方針・仕様の変更、スコープや制約の追加・修正など）がdescriptionに反映されていないと、その決定が実行時に取りこぼされる。着手に進む前に、descriptionがコメント履歴の確定内容を過不足なく自己完結的に表現できているかを検証する。
反映済みかを判定する対象は、コメントで確定した実質的な内容に限る。以下は反映対象に含めない：
- 未回答の確認事項そのもの（パターンCで扱う。回答が出た後に反映対象となる）
- 本スキルやワーカーが付与したトリアージ用コメント（判定理由の記録など）や、
/gemini reviewのような処理上のノイズコメント - 雑談・相槌など、Issueの内容に影響しないコメント
上記を除いた確定内容のうち、descriptionに書かれていない、または古いまま食い違っている項目が一つでもある場合は、descriptionが陳腐化しているとみなす。この場合は着手（パターンE）に進めず、以下を実行してこのIssueの処理を終了する。他のラベル（cc-exec-issueなど）は付与しない。
descriptionに未反映と判断した内容を、根拠となるコメントを引用しつつ簡潔にコメントする
gh issue comment $0 --body "<descriptionに未反映と判断した内容の説明>"cc-update-issueラベルを付与するgh issue edit $0 --add-label "cc-update-issue"
コメント履歴の確定内容がすべてdescriptionに反映済みで整合している場合は、このパターンには該当せず、パターンEに進む。
パターンE: 着手準備が整っている場合
確認事項がない、または全ての確認事項に回答済みであり、かつパターンDでコメント履歴の確定内容がdescriptionに反映済みと確認できた場合、実行可能と判断してcc-exec-issueラベルを付与する：
gh issue edit $0 --add-label "cc-exec-issue"