Triage Created Issue

着手可能と判断されたIssueに対して、確認事項の有無や実行準備の整合性を判定するトリアージスキルです。

Instructions

GitHub アクセス

本スキルの GitHub 参照/更新は gh コマンドを優先し、gh が使えない場合に GitHub MCP へフォールバックする（本文中の gh コマンド例はそのまま第一手段として読む）。クラウド実行時のみ優先順位が逆転して GitHub MCP が第一手段になるが、その指示は起動プロンプトで渡されるので、指示が無ければローカル実行として扱う。判定手順・gh ↔ MCP の対応表・MCP に代替が無い操作は ${CLAUDE_PLUGIN_ROOT}/references/github-access.md を参照する。

前提

• 依存Issueの着手判定（このIssue自体が着手可能か）は解決済みであり、再確認は不要
• ただしこれは「このIssueに向けた依存関係の解決状況」に限る。確認事項本文で個別に参照されているIssue/PR（例:「#1404はマージ済みか」）の現在の状態は解決済みとみなさず、実行ステップ2で別途検証する

責務

後述のパターンA〜E（E-1含む）の判定と、対応する処理のみを行う: cc-need-human-checkの付与（確認事項が未回答であること自体は付与理由にしない。「確認事項の委任原則」参照）／クローズ判断／cc-answer-issue-questionsの付与／cc-update-issueの付与／実装PRを分離すべきIssueのEpic化とサブIssueへの分割（cc-epic-issueの付与）／UI変更タスクのデザイン先行フローへの振り分け（cc-create-ui-designの付与。デザイン参照が明示済みのIssueと、新しいビジュアル判断を含まない軽微なUI変更のみ例外として実装へ進める）／cc-exec-issueの付与。

注意事項

• Issueに付いているラベルは絶対に外さないこと。gh issue editで--remove-labelは使用禁止
• トリガーラベル（cc-issue-created・cc-triage-scope）の除去はワーカー基盤側が本スキル完了時に行う。本スキルは遷移ラベル（cc-need-human-check・cc-answer-issue-questions・cc-update-issue・cc-exec-issue）を付与するのみで、既存ラベルの除去は行わない

実行モードの制約

本スキル固有のリスク: 本スキルは claude-task-worker の triage-created-issue ワーカー（cc-issue-created + cc-triage-scope ラベル）から自動起動され、ワーカーはスキルプロセスの同期完了を根拠にラベル遷移（cc-answer-issue-questions / cc-exec-issue の付与や Issue のクローズ）を進める。処理が未完のままターンを終えると、判定未確定のまま遷移ラベルが付与されず Issue が次のワーカーに引き継がれない（あるいは判定と異なるラベルが付与される）状態壊れが起きる。

実行ステップ

1. Issueのdescriptionとコメント履歴の確認

GitHub MCP が使える場合は issue_read（method: get。コメント取得は get_comments）を使う。以下は MCP 利用不可時のフォールバック。

gh issue view $0 --json body,labels,comments

3つの観点で読む。

• コメント履歴全体: 人の確認が必要なシグナル（議論の未決着、明示的な相談・承認依頼など）の有無。あわせて answer-issue-questions の回答試行の痕跡（固定マーカー ## 回答 を含むコメント、## 人間判断が必要な確認事項（自動回答不能） セクション）の有無
• 最後のコメント: 未回答の確認事項の有無。最後のコメントが以前の確認事項への回答である場合は、どの確認事項への回答かを対応付けて該当項目を回答済みとして扱う（有効性判定は「回答コメントの受け入れ原則」に従う）
• description: 未回答の確認事項（## 確認事項 セクション、「確認したいこと」「要確認」「TBD」などの未確定項目リスト）の有無。description側の未回答項目もパターンCの対象になる。ただし実装プラン中の「〜を確認する」といった作業手順は確認事項ではない（実行担当が作業として行うもの）

2. 確認事項内で参照されるIssue/PRの現在状態の検証

確認事項本文（最後のコメント・descriptionの両方が対象）で他のIssue/PRが参照されている場合（番号・URLでの言及、「依存Issue」「関連PR」等の表現を含む）、記述はスナップショット時点のものでその後クローズ・マージされている可能性があるため、鵜呑みにせず参照先の現在の状態を必ずghで取得する。

GitHub MCP が使える場合は Issue に issue_read（method: get）、PR に pull_request_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。

gh issue view <参照先のIssue番号> --json state,title
gh pr view <参照先のPR番号> --json state,title,mergedAt

得られた事実（例: 参照先がCLOSED/MERGED）は、次ステップの「事実確認で解消可能か」の判断材料に用いる。確認事項がIssue/PRを参照していなければスキップする。

3. 判定と処理

以下の優先順で判定する。

