triage-created-issue

name	triage-created-issue
description	Triage a GitHub issue that already has the cc-issue-created label and is assumed to be ready to start. First inspect the comment history to decide whether human confirmation is needed (cc-need-human-check, highest priority); otherwise decide whether the issue should be closed as not needed, unanswered confirmation items remain (cc-answer-issue-questions), the description is stale relative to settled comment-history content and must be refreshed before execution (cc-update-issue), or it can move to execution (cc-exec-issue). Dependency checks are out of scope.
argument-hint	[Issue number]
hooks	{"Stop":[{"matcher":"","hooks":[{"type":"command","command":"node \"${CLAUDE_PLUGIN_ROOT}/scripts/stop-servers.mjs\""}]}]}

Triage Created Issue

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

Instructions

前提

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

責務

1. コメント履歴の精査による人の確認要否の判断とcc-need-human-checkラベルの付与
2. Issue内容の精査によるクローズ判断
3. 確認事項への未回答チェックによるcc-answer-issue-questionsラベルの付与
4. コメント履歴で確定した内容がdescriptionに未反映な場合のcc-update-issueラベルの付与
5. UI実装タスクと判定した場合のcc-create-ui-designラベルの付与（デザイン先行ワークフロー）
6. 着手準備が整っている場合の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 のクローズ）を進める。処理が未完のままターンを終えると、判定未確定のまま cc-answer-issue-questions や cc-exec-issue が付与されず Issue が次のワーカーに引き継がれない（あるいは判定と異なるラベルが付与される）といった状態壊れが起きる。

実行ステップ

スキルが呼び出された時は、以下のステップで処理を行なってください。

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

対象Issueのdescription・ラベル・コメント履歴全体を取得する。

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

2つの観点で内容を読む。

• コメント履歴全体: 人の確認が必要なシグナル（議論の未決着、明示的な相談・承認依頼、高リスクな判断など）が含まれていないか
• 最後のコメント: 確認事項が含まれているか、含まれている場合に未回答の項目があるか。最後のコメントが確認事項リストではなく、それ以前の確認事項への回答である場合は、どの確認事項への回答かを対応付けたうえで該当項目を回答済みとして扱う（回答の有効性判定はステップ3冒頭の「回答コメントの受け入れ原則」に従う）

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を参照）。反証シグナルにより事実確認で解消済みと判定された項目は「未回答の確認事項」の集合から除外される（詳細はパターンA経路2「反証シグナルで解消した項目の『未回答』集合からの除外」を参照）。この除外後もなお未回答の確認事項が残りパターンCに該当する場合はそこで終了する
• 確認事項がない、または全て回答済みで着手可能に見える場合は、着手（パターンE）に進む前にパターンD（コメント履歴のdescription反映チェック）を評価する。コメントで確定した内容がdescriptionに未反映であればcc-update-issueを付与して終了し、反映済みで整合している場合に限りパターンE-1（UIデザイン要否）の評価へ進む
• パターンDを通過した場合、パターンE（cc-exec-issue）の前にパターンE-1（UIデザイン要否）を評価する。UI実装タスクと判定した場合はcc-exec-issueを付けずにcc-create-ui-designのみを付与して終了する。該当しない場合に限りパターンEへ進む
• ラベルの排他性として、各トリアージ実行で付与する遷移ラベル（cc-need-human-check / cc-answer-issue-questions / cc-update-issue / cc-create-ui-design / cc-exec-issue）は同一Issueに複数付与しない。特にcc-need-human-checkとcc-answer-issue-questionsは同時に付与しない

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

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

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

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

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

このラベルは「自動化を一旦止めて人に渡す」ためのセーフティバルブ。曖昧なまま、あるいは影響の大きい判断を自動で押し進めると手戻りや事故につながるため、確信が持てない・人間の意思決定が要るケースはここで止める。

パターンAに該当するケースには次の2つの経路があり、最終的な処理内容（コメント＋ラベル付与）はどちらも同一である。

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

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

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

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

経路2: 確認事項の個別評価による人間判断の要否

最後のコメントの確認事項のうち、まだ回答が記載されていない各項目について、事実確認（コードベース調査やghコマンド。ステップ2で検証したIssue/PRの現在状態を含む）で自動回答可能かどうかを個別に評価する。