• コメント履歴全体から見た人間確認シグナル（確認事項の内容とは独立に判定）に該当する場合は、他の判定に先立ってパターンAとして処理し、以降の判定はすべて打ち切る。この「最初に該当したら以降は評価しない」排他ルールは、この人間確認シグナルの判定にのみ適用される
• 該当しない場合、パターンB（対応不要判断）を評価する。該当すればクローズして終了
• どちらにも該当しない場合、最後のコメントおよびdescriptionの確認事項を項目ごとに個別評価する。反証シグナルで解消済みの項目を除外したうえで（「反証シグナルで解消した項目の『未回答』集合からの除外」参照）、**未回答の項目が1つでも残っていれば原則パターンC（cc-answer-issue-questions）**であり、人間判断を要しそうに見えてもパターンAには倒さない（「確認事項の委任原則」参照）。該当すればそこで終了
• 確認事項がない、または全て回答済みなら、着手（パターンE）の前にパターンD（コメント履歴のdescription反映チェック）を評価する。未反映ならcc-update-issueを付与して終了し、反映済みで整合している場合に限りパターンFの評価へ進む
• パターンD通過後、パターンE-1・Eの前にパターンF（実装PRの分離＝Epic化）を評価する。該当すればIssueをEpic化してサブIssueを作成し、cc-exec-issueを付けずに終了する（UI変更の扱いは各サブIssueのトリアージで個別に判定される）
• パターンF非該当の場合、パターンE（cc-exec-issue）の前にパターンE-1（UI変更タスクの扱い）を評価する。UI変更タスクは、新しいビジュアル判断を含まない軽微なUI変更（E-1-a-2）の場合、すでにデザインが作成済みでdescriptionの## UIデザインにその参照（.penの実パス）が明示されている場合、または**uiDesign.enabled が true でない（デザイン先行フローが無効な）リポジトリの場合**にパターンEへ進み、それ以外はcc-exec-issueを付けずにcc-create-ui-designを付与して終了する（デザイン先行フロー一本。実装PRでの.pen編集経路はどのケースでも存在しない）。UI変更に該当しないIssueはそのままパターンEへ進む
• 各トリアージ実行で付与する遷移ラベル（cc-need-human-check / cc-answer-issue-questions / cc-update-issue / cc-epic-issue / cc-create-ui-design / cc-exec-issue）は同一Issueに複数付与しない。特にcc-need-human-checkとcc-answer-issue-questionsは同時に付与しない

判定の前提: 確認事項の委任原則（cc-need-human-check の濫用防止）

本スキルは確認事項に答える主体ではない。回答は answer-issue-questions の責務であり、本スキルの役割は「誰に渡すか」を決めることだけ。次の二段構えを厳守する。

1. 未回答の確認事項がある → まず cc-answer-issue-questions（パターンC）へ委任する。gh やコードベース調査だけでは答えが決まらないように見える項目でも cc-need-human-check を付けない。本スキルは確認事項の調査（コード探索・ドキュメント精査・外部リンク参照）を行わないため「gh で判断できない＝人間判断が必要」ではなく、実際には answer-issue-questions の調査で解消する項目が大半。ここで人へ差し戻すと、答えのある問いを人に投げて着手を止めることになる
2. cc-need-human-check（パターンA経路2）へ上げるのは、answer-issue-questions が回答を試みてなお解消できなかったことを確認できた場合のみ。判定は推測ではなくコメント履歴上の痕跡で行う（該当条件は経路2に定義）

なお、answer-issue-questions の実行後は cc-update-issue → update-issue を経て本スキルが再実行されるため、委任 → 再トリアージの往復は1回で決着し、無限ループにはならない。

再委任のループ防止: 過去に ## 人間判断が必要な確認事項（自動回答不能） へ列挙された項目と実質的に同一の問い（表現が違っても内容が同じなら同一とみなす）が、その後の ## 確認事項 コメントやdescriptionに再掲されている場合、それは新しい未回答項目ではなく引き渡し済みの項目である。「回答試行を受けていない未回答項目」として数えず、経路2の対象（＝cc-need-human-check）として扱う。

判定の前提: 回答コメントの受け入れ原則

確認事項が「回答済み」か、その回答が意思決定として有効かは、コメントの内容だけで判定する。以下を理由に回答を無効扱いしてはならない。

• 投稿者のアカウントが誰であるか。Issue作成者・依頼者・過去の回答者と異なるアカウントからの回答も、本スキルが使用するgh認証と同一アカウントからの回答も等しく有効。チーム運用では複数の人間が各自のアカウントでコメントし、自動化も人間と同じアカウントで動くため、アカウント名から「依頼者本人の意思決定か」は原理的に判別できない。投稿者ベースで却下すると、正当な回答を無視して同じ確認を要請し続けるループが生じる
• 回答が簡潔であること。確認事項の後に投稿された、確認内容を肯定形で言い換え・引用するコメント（「〜という理解でよい」「〜で問題ない」「はい、その方針で進めてください」など）は、短くても意思決定の回答として扱う。文末が疑問形（「〜でよいか？」「〜ですか」）でない限り、確認文の再掲は再質問ではなく承認の表明と解釈する

特に、過去のトリアージがcc-need-human-checkを要請した後に新しいコメントが投稿された状態での再実行は、案内どおりの人間確認フロー（回答をコメント→cc-need-human-checkラベルを外す→トリアージ再開）が完了した正常な状態である。新しいコメントが確認事項に内容面で答えているなら、投稿者や形式を理由に疑い直したり同じ確認を再要請したりせず、その回答を確定事項として次の判定（パターンD等）に進む。

パターンA: 人の確認が必要と判断できる場合（最優先）

このラベルは「自動化を一旦止めて人に渡す」セーフティバルブ。曖昧・影響の大きい判断を自動で押し進めると手戻りや事故につながるため、確信が持てない・人間の意思決定が要るケースはここで止める。該当経路は次の2つで、最終的な処理内容（コメント＋ラベル付与）はどちらも同一。

経路1: コメント履歴全体の人間確認シグナル（確認事項の内容とは独立に判定）

判定基準（下記リストは例示であり、当てはめではなくこの基準で判定する）: コメント履歴を最新まで読んだとき、人間の意思決定・承認・議論の決着を待っている状態がまだ残っているか。残っているなら該当する。典型例（リストにない形でも上の基準を満たせば該当させる）：

• 人間同士の議論が未決着、または意見が対立したまま残っている
• 人間が明示的にレビュー・承認・相談を求めている（「要相談」「確認お願いします」「@担当者 確認して」など）
• 確認事項への回答が試みられたが、回答が内容面で確認事項を解消できない応酬が続き堂々巡りになっている。堂々巡りの根拠にしてよいのは実質的な議論の応酬だけで、本スキル自身の過去のトリアージ結果コメントの繰り返しや、ラベルの現状が過去のトリアージコメントの記載と食い違っていること（人間がフローどおりラベルを外して再開した痕跡）は根拠にしない。最新コメントにまだ評価されていない回答が含まれる場合は前進でありループではない
• AI自身がクローズすべきか着手すべきか確信を持てない。ただし確信の持てなさが特定の確認事項の内容に起因する場合は該当させない（answer-issue-questions へ委任すれば解消しうるためパターンCで扱う）。該当するのは、確認事項とは独立に Issue 全体の扱い（着手すべきか、そもそも対応すべきか）が定まらない場合に限る

該当した場合は確認事項の内容を精査するまでもなくパターンAとして処理し、以降（経路2を含む）の判定はすべて打ち切る。

経路2: answer-issue-questions が解消できなかった確認事項の引き上げ

「確認事項の内容を見て人間判断が必要そうだ」という本スキルの推測では成立しない。 該当条件（すべて満たすこと）:

1. コメント履歴に ## 回答 を含む回答コメントが存在する（answer-issue-questions が実行済み）
2. その回答コメントに ## 人間判断が必要な確認事項（自動回答不能） セクションがあり、1件以上の確認事項が列挙されている
3. その回答コメント以降に、列挙された項目へ内容面で答える人間のコメントが投稿されていない（投稿されていれば「回答コメントの受け入れ原則」に従い回答済みとして扱う）
4. 列挙された項目が後述の反証シグナルに該当しない（該当する項目は事実確認で解消可能として扱い、対象から外す）

回答コメントが存在しない、または未回答項目が上記セクションに列挙されていない場合はこの経路に該当せず、未回答項目が残っていればパターンC（cc-answer-issue-questions）へ回す。

反証シグナル（人間判断が必要とは判断しない条件）: 以下のいずれかに該当する場合、answer-issue-questions が「自動回答不能」と列挙していても、その項目は解消済みとして扱い経路2の対象から外す。回答試行前の一次トリアージで「未回答の確認事項」の集合を絞り込む際にも同じ基準を適用する。

• Issue本文（実装プラン等）がすでに根拠付きの結論を示しており、確認事項がその結論を裏付け・再確認するだけの内容である
• 本スキルがステップ2のgh確認で当該項目の答えを実際に確定できた（推測ではなく取得済みの事実で決まる）。「コードベース調査をすれば解消できそう」という見込みはこのシグナルに該当しない — その項目は解消済みではなく、委任すべき項目としてパターンCで扱う
• ステップ2で検証したIssue/PRの現在状態から、確認事項の前提となる事実がすでに判明している
• 確認事項が「独立した既知の不具合の分離・後回し」を問うもので、かつ次をすべて満たす場合:
  1. Issue本文または直前のAI回答が根拠付きの推奨結論を示している
  2. 後回し対象が correctness / security / データ移行 / 課金 / 不可逆性 / 外部公開に影響しない（残存被害がUXグリッチ等に限定される）
  3. 相互参照付きの後続Issueを自動起票して失念リスクを緩和できる → この項目は事実確認で解消可能（＝推奨案で進行可）として扱い、cc-need-human-check を付与しない。ただし後続Issueの起票がまだなら、パターンAへの該当を打ち切る前に「反証シグナル4項目目該当時の後続Issue起票」の手順を実行すること

反証シグナルで解消されない列挙項目が1件以上残り、かつそれ以外に「まだ回答試行を受けていない未回答の確認事項」が存在しない場合に、経路2としてパターンAに該当する。回答試行を受けていない未回答項目が残っている場合は、先にそれらを委任するためパターンCで扱う。

反証シグナルで解消した項目の「未回答」集合からの除外

反証シグナルに該当し事実確認で解消可能と判定した項目は、以降のパターンC・D・Eの判定で数える「未回答の確認事項」の集合に含めない（以降「未回答の確認事項」は常にこの除外後の集合を指す）。

• 反証シグナル1〜3項目目に該当した項目は、判定した時点で直ちに「解消済み」として扱う
• 反証シグナル4項目目（carve-out）に該当した項目は、後続Issue起票の手順（起票・本文相互参照・重複検出用マーカー記録）がすべて完了して初めて「解消済み」として扱う。手順が未完了・いずれかのステップが失敗した場合は解消済みとみなさず、ステップ6の規定に従ってその場でパターンA（cc-need-human-check）の人間確認フローに委ね、パターンC・D・Eの判定には進めない

反証シグナル4項目目該当時の後続Issue起票

反証シグナル4項目目に該当し、後回し対象の不具合を追跡する後続Issueがまだ無い場合、本スキル自身が以下の手順で起票する。

トリガーラベルはAND条件であり競合しない: 後続Issueにはcc-triage-scopeのみを付与しcc-issue-createdは付けない。triage-created-issueワーカーは両ラベルが揃って初めてマッチする（src/workers/triage-created-issue.ts、--label複数指定のAND一致）ため、cc-issue-createdが無い間は後続Issueが同ワーカーに拾われず、create-issueワーカー（トリガーラベルcc-triage-scope単独）との競合は起きない。

1. 起票前に、分離元Issueのコメント履歴を固定マーカー ## 後続Issue起票済み（carve-out） で走査する。ヒットした場合は起票をスキップし、記載されている既存の後続Issue番号を再利用する。

2. ヒットしない場合、gh-compat.sh create-issue で起票する（gh issue create と GitHub MCP の issue_write は使わない。前者は GraphQL 経由でクラウドでは 403 になり、後者は labels / assignees の渡し忘れで黙って欠落する）。初期ラベルはcc-triage-scopeのみ（cc-issue-createdを付けるとcreate-issueワーカーの分析フェーズをスキップし、実装プランのない素のdescriptionのままtriage-created-issue→exec-issueに流れてしまう）。Assignee には実行中のユーザー（@me）を付ける（ワーカーはラベルと Assignee の両方で Issue を拾うため、欠けると後続Issueが放置される）。blockedBy関係は付与しない（-is:blockedによりワーカーの検索クエリから除外され、分離元Issueがクローズするまで放置されるため）。

   bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh create-issue \
     --title "<後回しにした不具合のタイトル>" \
     --label "cc-triage-scope" \
     --assignee "@me" \
     --body-file - <<'EOF'
   <不具合の内容。分離元Issue #$0 を参照する旨を明記>
   EOF
   