判定基準（下記リストは例示であり、当てはめではなくこの基準で判定する）: その項目が、コードベース調査と gh コマンドで確認できる事実だけでは答えが決まらず、人間の意思決定を必要とするか。必要とするならこの経路の対象になる。以下は該当する典型例で、リストにない形でも上の基準を満たせば該当させる（ただし後述の反証シグナルに該当する項目は除く）：

• 仕様・要件に矛盾や曖昧さがあり、コードベース調査だけでは解消できない
• 破壊的変更・セキュリティ・データ移行・課金・外部公開など、影響が大きい／不可逆な判断が絡む
• Issueのスコープを超える、優先度やビジネス判断など人間の意思決定が必要

反証シグナル（人間判断が必要とは判断しない条件）: 以下のいずれかに該当する場合、表面上は上記シグナルに一致していても、その項目は事実確認で解消可能な項目として扱う。

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

まだ回答が記載されていない項目全てが、反証シグナルに該当せず事実確認でも解消できない人間判断必要な項目と判断された場合に限り、経路2としてパターンAに該当する。一部の項目のみが該当する場合はパターンAには該当せず、パターンC（後述）で扱う。

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

反証シグナルのいずれかに該当し事実確認で解消可能と判定した項目は、以降のパターンC・パターンD・パターンEの判定において数える「未回答の確認事項」の集合には含めない。すなわち、この文書で以降「未回答の確認事項」という場合、常に「反証シグナルにより事実確認で解消済みと判定された項目を除いた、残りの未回答項目」を指す。

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

この除外ルールにより、carve-out項目について起票・根拠記録まで完了させたIssueは、その項目を理由にcc-answer-issue-questionsが誤って付与されたり、パターンEへの到達が妨げられたりすることはない。

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

反証シグナルの4項目目（既知バグの分離・後回しのcarve-out）に該当した項目があり、後回し対象の不具合を追跡する後続Issueがまだ存在しない場合、本スキル自身が以下の手順で後続Issueを起票する。

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

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

2. ヒットしない場合、gh issue create で後続Issueを起票する。初期ラベルはcc-triage-scopeのみを付与する（cc-issue-createdは付けない。付けるとcreate-issueワーカーの分析フェーズをスキップし、実装プランのない素のdescriptionのままtriage-created-issue→exec-issueに流れてしまうため）。blockedBy関係は付与しない（-is:blockedによりワーカーの検索クエリから除外され、分離元Issueがクローズするまで後続Issueが拾われず放置されるため）。

   gh issue create --title "<後回しにした不具合のタイトル>" --label "cc-triage-scope" --body "<不具合の内容。分離元Issue #$0 を参照する旨を明記>"
   

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

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

   • 起票先（後続Issue）の本文は、上記ステップ2の--bodyで分離元Issue番号を含めることで参照済み
   • 起票元（分離元Issue）の本文は、既存のdescriptionの内容を保持したまま末尾に後続Issueへの参照を追記する。exec-issueなど後続処理はdescriptionのみを読むため、コメント投稿だけでは本文に参照が残らない

   固定パス（例: /tmp/issue-$0-body.md）は、同一Issueへの並行実行（手動再トリガーとワーカーの重複起動など）で衝突しうるため、mktempで実行ごとに一意な一時ファイルを確保する。さらに、本文の取得（view）と書き戻し（edit）の間に人間または別プロセスが本文を更新している可能性があるため、edit直前に本文を再取得し、(a) 追記予定の参照文言がすでに含まれていないか（他プロセスが追記済みでないか）、(b) 再取得した本文がこのステップの開始時点で確認した内容と一致しているか（＝想定外の変更が入っていないか）を検証してから書き戻す：

   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でコメント投稿する。

   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の本文再取得で検知した「ステップ1〜3で確認した内容と矛盾する外部変更」も、この失敗ケースの一種として扱う（本文更新が完了しなかった＝ステップ4の失敗として、同じくパターンAへフォールバックする）。

該当する場合の処理