3. 起票直後・分離元Issueへのコメント投稿前に、もう一度同じ固定マーカーで分離元Issueのコメント履歴を走査する（並行実行で他プロセスが同じ起票を行っていないかの再確認）。既存の後続Issue番号がすでに記録されていた場合、直前に自分が作成した後続Issueは重複とみなしgh-compat.sh close-issue <番号> not_plannedでクローズしたうえで、既存番号を採用してステップ4に進む。

4. 分離元Issue・後続Issueそれぞれの本文（description）に相手のIssue番号を明記して相互参照する。本文更新とマーカーコメント投稿の2段階で行う：

   • 後続Issue側はステップ2の--bodyで参照済み
   • 分離元Issue側は既存descriptionを保持したまま末尾に参照を追記する。exec-issueなど後続処理はdescriptionのみを読むため、コメントだけでは本文に参照が残らない

   固定パス（例: /tmp/issue-$0-body.md）は同一Issueへの並行実行で衝突しうるためmktempで一意な一時ファイルを確保する。viewとeditの間の外部更新に備え、edit直前に本文を再取得し、(a) 追記予定の参照文言がすでに含まれていないか、(b) このステップ開始時点の内容と一致しているかを検証してから書き戻す：

   GitHub MCP が使える場合は本文取得に issue_read（method: get）を使う。以下は MCP 利用不可時のフォールバック。

   BODY_FILE="$(mktemp -t issue-$0-body-XXXXXX.md)"
   trap 'rm -f "$BODY_FILE"' EXIT
   
   ORIGINAL_BODY="$(gh issue view $0 --json body --jq .body)"
   REFERENCE_LINE='既知の不具合の分離・後回し（carve-out）として、後続Issue #<後続Issue番号> を起票済み。'
   printf '%s\n\n---\n\n%s\n' "$ORIGINAL_BODY" "$REFERENCE_LINE" > "$BODY_FILE"
   
   # edit直前に最新本文を再取得し、無条件の上書き（ロスト・アップデート）を避ける
   LATEST_BODY="$(gh issue view $0 --json body --jq .body)"
   if grep -qF '既知の不具合の分離・後回し（carve-out）として、後続Issue #' <<<"$LATEST_BODY"; then
     : # 他プロセスが既に参照を追記済み。重複追記せずステップ5へ進む
   elif [ "$LATEST_BODY" != "$ORIGINAL_BODY" ]; then
     : # ステップ1〜3で確認した内容と矛盾する外部変更を検知。carve-outとしての進行を中止し、ステップ6のパターンAへフォールバックする
   else
     gh issue edit $0 --body-file "$BODY_FILE"
   fi
   

   いずれの分岐でも「参照文言が本文に反映されている」（既存分含む）ことを確認できて初めて次に進んでよい。矛盾検知の分岐に入った場合はステップ6に従う。

5. 本文更新に続けて、重複検出・通知用の固定マーカー（後続Issue番号入り）を分離元Issueへコメント投稿する。

   gh issue comment $0 --body-file - <<'EOF'
   ## 後続Issue起票済み（carve-out）
   
   既知の不具合の分離・後回しとして、以下の後続Issueを起票しました。
   
   - 後続Issue: #<後続Issue番号>
   
   本Issueは推奨案のとおり進行します。
   EOF
   

6. ステップ2〜5（起票・本文更新・マーカーコメント投稿）のいずれかが失敗した場合、carve-outとして進行する前提が欠けたことになるため、この項目を事実確認で解消可能な項目として扱うのを中止する。パターンA本来の人間確認フロー（「該当する場合の処理」節）に戻り、失敗した操作の内容とエラーを「自動で進められない理由」に明記してcc-need-human-checkを付与する。ステップ4の本文再取得で検知した外部変更との矛盾も、本文更新が完了しなかった＝ステップ4の失敗として同じくパターンAへフォールバックする。

該当する場合の処理

経路1・経路2のいずれかに該当する場合、以下を実行して終了する。他のラベル（クローズ・cc-answer-issue-questions・cc-update-issue・cc-exec-issue）は付与しない。

1. 人が確認・判断すべき内容を整理した構造化コメントを投稿する。以下テンプレートを gh issue comment $0 --body-file - にヒアドキュメントで渡す（Markdownの体裁を保つため）：

   ## 人の確認・判断のお願い（cc-need-human-check）
   
   自動トリアージは、このIssueを自動で先に進められないと判断しました。以下の確認・判断をお願いします。
   
   ## 確認・判断していただきたいこと
   
   1. **<人がそのまま回答・決定できる具体的な問い>**
      - 背景: <経緯・現状の要約。ステップ2で検証した参照Issue/PRの最新状態など、判断に必要な事実を含める>
      - 選択肢: <想定される選択肢と、それぞれを選んだ場合の影響。選択肢を想定できない場合はこの行を省略>
      - 自動で進められない理由: <事実確認（コードベース調査・`gh`コマンド）では解消できない理由。経路2の場合は `answer-issue-questions` が調査したうえで自動回答不能と判定した旨と、その回答コメントに記載された理由を引用する>
   
   ## 根拠となるコメント
   
   > <判断の根拠となったコメントの引用>
   
   （<投稿者>のコメントより）
   
   ## ご確認後の進め方
   
   1. 上記への回答・決定内容をこのIssueにコメントしてください（どなたのアカウントから投稿いただいても構いません）
   2. `cc-need-human-check` ラベルを外してください。自動トリアージが再開され、いただいたコメントを踏まえて次のステップへ進みます
   

   テンプレートの記載ルール：

   • 「確認・判断していただきたいこと」は、読み手がそのまま回答できる問いの形で書く（「〜という方針でよいですか？」「A案とB案のどちらにしますか？」など）。「議論が未決着です」のような状態説明だけで終わらせない。経路1で該当した場合も「何が未決着で、誰の・何に対する回答があれば先へ進めるのか」を問いの形に変換する
   • 項目が複数ある場合は番号を分けて列挙する（1つの項目に複数の論点を詰め込まない）
   • 各項目はそのコメント単体で判断材料が揃うように書く（「上記の件」だけの参照など、Issue本文や過去コメントの読み直しが必要な書き方をしない）
   • 「根拠となるコメント」には判断の根拠とした実際のコメントを引用し、誰の発言かを添える（複数可）。経路2の場合は ## 人間判断が必要な確認事項（自動回答不能） セクションの該当行を必ず引用に含める（回答試行が実際に行われた証跡として残すため）

2. cc-need-human-checkラベルを付与する

   gh issue edit $0 --add-label "cc-need-human-check"
   

パターンB: Issueの内容が対応不要と判断できる場合

以下のいずれかに該当する場合：

• すでに別のIssueやPRで対応済み・重複している
• 要件や仕様の変更により不要になった
• 誤って起票されたIssueである
• その他、明らかに対応不要と判断できる

以下を実行する：

1. Issueにクローズ理由をコメントで記載する

   gh issue comment $0 --body "<クローズ理由の説明>"
   

2. コメント投稿の成功を確認してから、Issueをcloseする（コメントに失敗した場合はクローズしない。説明なしのクローズを残さないため）。gh issue close は GraphQL 経由でクラウドセッションのゲートに掛かるため使わない

   bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh close-issue $0 not_planned
   

パターンC: 確認事項への回答が必要な場合

最後のコメントまたはdescriptionに、反証シグナルによる解消（carve-outはフォローアップ完了分のみ解消済み扱い）を除いてもなお回答が記載されていない確認事項がある場合（パターンA経路2に該当したケースを除く）：

gh issue edit $0 --add-label "cc-answer-issue-questions"

これが未回答の確認事項に対する既定の処理である。 項目の内容が人間判断を要するように見えてもcc-need-human-checkは付与しない（「確認事項の委任原則」）。人間判断が本当に必要かの判定と、その旨の明示は、コードベース・ドキュメント・外部リンクまで調査する answer-issue-questions の回答フェーズに委ねる。

description側にのみ確認事項が残っている場合も同じ処理で構わない（answer-issue-questions はコメントとdescriptionの両方を回答対象にする）。その際は、どの確認事項を委任対象と判断したかが後から追えるよう、ラベル付与に先立って対象項目を列挙したコメントを1件投稿する。

パターンD: コメント履歴で確定した内容がdescriptionに未反映の場合

パターンA〜Cに該当せず着手可能に見えても、実行担当（executor）はdescriptionを唯一の入力として作業するため、コメント履歴で確定した実質的な内容（確認事項への回答、合意された方針・仕様の変更、スコープや制約の追加・修正など）がdescriptionに未反映だと、その決定が実行時に取りこぼされる。着手前に、descriptionが確定内容を過不足なく自己完結的に表現できているかを検証する。

反映対象に含めないもの：

• 未回答の確認事項そのもの（パターンCで扱う。回答が出た後に反映対象となる）。ただし反証シグナルにより解消済みと判定された項目（carve-outはフォローアップ完了分のみ）は確定済み内容として扱い、その結論（および該当する場合は起票した後続Issue番号）の反映有無をチェック対象に含める
• 本スキルやワーカーが付与したトリアージ用コメントや、/gemini reviewのような処理上のノイズコメント
• 雑談・相槌など、Issueの内容に影響しないコメント

上記を除いた確定内容のうち、descriptionに書かれていない、または古いまま食い違っている項目が一つでもあればdescriptionが陳腐化しているとみなし、着手（パターンE）に進めず以下を実行して終了する。他のラベル（cc-exec-issueなど）は付与しない。

1. descriptionに未反映と判断した内容を、根拠となるコメントを引用しつつ簡潔にコメントする

   gh issue comment $0 --body "<descriptionに未反映と判断した内容の説明>"
   

2. cc-update-issueラベルを付与する

   gh issue edit $0 --add-label "cc-update-issue"
   

確定内容がすべてdescriptionに反映済みで整合している場合は、パターンE-1に進む。

パターンE-1: UI変更タスクの扱い（デザイン先行フローへの振り分け）

パターンA〜Dに該当せず着手可能でも、UIを変更するタスクはコードだけが変わってデザインファイル（.pen）が置き去りになると、デザインと実装が恒久的に食い違う。

.pen の新規作成・編集は、必ず cc-create-ui-design のデザイン先行フローで行う。 実装PR（exec-issue）で .pen を編集する経路は存在しない。デザインのみのPRを作ってレビュー・マージしたうえで実装へ進ませることで、デザインの合意と実装が常に分離された状態を保つ。

したがってUI変更タスクは、既にデザインが作成済みで description にその参照が明示されている場合と、新しいビジュアル判断を含まない軽微なUI変更（E-1-a-2）を除き、すべてデザイン先行フローへ振り分ける（cc-create-ui-design を付与して終了。cc-exec-issue は付与しない）。ただしデザイン先行フローが無効なリポジトリ（uiDesign.enabled が true でない）では同フローのワーカーが起動しないため、実装（パターンE）へ進める。この場合も exec-issue は .pen を編集しない。例外の定義と分岐は E-1-b に定める。

E-1-a. UI変更タスクかの判定

UI変更タスクと判定する基準（いずれかに該当）

• 画面・ページ・モーダル・フォーム等の新規追加
• 既存画面のレイアウト・情報設計・視覚表現の変更（要素の追加/削除/並び替え、状態表示の追加など）
• 再利用コンポーネントの新規作成、および見た目に影響する変更