経路1・経路2のいずれかに該当する場合、以下を実行してこのIssueの処理を終了する。他のラベル（クローズ・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`コマンド）では解消できない理由>
   
   ## 根拠となるコメント
   
   > <判断の根拠となったコメントの引用>
   
   （<投稿者>のコメントより）
   
   ## ご確認後の進め方
   
   1. 上記への回答・決定内容をこのIssueにコメントしてください（どなたのアカウントから投稿いただいても構いません）
   2. `cc-need-human-check` ラベルを外してください。自動トリアージが再開され、いただいたコメントを踏まえて次のステップへ進みます
   

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

   • 「確認・判断していただきたいこと」は、読み手がそのまま回答できる問いの形で書く（「〜という方針でよいですか？」「A案とB案のどちらにしますか？」など）。「議論が未決着です」「判断に確信が持てません」のような状態説明だけで終わらせない。経路1（コメント履歴全体のシグナル）で該当した場合も、「何が未決着で、誰の・何に対する回答があれば先へ進めるのか」を問いの形に変換する
   • 確認・判断が必要な項目が複数ある場合は、項目ごとに番号を分けて列挙する（1つの項目に複数の論点を詰め込まない）
   • 各項目はそのコメント単体で判断材料が揃うように書く。Issue本文や過去コメントを読み直さないと判断できない書き方（「上記の件」「先日の議論の通り」だけの参照など）はしない
   • 「根拠となるコメント」には判断の根拠とした実際のコメントを引用し、誰の発言かを添える。根拠が複数ある場合は引用を並べてよい

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

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

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

Issueの内容を精査した結果、以下のいずれかに該当する場合：

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

以下を実行する：

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

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

2. Issueをcloseする

   gh issue close $0
   

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

最後のコメントに確認事項が存在し、反証シグナルによる解消（パターンA経路2「反証シグナルで解消した項目の『未回答』集合からの除外」を参照。carve-outはフォローアップ完了分のみ解消済み扱い）を除いてもなお回答が記載されていない項目がある場合（パターン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で扱う。回答が出た後に反映対象となる）。ただし反証シグナルにより事実確認で解消済みと判定された項目（carve-outはフォローアップ完了分のみ）は「未回答」ではなく確定済み内容として扱い、その結論（および該当する場合は起票した後続Issue番号）がdescriptionに反映されているかを本パターンDの反映済みチェックの対象に含める
• 本スキルやワーカーが付与したトリアージ用コメント（判定理由の記録など）や、/gemini reviewのような処理上のノイズコメント
• 雑談・相槌など、Issueの内容に影響しないコメント

上記を除いた確定内容のうち、descriptionに書かれていない、または古いまま食い違っている項目が一つでもある場合は、descriptionが陳腐化しているとみなす。この場合は着手（パターンE）に進めず、以下を実行してこのIssueの処理を終了する。他のラベル（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実装タスクと判定できるものは、実装の前にPencilでデザインを作って独立したPRとして合意するフローへ回す。実装（cc-exec-issue）ではなくcc-create-ui-designを付与する。

前提ゲート（すべて満たす場合のみE-1を評価する）

いずれかを満たさない場合はE-1を評価せず、そのままパターンEへ進む。

1. worktree直下の claude-task-worker.json に uiDesign.enabled === true がある

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

   （ワーカー側のconfig.tsが起動時に読むファイルと同一の真実源にするため、必ずworktree内のローカルファイルを読む。リモートをgh apiで読み直すと二重化して食い違いうるため行わない。ファイルが無い・読めない・不正JSONでjqが非ゼロ終了する場合も、フォールバックのprintfで確実にfalse扱いとする）
2. Issueに cc-ui-design-ready / cc-ui-design-pr-created / cc-create-ui-design のいずれも付いていない（デザイン済み・進行中の再デザインを防ぐ）
3. descriptionの## UIデザインセクション内に、</>を含まない.penで終わる実パス行が存在しない（src/workers/ui-design.tsのhasDesignReference()と同一のテキスト判定基準。見出しのみ・未置換プレースホルダー行しか無いセクションは「実パス行なし」として扱い、この条件を満たすため、そのままE-1の評価対象になる）

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

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

UI実装タスクと判定しない基準（該当すればパターンEへ）

• サーバーサイド・データモデル・バッチ・CI・ドキュメント・テストのみの変更
• 文言の差し替えのみ、ログ・計測の追加のみなど、レイアウトに影響しない微修正
• descriptionが既に十分に具体的なUI仕様（対象コンポーネント・配置・状態）を持ち、デザイン検討の余地がないと判断できる場合
• リポジトリにフロントエンド実装が存在しない

判定が割れる場合はデザインを作らない側（パターンE）に倒す。 誤ってデザインPRを挟むと、UIを伴わないIssueのリードタイムが1PR分伸びるため。

該当する場合の処理

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 を直接付ければ、トリアージ判定を経ずにデザインフローへ入れる
• 人が cc-ui-design-ready を手で付ければ、前提ゲート2により E-1 はスキップされ従来どおりパターンEへ進む

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

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

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