UI変更タスクと判定しない基準（該当すればそのままパターンEへ）

• サーバーサイド・データモデル・バッチ・CI・ドキュメント・テストのみの変更
• ログ・計測の追加のみなど、レイアウトにも視覚表現にも影響しない修正
• リポジトリにフロントエンド実装が存在しない

UI変更かどうかの判定が割れる場合は「UI変更である」側に倒す。 デザインPRが空振りだった場合のコストはリードタイム1PR分にとどまる一方、UI変更を素通しするとデザインファイルが更新されないまま実装だけが進み、以降のデザインの正しさが失われる。

E-1-a-2. 軽微なUI変更の除外（デザイン先行フローのスキップ）

UI変更タスクであっても、新しいビジュアル判断を一つも含まない変更はデザイン先行フローを通しても .pen に反映すべき差分が生まれない（デザイン作成セッションが「デザイン不要」と判定して戻ってくるだけで、1ワーカー分のリードタイムとトークンを消費する）。次の基準をすべて満たす場合は「軽微なUI変更」とみなし、cc-create-ui-design を付与せずそのままパターンEへ進む。

適用の前提（ラベル状態の確認を先に行う）: 本判定は E-1-b の分岐1・分岐2に該当しない場合にのみ適用する。すなわち、Issueに cc-create-ui-design / cc-ui-design-pr-created / cc-ui-design-ready のいずれかが付いている場合は、軽微かどうかを判定せず E-1-b の分岐へ進む。デザイン先行フローが既に走っている（分岐1）Issueへ cc-exec-issue を付けるとデザインPRと実装が二重進行し、cc-ui-design-ready があるのに参照が無い異常（分岐2）を軽微判定で素通しすると、合意済みデザインが実装に届かないまま実装が走る。cc-ui-design-ready が付いていて参照も生きている場合は E-1-b の例外1に該当するため、いずれにせよ本判定を経ずにパターンEへ進む。

軽微と判定する条件（すべて満たすこと）

1. 新規の画面・ページ・モーダル・タブ・セクションの追加を含まない
2. 既存要素のレイアウト・情報設計を変更しない（並び順・階層・グリッド・余白構成を変えない）
3. 新規の再利用コンポーネントを作らない
4. 新しい色・タイポグラフィ・アイコン・イラスト・パターンなど、既存のデザイントークン／既存デザイン済みコンポーネントの範囲外の視覚表現を導入しない

上記を満たす典型例

• 文言・ラベル・プレースホルダー・エラーメッセージの差し替え
• 既存デザインに定義済みの状態（disabled / loading / エラー表示など）を、未実装の箇所へ適用する
• 表示条件の変更のみ（既存要素の出し分け・権限による非表示など）で、要素そのものの見た目を変えない
• デザインから外れている実装をデザイン側の定義に合わせ直す修正（表示崩れ・トークン不一致のバグ修正）
• 既存デザイン済みコンポーネントをそのまま使った置き換え（独自実装 → 共通コンポーネント化で見た目が変わらないもの）

軽微かどうかの判定が割れる場合は「軽微ではない」側に倒す（デザイン先行フローへ振り分ける）。ここで誤って軽微に倒すと .pen の編集経路が無いまま実装が進み、デザインと実装が恒久的に食い違う。

軽微と判定した場合は、判定根拠を人が事後に追えるよう次のコメントを残してからパターンEへ進む。

gh issue comment $0 --body-file - <<'EOF'
## UIデザイン先行フローをスキップしました（軽微なUI変更）

## 判定理由
<新しいビジュアル判断を含まないと判断した根拠。E-1-a-2 の4条件それぞれについて、なぜ該当しないかを具体的に>
EOF

E-1-b. デザイン先行フローへ移行しない例外

例外は2つだけである。いずれも descriptionの ## UIデザイン セクションの内容で判定する。

例外1: すでにデザインが作成済みで、descriptionにどのデザインを参照して実装するかが明示されている場合。 具体的には、## UIデザイン セクション内に、</> を含まない .pen で終わる実パス行が存在すること（src/workers/ui-design.ts の hasDesignReference() と同一のテキスト判定基準。見出しのみ・未置換プレースホルダー行しか無いセクションは「実パス行なし」として扱い、例外に該当しない）。

この場合は既に合意済みデザインが実装の参照元として届いているため、追加処理なしでそのままパターンEへ進む（実装セッションは .pen を編集せず、デザインを参照元として実装する）。

例外2: create-ui-design が「デザイン不要」と判定済みの場合。 ## UIデザイン セクション内に UIデザインは不要 で始まる行があること（create-ui-design が書き込む固定マーカー）。デザイン先行フローを一度通した結果として「このIssueは .pen を必要としない」と判定が済んでいるため、そのままパターンEへ進む。再度 cc-create-ui-design を付けてはならない（同じ判定を繰り返すだけで、Issueが実装へ進まなくなる）。

上記のいずれにも該当しない場合は、下記の分岐に従って処理する。 「デザイン検討の余地が無い（descriptionが既に具体的なUI仕様を持つ）」「リードタイムを伸ばしたくない」はいずれも例外の理由にならない（例外は、E-1-a-2 の4条件をすべて満たす軽微なUI変更と、分岐3の uiDesign.enabled が true でないリポジトリだけ）。.pen の編集経路が他に無いため、ここで例外を作るとデザインファイルが更新されないまま実装だけが進む。

分岐1・分岐2は E-1-a-2（軽微なUI変更）の判定より優先する（E-1-a-2 の「適用の前提」を参照）。分岐3へ落ちてくるのは、デザイン関連ラベルが1つも付いておらず、かつ E-1-a-2 で軽微と判定されなかったIssueである。

分岐1: デザイン先行フローが既に進行中の場合

Issueに cc-create-ui-design または cc-ui-design-pr-created が付いている場合、フローは既に走っている。ラベルを一切付与せず（cc-exec-issue も cc-create-ui-design も付けない）、その旨を報告して終了する。

分岐2: cc-ui-design-ready が付いているのにデザイン参照が無い場合

デザイン合意済みを示すラベルがあるのに description の ## UIデザイン が実パス行を持たない状態は、人が description を書き換えて参照を消した、apply-ui-design が途中で壊れた等の異常であり、自動では復旧できない（再デザインさせると合意済みデザインと二重になる）。パターンAの人間確認フロー（cc-need-human-check）で処理し、「自動で進められない理由」に本状況を、「確認・判断していただきたいこと」に次の復旧手順を書く。

• デザイン参照を自動で再生成する場合: cc-need-human-check と cc-ui-design-ready を外し、cc-ui-design-pr-created を付け直す（apply-ui-design がデザインPRを再検出してdescriptionを再生成する）
• デザインなしで実装を進めてよい場合: descriptionの ## UIデザイン セクションに参照する .pen の実パスを記入する

分岐3: それ以外（デザイン未作成 / 参照未記載）

worktree直下の claude-task-worker.json の uiDesign.enabled を確認する。

jq -r '.uiDesign.enabled // false' claude-task-worker.json 2>/dev/null || printf 'false\n'

（ワーカー側のconfig.tsが起動時に読むファイルと同一の真実源にするため、必ずworktree内のローカルファイルを読む。リモートをgh apiで読み直すと二重化して食い違いうるため行わない。ファイルが無い・読めない・不正JSONでjqが非ゼロ終了する場合も、フォールバックのprintfで確実にfalse扱いとする）

• true の場合: E-1-c の処理でデザイン先行フロー（cc-create-ui-design）へ振り分ける

• true でない場合: このリポジトリではデザイン先行フローのワーカーが起動せず、cc-create-ui-design を付けても誰も拾わずIssueが停止する。そのままパターンE（cc-exec-issue）へ進めて実装させる。実装セッション（exec-issue）はこのケースでも .pen を編集しないため、コードのみが変更されデザインファイルは現状のままになる。人が状況を把握できるよう、git ls-files '*.pen' の出力が1件以上ある場合はパターンEのラベル付与に加えて次のコメントを残す（descriptionへ実装PRで .pen を編集させる指示は書かない）

  gh issue comment $0 --body-file - <<'EOF'
  ## デザインファイルは更新されません（UIデザイン先行フローが無効）
  
  本IssueはUIを変更するタスクですが、`claude-task-worker.json` の `uiDesign.enabled` が `true` ではないため、デザイン先行フロー（`cc-create-ui-design`）へ振り分けられません。`.pen` の編集は同フロー専任で実装PRでは行わないため、このまま実装するとコードのみが変更され、デザインファイルは現状のままになります。
  
  デザインも更新する場合は、`claude-task-worker.json` の `uiDesign.enabled` を `true` にしたうえで、`cc-exec-issue` を外して `cc-create-ui-design` を付け直してください。
  EOF
  

E-1-c. デザイン先行フローの処理（E-1-b 分岐3・uiDesign.enabled が true の場合）

1. 判定理由をIssueにコメントする（人が事後に判断を追えるようにする）

   gh issue comment $0 --body-file - <<'EOF'
   ## UIデザイン先行フローへ振り分けました（cc-create-ui-design）
   
   ## 判定理由
   <UI変更タスクと判断した根拠。対象画面・変更内容を具体的に>
   
   ## この後の流れ
   1. `create-ui-design` がPencilでデザインを作成し、デザインのみのPRを作ります
   2. デザインPRは通常のPRと同じフロー（`triage-pr`）でレビュー・マージされます
   3. マージ後に `apply-ui-design` がこのIssueのdescriptionへデザイン参照を追記し、実装（`cc-exec-issue`）へ進みます
   
   デザインが不要と判断された場合は、`cc-ui-design-ready` が付いてそのまま実装へ進みます。
   EOF
   

2. cc-create-ui-designラベルを付与する。cc-exec-issueは付与しない（デザインPRのマージ後にapply-ui-designが付与する）

   gh issue edit $0 --add-label "cc-create-ui-design"
   

手動オプトイン/オプトアウト

• 人が cc-create-ui-design を直接付ければ、トリアージ判定を経ずにデザイン先行フローへ入れる
• デザイン先行フローを通さずに実装へ進めたい場合は、descriptionの ## UIデザイン セクションに参照する .pen の実パスを記入する（E-1-b の例外に該当し、そのままパターンEへ進む）。cc-ui-design-ready ラベルだけを手で付けても例外にはならず、分岐2により cc-need-human-check になる

パターンF: 実装PRを分離すべき場合（Epic化とサブIssueへの分割）

パターンD通過後（確認事項が解消し、descriptionが最新の確定内容を反映している状態）に評価する。1つのPRにまとめるべきでないIssueを、breakdown-issues の「既存IssueをEpicに格上げする」経路と同じ形（親Issueに cc-epic-issue、子をsub-issueとして紐付け）へ変換する。以降は既存のEpicフロー（サブIssueは cc-epic-<本Issue番号> ブランチへPRを出し、全サブIssue完了後に epic-issue ワーカーが Epic PR を作る）に乗る。

適用しない場合（該当したらパターンE-1へ進む）

• 本Issueが既に parent を持つ（gh-compat.sh issue-parent $0 が番号を返す）。Epic ブランチは1階層のみを前提にしているため、サブIssueをさらにEpic化しない
• 本Issueに既に cc-epic-issue が付いている

判定基準

次の (1) と (2) を両方満たす場合に該当する。規模の大小（「大きい」「重い」）だけでは該当させない。

1. descriptionの ## 要件 / ## 実装プラン が、単独でマージしても既存の動作を壊さない変更単位に2つ以上分けられる
2. 次のいずれかに当てはまる
   • 単位間に「先にマージされている必要がある」順序がある（例: スキーマ・マイグレーション → それを使うコード、API追加 → クライアント側の利用、共通基盤の導入 → 各利用箇所への適用）
   • 単位どうしが互いに独立した機能・画面・サブシステムを対象にしており、1PRにまとめるとレビューで論点が混ざる
   • descriptionが複数の独立した成果物（別々に完了判定できるもの）を求めている

判定が割れたら分割しない（パターンE-1へ進み、従来どおり1PRで実装する）。分割は後から統合するより戻しにくいため。

処理

1. 冪等性の確認: 変更単位（タイトル付き）を先に確定させ、本Issueの既存sub-issueを取得する（gh api repos/{owner}/{repo}/issues/$0/sub_issues --jq '.[] | {number, title}'）。既存sub-issueはタイトルで変更単位と照合し、一致したものは新規作成せず採用する。既存sub-issueがあってもステップ4へ飛ばず、ステップ2〜4を「未完了の操作だけを行う」形で順に実行する（前回の途中失敗からの再実行で、子の重複作成や blockedBy の設定漏れを残さないため）
2. 照合で見つからなかった変更単位ごとにサブIssueを作成し、作成のたびに直ちに本Issueへ紐付ける（作成と紐付けの間で失敗すると、親を持たない子は次回の照合で見つからず重複作成されるため、その窓を1件分に狭める）。gh-compat.sh create-issue を使う（gh issue create / MCP の issue_write は使わない。理由は「反証シグナル4項目目該当時の後続Issue起票」と同じ）。作成時はラベルを付けず、Assignee は @me のみ指定する（cc-triage-scope は create-issue ワーカーのトリガーのため、親子関係・blockedBy の設定前に付けると、親なし・未ブロックのIssueとして拾われ、デフォルトブランチ起点・順序無視で処理されうる。付与はステップ4で行う）

   bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh create-issue \
     --title "<変更単位のタイトル>" \
     --assignee "@me" \
     --body-file - <<'EOF'
   ## 概要
   Epic #$0 の一部。<この単位で行う変更>
   
   ## 要件
   <親Issueの要件・実装プランのうち、この単位が担う部分を転記（親の確定内容を書き換えない）>
   
   ## 完了条件
   <この単位を単独でマージできる状態>
   EOF
   bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh add-sub-issue $0 <作成した子>
   

3. 順序がある単位には blockedBy を貼る（先行単位が close されるまで後続が exec-issue に拾われないようにするため）。再実行時は gh-compat.sh issue-deps <後続の子> の blockedBy に先行の子が含まれていないものだけを貼る

   bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh add-blocked-by <後続の子> <先行の子>
   

   本Issue（親）とサブIssueの間には blockedBy を貼らない（親はサブIssueが全て閉じるまで close されないため、サブIssueが永久に拾われなくなる）
4. 全サブIssue（採用した既存の子を含む）に cc-triage-scope を付ける。ステップ2・3がすべて成功してから付ける（理由はステップ2のとおり）。add-label は冪等なので再実行で付け直してよい

   bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh add-label <子1> cc-triage-scope
   bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh add-label <子2> cc-triage-scope
   

5. 本Issueに cc-epic-issue を付ける（sub-issue の紐付けが済んでから付ける。先に付けると、紐付け途中の部分集合だけで epic-issue ワーカーの完了判定が走りうる）

   bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh add-label $0 cc-epic-issue
   

6. 本Issueへマーカーコメントを投稿する（既に固定マーカー ## Epic化しました（サブIssueへ分割） のコメントがあれば投稿しない）

   gh issue comment $0 --body-file - <<'EOF'
   ## Epic化しました（サブIssueへ分割）
   
   ## 分割した理由
   <判定基準のどれに該当したか、変更単位の切り方>
   
   ## サブIssue
   - #<子1>: <タイトル>
   - #<子2>: <タイトル>（#<子1> の完了後に着手）
   
   各サブIssueは通常のフロー（分析 → トリアージ → 実装）で処理され、全て完了すると Epic PR が作成されます。
   EOF
   

cc-exec-issue は付与しない（本Issue自体は実装しない）。ステップ2〜6のいずれかが失敗した場合は、作成済みのサブIssueは残したまま（ステップ1の冪等性確認で再採用される。紐付け前に失敗した子は再採用されないため、その番号も理由に明記する）、パターンAの「該当する場合の処理」に従い、失敗した操作とエラーを「自動で進められない理由」に明記して cc-need-human-check を付与する。

パターンE: 着手準備が整っている場合

確認事項がない、または全ての確認事項に回答済み（反証シグナルにより解消済みと判定された項目を含む。carve-outはフォローアップ完了分のみ）であり、かつパターンDでコメント履歴の確定内容がdescriptionに反映済みと確認できた場合、実行可能と判断してcc-exec-issueラベルを付与する：

gh issue edit $0 --add-label "cc-exec-issue"

ただしパターンE-1でUI変更タスクと判定した場合、本パターンへ進めるのは次の3ケースだけである。

• E-1-a-2 の4条件をすべて満たす軽微なUI変更（新しいビジュアル判断を含まないため .pen に反映すべき差分が無い）
• E-1-b の例外に該当する（descriptionの ## UIデザイン セクションに .pen の実パス行があり、参照すべきデザインが明示されている）
• E-1-b 分岐3で uiDesign.enabled が true でない（デザイン先行フローが無効なリポジトリ。デザインファイルは更新されないまま実装が進む）

分岐1（フロー進行中）・分岐2（cc-ui-design-ready があるのに参照が無い）に該当する場合、および分岐3で uiDesign.enabled が true の場合は本ラベルを付与しない。また、本ラベルを付与するどのケースでも、descriptionへ実装PRで .pen を編集させる指示を追記してはならない（.pen の編集経路はデザイン先行フローのみ）。