Execute Issue

GitHub Issue $0 の内容を読み取り、実装からPR作成までを完遂するスキル。Instructionsに従って順に実行し、各フェーズの「完了条件」を満たさないまま次のフェーズに進まないこと。

自律実行原則: ユーザーへの確認は行わず、判断はすべて本スキル内のルールで自動決定する。中断条件に該当した場合のみ、理由を出力して終了する。

Instructions

GitHub アクセス

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

実行モードの制約

本スキル固有のリスク: 本スキルは claude-task-worker の cc-exec-issue ラベルをトリガーに自動起動され、ワーカーはスキルプロセスの同期完了を根拠に cc-in-progress 除去・cc-pr-created 付与のラベル遷移を進める（フェーズ7で cc-need-human-check を付与した場合は PR 不在とみなし cc-pr-created を付与しない）。処理未完のままターンを終えると、ワーカーの二重起動や、テスト・PR作成未完のままの cc-pr-created 付与で Issue/PR の状態が壊れる。

CI を待たない

PR の CI（GitHub Actions の結果・CI が PR に投稿するコメント）は本スキルの完了条件ではない。 PR を作成したらその時点で終える。CI の確認は triage-pr の担当で、CI が落ちれば cc-fix-onetime → fix-review-point が CI の結果を読んで直す。本スキルが CI を待つと、その間ワーカーのタスクが実行中のまま張り付き、同じ確認を二重に行うことになる。

• gh pr checks --watch / gh run watch / workflow run や PR コメントのポーリング / sleep を挟んだ待機など、CI の完了を待つ操作をしない
• description の完了条件・実装プランが CI の結果を前提にしている場合（例:「CI が PR に投稿する結果を見てから値を書く」「CI の出力が差分なしであること」）も、CI を待って続きを書くのではなく、ローカルで得られる情報（コード・ドキュメント・ローカルで実行できるテスト/コマンド）だけで書ける最善の最終形で PR を作って終える。CI の結果を反映する作業は、CI を受けた修正ループ（triage-pr → fix-review-point）へ引き渡す
• PR は「そのままマージされてもよい最終形」で作る。CI の出力を採るためだけの一時ファイル・暫定定義など、途中段階のまま PR を残さない。途中段階は CI が通ってしまうことがあり、その場合 triage-pr がそのままマージする。値が確定できない箇所は根拠のある推定値で書き、誤っていれば CI が落ちる側に倒す（落ちれば修正ループが拾う）
• CI の結果に依存して未検証のまま残した点（推定で書いた値・CI でしか確認できない完了条件）は、PR body と最終報告に列挙する

スコープと出力の規律

• 要求されたスコープだけを実装する: Issueの受け入れ基準を満たす変更に限定し、リファクタ・命名整理・周辺の改善を足さない。気づいた別の改善点は実装せず最終報告に1行で挙げる。要求の解釈が割れて成果物が実質的に変わる場合のみ、安全側（破壊的でない側）を選び根拠を最終報告に残す
• Issueが間違っていると考えた場合: 1-2行の指摘を最終報告に書き、そのうえで依頼どおりのスコープで完遂する（黙って縮小・拡大・別物への置き換えをしない）
• 成果物の文章量は内容に見合わせる: Issueコメント・PR body・最終報告は必要な実質だけを書く。言い換え・埋め草セクション・無内容な行を足さない
• 最終報告は結論から: 1文目で「何を実装したか / どこで止まったか」を述べ、詳細を後に置く

実装の委任（判断ロジック）

メインエージェント（本スキルを実行しているセッション本体）の役割は「分解・委譲・検証・統合」であり、規模の大きいタスク・並列化できるタスクの実装主体はサブエージェントである。ただし数回のツール呼び出しで終わる作業まで委譲すると、ブリーフィング作成とサブエージェント側の再探索でコストと時間が倍になる。委譲が効くのは (1) メインのコンテキストを実装ログから隔離できる、(2) 独立タスクを並列化できる、(3) 専門エージェント（frontend-implementer）の前提知識を使える、のいずれかが成り立つ場合であり、下記の判定で委譲/直接実装を決める。

判定は着手前に行い、判定結果（どちらを選んだか・根拠となった条件）を記録して最終報告の自己監査に載せる。

ステップ1: 無条件で委譲するもの（1つでも該当したら即委譲。以降の判定はしない）

• UIデザインのマークアップ（デザイン参照をマークアップ・スタイルへ変換する部分） → frontend-implementer（マークアップ以外のフロントエンド実装＝状態管理・データ取得・API連携・ロジックは同エージェントの担当外。別タスクとして切り出し general-purpose-assistant へ委譲する）
• 2ファイル以上に触れる見込みがある
• 新規ファイルの作成を含む
• 着手前に探索が必要（編集対象のファイルパスと関数/シンボル名を、いま即答できない）
• 変更行数の見積もりが概ね20行を超える
• 依存追加・設定変更・スキーマ/マイグレーション変更を含む
• 独立して並列実行できるタスクが他に2件以上ある（メインが自分で書くと並列性を捨てることになる）

ステップ2: メインが直接実装してよい条件（すべて満たす場合のみ）

1. ステップ1のどれにも該当しない（フェーズ3の実装タスク・フェーズ5の収束ループ・サブエージェント成果物の範囲外変更の巻き戻し、いずれの局面でも同じ判定を使う）
2. 対象が単一ファイルで、変更が概ね10行以内
3. 対象箇所がすでにメインの文脈にある（自分で Read 済み、CodeGraph の出力に含まれる、または失敗ログが file:line を直接指している）
4. 追加の調査・仕様確認が不要で、変更内容が一意に定まる（型注釈の修正、import の追加、明らかなtypo、定数追加、スナップショット更新など）
5. 他のサブエージェントの完了待ちを遅らせない

ステップ3: 判定が割れたら委譲する

どちらとも言い切れない場合は委譲側に倒す。「たぶん小さい」「たぶん1ファイルで済む」は該当しない根拠にならない。軽量タスクの受け皿として lightweight-assistant を使う。

委譲の量の制御

• 1タスクに1エージェント。1体で完結するタスクに複数体を重ねて起動しない
• 検証目的でサブエージェントを起動しない。成果物の確認は git diff / テスト・Lintの実行でメインが自分で行う
• 並列起動は「対象ファイルが重ならない独立タスク」に限る（判断基準は「並列 vs 逐次の判断」節）

滑り坂ガード

小規模な直接実装を積み上げて実装そのものを丸ごと自分でやってしまう事故を防ぐため、以下を守る。

• 直接実装は1回ごとに独立して判定する。「さっき直したついでに」で連鎖させない
• 直接実装したら即座にテスト/Lintを再実行して結果を確認する（まとめて後で確認しない）
• 同一の収束ループ内で直接編集が3回に達したら、以降はすべて委譲へ切り替える（3回直しても収束しない＝ステップ2の条件4「変更内容が一意に定まる」が成り立っていない）

ツールの使い分け（直接編集する場合も適用）

• ファイル編集は必ず Edit / Write を使う。sed -i / ファイルへの > >> リダイレクト / patch / cp / mv / rm などシェル経由の書き換えは、差分が検証できずレビューにも残らないため使わない
• gh ... --body-file - へのヒアドキュメントのように、リポジトリのファイルを変更しない標準入力の利用は可
• git stash / git checkout / git commit など、スキル本文が指示する git 操作は可
• 依存追加（npm install <pkg> など）はステップ1で委譲対象のため、メインからは実行しない

E2Eテストの取り扱い（共通ルール）

対象プロジェクトにE2Eテストが存在し、かつタスクがユーザー操作フローに影響する場合、E2Eテストの実装・更新も本スキルの完遂条件に含める。フェーズ1の完了後（サブエージェント起動前）に以下のいずれかに該当するかを一度だけ確認し、判定結果（存在有無・テストの所在・実行コマンド）を後続フェーズで使い回す：

• E2Eフレームワークの設定ファイルが存在する（playwright.config.* / cypress.config.* / wdio.conf.* / nightwatch.conf.* など）
• e2e/ / tests/e2e/ / cypress/ などのE2Eテスト用ディレクトリが存在する
• package.json の scripts に test:e2e / e2e 等のE2Eテスト実行コマンドがある

存在すると判定した場合、ユーザー操作フロー（画面遷移・フォーム入力・API連携・CLIの入出力など、既存E2Eテストが検証している境界）に影響するタスクの完了条件に「該当フローのE2Eテストの追加・更新」を含め、フェーズ3のブリーフィングにE2Eテストの所在・実行コマンド・既存テストの記述パターンの参照先を含め、フェーズ5の収束ループでE2Eテストも実行する。

存在しない場合は、Issueが明示的に要求しない限りE2Eテスト基盤を新規導入しない（スコープ外の変更となるため）。

フェーズ0: 事前チェック（必ず最初に実施）

並列で以下を確認し、判断は自動で行う。ユーザーに質問しないこと。

• pwd で .claude/worktrees/ 配下にいることを確認する。worktree外なら 中断 し、理由を出力して終了する（デフォルトブランチで作業してはならない）。ただし起動プロンプトに「このセッションはクラウド実行のため worktree を持たず、cwd はリポジトリルートである」旨の指示がある場合はこの確認をスキップする — クラウド実行ではワーカーが worktree を作らないため常に worktree 外になる。ガードの目的である「デフォルトブランチで作業しない」は次の確認で担保する。指示が無く worktree 外でもある場合は従来どおり 中断 する（クラウドかもしれないという推測で続行しない）
• bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh default-branch でデフォルトブランチ名を取得し、git rev-parse --abbrev-ref HEAD の現在ブランチと比較する。一致する場合は 中断。デフォルトブランチ名の取得に失敗した場合も 中断 する（fail-safe）
• gh issue view $0 --json number,title,state,labels でIssueが存在し OPEN であることを確認する（GitHub MCP が使える場合は issue_read（method: get）を使う。以下はフォールバック）。CLOSEDなら 中断
• git status --short で未コミット変更を確認する。存在する場合は git stash push -u -m "exec-issue auto-stash $0" で自動退避し、その旨を最終報告に明記する

デザイン参照セクションの欠落検出

gh issue view $0 --json body,labels（GitHub MCP が使える場合は issue_read（method: get）を使う。以下はフォールバック）の結果から、cc-ui-design-ready ラベルの有無と、description の ## UIデザイン セクションが生きているかを確認する。見出し行 ## UIデザイン（行頭からの厳密一致。### UIデザイン のような部分一致は不可）の存在だけでは「生きている」とみなさない。次の ## 見出し直前までのセクション本文に、- デザインファイル: 行があり、値が <path>.pen 形式（実パス）であることまで確認する（<.pen の実パス> のような未置換プレースホルダや、</> を含む行、見出しのみで本文が空のセクションは「生きている」とみなさない）。この判定基準は src/workers/ui-design.ts の hasDesignReference() と同一にする。

ただし ## UIデザイン セクション内に UIデザインは不要 で始まる行がある場合は、create-ui-design がデザイン不要と判定した正常な状態なので、以下の欠落検出には該当させない（そのまま実装へ進む）。

cc-ui-design-ready が付いているのに、上記の意味で ## UIデザイン セクションが生きていない場合（見出しが無い、実パス行が無い、プレースホルダのまま等。デザイン不要マーカーがある場合を除く）、デザインの合意内容が実装セッションに届かない状態である（人が description を書き換えて参照を消した、apply-ui-design が途中で壊れた等）。デザインなしで実装を進めず、以下を実行して終了する。

1. Issueに状況コメントを投稿する

   gh issue comment $0 --body-file - <<'EOF'
   ## デザイン参照が見つかりません（要人手確認）
   
   このIssueには `cc-ui-design-ready` ラベルが付いており、UIデザインが合意済みであることを示していますが、descriptionに `## UIデザイン` セクション（`- デザインファイル:` 行があり、値が `<path>.pen` 形式であること）が見つかりませんでした。デザインの合意内容を参照できないため、実装は行っていません。
   
   ## デザインの所在
   - デザインPR: `cc-ui-design-$0` ブランチを head とするPR（マージ済み）を辿ると `.pen` とスナップショットの所在が分かります
   
   ## 対応後の進め方
   - デザイン参照を自動で再生成する場合: `cc-need-human-check`・`cc-ui-design-ready`・`cc-exec-issue` ラベルを外し、`cc-ui-design-pr-created` ラベルを付け直してください（`apply-ui-design` がデザインPRを再検出してdescriptionを再生成します）
   - 手動でdescriptionに参照を復元した場合: `cc-need-human-check` ラベルを外し、`cc-exec-issue` ラベルを付け直してください
   - デザインなしで実装を進めてよい場合: `cc-ui-design-ready`・`cc-ui-design-pr-created`・`cc-need-human-check` ラベルを外し、`cc-exec-issue` ラベルを付け直してください（`cc-ui-design-pr-created` を外さないと、`apply-ui-design` の除外ラベル設定上、実装完了時に `cc-exec-issue` が除去された瞬間 `apply-ui-design` が予期せず再起動してしまいます）
   EOF
   

2. gh issue edit $0 --add-label "cc-need-human-check" を実行する
3. 実装（コード変更・PR作成）は行わず、最終報告に「デザイン参照欠落・cc-need-human-check 付与済み」と明記して終了する

cc-need-human-check は issue-worker.ts の共通除外ラベルに含まれるため、付与後はポーリング候補から外れ、人がラベルを外すまで再実行されない。

完了条件: worktree内（クラウド実行では上記のとおり免除）、デフォルトブランチ以外のブランチ、Issue OPEN、作業ツリーがクリーンであること。加えて、cc-ui-design-ready が付いている場合は上記の意味で ## UIデザイン セクションが生きていること。

フェーズ1: Issue読み込みとタスク分解

read-github-issue skill を Skill(skill='read-github-issue', args=<Issue番号>)（必要なら plugin namespace 付きで claude-task-worker:read-github-issue）で起動し、以下を取得する：

• Issue概要（タイトル・目的・背景）
• 分解されたタスク一覧（目的・対象範囲・完了条件付き）
• タスク間の依存関係
• スキル実行ステップ一覧（返却フォーマットで「## スキル実行ステップ」として区別されているもの。各ステップに呼び出すべきスキル名・引数・依存関係が明示される）

返却内容は後続フェーズで各サブエージェントに渡すため、全文を保持しておくこと。

対応不要の判定（着手前に必ず実施）

実装に入る前に、Issueが対応不要でないかを確認する。次のいずれかを根拠（コミット・PR・Issue・ファイルの該当箇所）付きで確認できた場合は、フェーズ2以降を実行せず、フェーズ6の「コード変更がない場合」の手順（構造化コメントの投稿 → コメント成功後に close-issue $0 not_planned → 最終報告）で終了する。

• 要件がベースブランチで既に満たされている（別のPR・コミットで実装済み）
• 同じ内容を扱う別のIssue/PRが存在し、そちらで対応される（重複）
• 対象の機能・コードが既に削除されている、または要件の前提が変更され依頼自体が意味を失っている

根拠を確認できない「たぶん不要」は該当させず、通常どおり実装へ進む。実装途中・実装後に不要と判明した場合も、フェーズ6の同じ手順で扱う。

スキル実行ステップの補完抽出（必ず本フェーズで実施）

返却の明示マーキングを尊重しつつ、マーキングが欠けている・不完全な場合は実装プラン各ステップを走査し、以下の兆候があるステップを追加でスキル実行ステップとして抽出する：

• ステップ本文または対象範囲に「○○スキルを実行する」「/○○ を呼ぶ」「claude-task-worker/skills/○○/SKILL.md を発火する」等の明示的な呼び出し指示がある
• 完了条件が「スキル固有の副作用（例: PR作成・ラベル遷移・スナップショット出力・フックによる後処理）」を要求している
• ステップ名または目的が既存スキル名（claude-task-worker/skills/*/SKILL.md）と一対一で対応する

抽出したステップは {ステップ名, 呼び出すべきスキル名, 引数, 依存関係} の構造で保持し、通常タスクと分けて管理する。判定が微妙なステップは「スキル実行ステップ候補」として別に列挙し、フェーズ2で最終判定する（推測で通常タスクに寄せない）。

完了条件: 実装タスクが「並列実行可能なグループ」「逐次グループ」「スキル実行ステップ」の3分類に整理できていること。

デザイン参照セクション（## UIデザイン）がある場合の扱い

セクション内に UIデザインは不要 で始まる行がある場合は、create-ui-design が「このIssueは .pen を必要としない」と判定済みという記録である。参照すべきデザインは無いため、inspect-pencil-node も frontend-implementer へのデザイン受け渡しも行わず、通常どおりコードのみを実装する（.pen を編集しない点は下記のとおり変わらない）。

それ以外で description に ## UIデザイン セクションがある場合、そのIssueは合意済みのPencilデザインを参照元として実装するタスクである。以下を守る。

• 実装前に inspect-pencil-node スキルで対象Nodeの構造・スタイルを取得し、それを根拠に実装する。.pen は平文JSONなので Read / jq でも読めるが、レイアウト解決後のサイズやスクリーンショットは inspect-pencil-node でしか得られない
• UIの実装は「デザインのマークアップ」と「それ以外（状態管理・データ取得・API連携・ロジック）」に分け、マークアップ部分のみ frontend-implementer エージェントに委譲して取得したデザインデータを参照元として渡す（フェーズ3のブリーフィングに .pen パス・スナップショットパス・取得したNode構造を含める）。マークアップ以外は別タスクとして general-purpose-assistant へ委譲し、frontend-implementer が報告した props のシグネチャを配線の入力として渡す
• 実装PRで .pen を編集しない。デザイン変更が必要な場合はデザインフローへ戻す（Issueにコメントを残し、実装は現行デザインに沿って進めるか、デザイン修正待ちであることを最終報告に明記する）
• デザインと実装が乖離せざるを得ない場合（技術的制約など）は、その理由を実装PRのbodyに記載する

デザインファイル（.pen）を本スキルで編集しないこと

本スキルは .pen の新規作成・編集を一切行わない。 デザインファイルの変更は cc-create-ui-design のデザイン先行フロー（create-ui-design → デザインPRのレビュー・マージ → apply-ui-design）の専任であり、実装PRで .pen を触るとデザインの合意プロセスを迂回することになる。pencil-design-updater エージェントも本スキルからは起動しない（.pen の読み取りは inspect-pencil-node スキルで行ってよい）。

実装中に .pen の変更が必要と判明した場合は、次のとおり扱う。

• コード実装は現行デザイン（または現行デザインが存在しない範囲では既存の実装パターン）に沿って進め、.pen は変更しないままPRを作る
• Issueに「どの .pen の、どの箇所の更新が必要か」をコメントし、デザイン更新は cc-create-ui-design を付け直してデザイン先行フローで対応する必要がある旨を明記する
• 同じ内容を最終報告にも書く（デザイン未更新のままマージされうる点が人に伝わるようにする）

旧フローの残骸への対応: description に ## デザインファイルの更新 セクション（実装PRで .pen も更新させる旧トリアージの指示）が残っている場合も、その指示には従わない。上記の扱いに倒し、セクションが残っていた旨と .pen を更新しなかった理由を最終報告に書く。

フェーズ2: タスク実行戦略の決定

スキル実行ステップの取り扱い（原則: メインエージェントが直接発火）

フェーズ1で抽出した「スキル実行ステップ」は、原則として メインエージェントが直接 Skill ツールで発火する。サブエージェントに委譲するとスキル固有の副作用（フック・ガードレール・PR作成・ラベル遷移・スナップショット出力等）が保証されず、独自判断で同等処理を手作業実装されるリスクがあるため。

• 依存する通常タスク・先行スキル実行の完了後にメインエージェントが Skill ツールで呼び出す（依存関係のないステップ同士の並列実行はフェーズ4の実行手順に従う）
• やむを得ずサブエージェント経由で実行させる場合（例: 対象スキルの前提条件がサブエージェントのコンテキストに依存する場合）は、フェーズ3のブリーフィングで対象スキル名と「必ず Skill ツールで発火し、代替実装は禁止する」旨を明記する
• スキル間の依存関係（先行スキル → 後続タスク／後続スキル）は、通常タスクの並列/逐次判断と同じルールで扱う
• 「スキル実行ステップ候補」は、対象スキルの実在（claude-task-worker/skills/○○/SKILL.md の存在）を確認し、実在すればスキル実行ステップとして確定、実在しなければ通常タスクへ差し戻す

サブエージェント選定（通常タスク用）

通常タスク（スキル実行ステップ以外）は、まずタスクごとに「実装の委任（判断ロジック）」のステップ1〜3で委譲するか自分で実装するかを判定する（ステップ2の全条件を満たす小さなタスクはメインが直接実装してよく、判定結果は自己監査に記録する）。委譲すると決めたタスクは、以下の判断軸でサブエージェントを選定する：

• frontend-implementer: UIデザインのマークアップ専任。デザイン（.pen / スナップショット / DESIGN.md / 文章での指定）をマークアップ・スタイル・視覚的な状態のpropsインターフェースへ変換するタスクにのみ使う。.pen を参照元としてUIに変換する場合は必ずこのエージェントを使う。逆に、状態管理・データ取得・API連携・ルーティング・バリデーション/ビジネスロジックはフロントエンドの作業であってもこのエージェントに渡さない
• pencil-design-updater: 本スキルからは起動しない。.pen 自体の編集・更新は cc-create-ui-design のデザイン先行フロー専任（上記「デザインファイル（.pen）を本スキルで編集しないこと」を参照）
• lightweight-assistant: 内容が具体的で探索不要・単一ファイル編集レベルの軽量タスク（型定義追加、定数追加、設定ファイル更新など）
• general-purpose-assistant: 上記以外（複数ファイルにまたがる実装、調査を伴うタスク、テスト/Lint修正、フロントエンドのマークアップ以外の実装）

lightweight-assistant / general-purpose-assistant を起動するときは、Agent ツールの effort を毎回指定する（両エージェントとも定義に effort を持たない）。基準は ${CLAUDE_PLUGIN_ROOT}/references/agent-effort.md の表で、本スキルでは次のとおり選ぶ: lightweight-assistant は変更を伴うので medium、general-purpose-assistant は失敗ログ付きのテスト/Lint修正や指示が一意な単一の実装なら medium、複数ファイルにまたがる・原因調査を伴う・設計の再考を求めるものなら high。判定が割れたら上の段を選ぶ

デザインマークアップタスクの分離

UI変更を含むタスクは、read-github-issue の返却で「デザインマークアップタスク」と「配線タスク（状態管理・データ取得・ロジック）」に分離されている。返却が分離されていない場合（明示マーキングが欠けている場合）は、本フェーズで同じ基準で分割してから委譲する。

• マークアップタスク → frontend-implementer。完了条件は「デザインとの視覚的一致」と「表示に必要な props のシグネチャが定義されていること」に閉じる
• 配線タスク → general-purpose-assistant（軽量なら lightweight-assistant）。frontend-implementer が報告した props のシグネチャを入力として渡す
• 同一コンポーネントファイルを両方が触るため、この2タスクは逐次（マークアップ → 配線）で実行する。異なる画面のマークアップ同士は並列でよい
• マークアップの分量が数行で、既存コンポーネントへの表示条件追加程度に収まる場合は分割せず1タスクにまとめてよい（分割コストが上回るため）。その場合も担当は配線側（general-purpose-assistant）にする

並列 vs 逐次の判断

以下のいずれかに該当するタスク同士は 逐次 で実行する：

• 同じファイルを編集する可能性がある
• 一方の出力（型・関数・スキーマ）に他方が依存する
• マイグレーションやスキーマ変更を含む

それ以外は 並列 で実行する。並列実行する場合は、1メッセージ内で複数のAgent tool callを発行すること（順次呼び出しでは並列にならない）。

フェーズ3: サブエージェントへのブリーフィング

フェーズ2で委譲と判定したタスクを起動する（メインが直接実装すると判定した小さなタスクは、このフェーズ内でメインが Edit / Write で実装し、実装後すぐテスト/Lintを実行する）。

サブエージェントは現在の会話履歴を持たないため、起動時に以下を すべて プロンプトに含めること（自己完結したブリーフィングが品質を決める）。

【背景】Issue #$0「<title>」: <要約 1-2行>

【あなたが担当するタスク】
<タスク名と目的>

【対象範囲（編集可ファイル/ディレクトリ）】
<具体パスを列挙。範囲外を触らないこと>

【触れてはいけないファイル】
<並列実行中の他タスクが触る予定のファイル>

【完了条件】
- <受け入れ基準1>
- <受け入れ基準2>
- 該当箇所のユニットテストが追加・更新され、すべてpassすること
- プロジェクトにE2Eテストが存在し、担当タスクがユーザー操作フローに影響する場合: 該当フローのE2Eテストが追加・更新され、passすること（E2Eテストの所在・実行コマンド: <パスとコマンド。存在しない場合はこの行ごと削除>）
- `npm run lint`（またはプロジェクト指定のlint）に該当ファイルでエラーがないこと

【スキル実行の扱い】
本タスク内で他のスキル（`claude-task-worker/skills/○○/SKILL.md` に定義されるもの）を呼び出す必要がある場合は、**必ず `Skill` ツール経由で対象スキルを発火すること**。代替実装（スキル手順を自前で再現するなど）は禁止する。スキル固有のフック・ガードレール・後処理が失われ、期待される副作用が保証されなくなるため。呼び出すべきスキル名が本ブリーフィング内に明示されている場合は、その名前で `Skill` ツールを呼び出す。対象スキル名が不明・存在しない場合は自前実装で代替せず、その旨を報告して呼び出し元の判断を仰ぐ。

【スコープ】
上記の完了条件を満たす変更だけを行う。範囲外のリファクタ・命名整理・周辺の改善を足さない。作業中に気づいた別の改善点は実装せず、報告に1行で挙げるだけにする。

【参考情報】
- Issueのリンク・関連画像パス
- 既存の類似実装の参照先（あれば）

【作業ディレクトリ】
<worktreeの絶対パス>。すべてのコマンドはここを基準に実行すること。

【報告】
何を変更したか（対象ファイルと要点）・完了条件の充足状況・残課題を簡潔に。埋め草の要約セクションは不要。

サブエージェントが完了報告を返したら、本体側で git diff --stat を実行して変更範囲が宣言通りか検証する。範囲外の変更があれば、当該サブエージェントを再起動して修正させる。

フェーズ4: スキル実行ステップの実行と取りこぼし検知

フェーズ2で確定した「スキル実行ステップ」を、依存関係に沿って実行する。

実行手順

1. 依存関係のないステップは、同一メッセージ内で複数の Skill tool call を発行して並列実行する
2. 依存関係のあるステップは、先行ステップの完了（Skill tool の返却）を確認してから後続を発火する
3. 各実行の呼び出し履歴（スキル名・引数・返却サマリ・エラー有無）を「実行済みスキル一覧」として保持する

取りこぼし検知

すべての実行完了後、フェーズ1で抽出した「スキル実行ステップ」一覧（期待側）と「実行済みスキル一覧」（実測側。メイン直接発火分 + フェーズ3で委譲した分）を突き合わせる。期待側にあって実測側にないステップ、または期待した副作用（PR作成・ラベル遷移・スナップショット等）が発生していないステップは 未実行 と判定し、依存関係を再確認して本フェーズ内で Skill ツールにより再発火する（サブエージェントに再委譲しない）。

再発火してもスキルが失敗する場合、失敗ログ・対象スキル名・依存関係を最終報告に含めた上で次フェーズへ進む（ユーザーに判断を仰がない）。

スキル実行ステップがない場合

フェーズ1で抽出されなかった場合、本フェーズは何もせずスキップしてよい（その旨を最終報告に一行で明記する）。

完了条件: 抽出したすべてのスキル実行ステップが実測側で確認できているか、あるいは再発火失敗として最終報告に記録されていること。

フェーズ5: テストとLintの収束ループ

すべてのサブエージェントとスキル実行ステップが完了したら、本体で以下を順に実行：

1. プロジェクトのユニットテストコマンドを実行（package.json の scripts.test を確認）
2. E2Eテストが存在する場合（「E2Eテストの取り扱い（共通ルール）」の判定結果に従う）、E2Eテストコマンドも実行する（scripts の test:e2e / e2e 等）
3. プロジェクトのLintコマンドを実行（scripts.lint）
4. 失敗した場合、「実装の委任（判断ロジック）」のステップ1・2で委譲/直接編集を判定する
   • 委譲する場合: general-purpose-assistant（単一ファイルの自明な修正なら lightweight-assistant）に 失敗ログ全文と該当ファイルパス を渡して修正させる
   • 直接編集する場合: ステップ2の5条件をすべて満たすことを確認したうえで Edit で修正する。滑り坂ガード（1回ごとに独立判定・修正のたびに再実行・同一ループ内3回で以降は委譲へ切替）を必ず守る
5. 修正後、再度テスト（ユニット・E2E）とLintを実行

ユニットテスト/E2Eテスト/Lintコマンドがプロジェクトに存在しない場合はスキップしてよい（その旨を最終報告に含めること）。

修正ループは最大3回まで自動で繰り返す。3回試行しても収束しない場合は、失敗ログ・残課題・推定原因をまとめて最終報告に含めた上でフェーズ6へ進む（ユーザーに判断を仰がない）。

フェーズ6: 変更の有無で分岐

まず差分の基準ブランチ（BASE_BRANCH）を決定する。Issue $0 が parent（Epic Issue）を持つ場合、worktree は cc-epic-<parent番号> ブランチ派生のため epic ブランチを基準にする。デフォルトブランチを基準にすると、epic ブランチへマージ済みの他サブIssueの差分が混ざり、コード変更の有無を誤判定する（create-pr スキルのベースブランチ決定と同じ確定的導出を用いる）。

parent は Issue Dependencies（sub-issue）系のフィールドで、gh issue view --json parent は GraphQL 経由のためクラウドセッションでは 403 になり、クラウド VM の gh 2.45.0 はそもそもこのフィールドを知らない。gh-compat.sh issue-parent は REST（repos/{o}/{r}/issues/{n}/parent）を第一手段にし、失敗時のみ gh へフォールバックする。

BASE_BRANCH=""
if ! PARENT=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh issue-parent "$0"); then
  echo "failed to resolve issue parent" >&2
  exit 1
fi
if [ -n "${PARENT}" ] && git rev-parse --verify --quiet "refs/remotes/origin/cc-epic-${PARENT}" >/dev/null; then
  BASE_BRANCH="cc-epic-${PARENT}"
fi

# parent が無い場合は upstream（ワーカーが worktree 作成時に --track で記録した分岐元）を使う
if [ -z "${BASE_BRANCH}" ]; then
  CURRENT=$(git rev-parse --abbrev-ref HEAD)
  UPSTREAM=$(git rev-parse --abbrev-ref --symbolic-full-name '@{upstream}' 2>/dev/null || true)
  UPSTREAM=${UPSTREAM#origin/}
  if [ -n "${UPSTREAM}" ] && [ "${UPSTREAM}" != "${CURRENT}" ] \
    && git rev-parse --verify --quiet "refs/remotes/origin/${UPSTREAM}" >/dev/null; then
    BASE_BRANCH="${UPSTREAM}"
  fi
fi

if [ -z "${BASE_BRANCH}" ]; then
  BASE_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
fi

git status --short
git diff "origin/${BASE_BRANCH}..HEAD" --stat

• コード変更がない場合（PRを作成しない場合）:
  1. Issueに調査結果を構造化したコメントを投稿する。コメントは以下のテンプレートに従い、gh issue comment $0 --body-file - にヒアドキュメントで渡す（Markdownの体裁を保つため）。

     ## 調査結果サマリ
     <Issue要件に対して何を確認したか 1-3行>
     
     ## コード変更が不要と判断した理由
     <根拠。既に実装済み・要件が再現しない・別Issueでカバー済み等を具体的に>
     
     ## 確認したファイル / 参考情報
     - <パスやリンクを列挙。なければ「該当なし」>
     

  2. コメント投稿の成功を確認した上で bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh close-issue $0 not_planned を実行する（gh issue close は GraphQL 経由でクラウドセッションのゲートに掛かるため使わない）。コメントに失敗した場合はクローズせず、失敗ログを最終報告に含めて終了する（説明なしでクローズしない）
  3. 最終報告に「PR未作成・Issueクローズ済み」と判断理由を明記して処理終了
• コード変更がある場合: フェーズ7へ

フェーズ7: コミットとPR作成

1. commit-push skill を呼び出し、変更をコミット・push

2. create-pr skill を呼び出し、PRを作成。args には Issue 番号だけを渡す（Skill(skill='claude-task-worker:create-pr', args='$0')）。ブランチ名や変更内容を添えた自然文を渡さないこと（create-pr は数字を抽出して動くが、番号以外を渡す必要はない）

3. PR作成の成否を必ず検証する。現在ブランチに対応するOpen PRが実在するかを確認する：

   GitHub MCP が使える場合は list_pull_requests を使う。以下は MCP 利用不可時のフォールバック。

   HEAD_BRANCH=$(git rev-parse --abbrev-ref HEAD)
   OWNER_REPO=$(bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh owner-repo)
   gh api "repos/${OWNER_REPO}/pulls" -f state=open -f head="${OWNER_REPO%%/*}:${HEAD_BRANCH}" --jq '.[] | {number, url}'
   

   （gh pr list --head は GraphQL 経由でクラウドセッションでは 403 になるため、REST で引く）

   • PRが実在する場合: そのURLを最終報告として出力し正常終了する（CI の完了は待たない。「CI を待たない」節を参照）
   • PRが実在しない場合: commit-push / create-pr の失敗、返却にPR URLが含まれない、想定外エラー等、理由を問わず最終的にPRが存在しないときは以下を必ず実施する：
     1. cc-need-human-check ラベルを付与する（外側ワーカーはこのラベルがある場合、PR不在のまま cc-pr-created を付けて完了扱いにするのを抑止する）：

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

     2. IssueにPRを作成できなかった旨と原因・現在の状態を構造化コメントで投稿する。以下テンプレートを gh issue comment $0 --body-file - にヒアドキュメントで渡す（Markdownの体裁を保つため）：

        ## PR未作成（要人手確認）
        exec-issue の自動処理はコード変更を行いましたが、PRの作成まで完了できませんでした。
        
        ## 失敗した箇所 / 原因
        <commit-push で失敗 / create-pr で失敗 / その他。判明している範囲でログ要約を記載>
        
        ## 現在の状態
        - ブランチ: `<現在ブランチ名>`（コミット・pushの有無を明記）
        - 未コミット変更の有無
        
        ## 人手で必要な対応
        - <残作業を、人がそのまま着手できる具体的な作業単位で列挙する。例: 「ブランチ `xxx` から手動でPRを作成する」「`yyy` のコンフリクトを解消して push する」「失敗原因（ログ要約参照）を調査する」など。「確認してください」だけの曖昧な指示にしない>
        
        ## 対応後の進め方
        - 手動で対応を完了した場合（手動でPRを作成した等）: `cc-need-human-check` ラベルを外してください
        - 自動実行をやり直す場合: 失敗原因を解消したうえで `cc-need-human-check` ラベルを外し、`cc-exec-issue` ラベルを付け直してください
        

     3. 最終報告に「PR未作成・cc-need-human-check 付与済み」と原因を明記して終了する（ユーザーに判断を仰がず、ここで処理を終える）

実装委任の自己監査（最終報告の必須項目）

最終報告には、以下のフォーマットで自己監査結果を必ず含める。監査は「実装の委任（判断ロジック）」の適用状況をセッション自身で振り返るためのもので、判定の正当化より事実の記録を優先する。

## 実装委任の自己監査
- 起動したサブエージェント: <エージェント名 × 件数。例: general-purpose-assistant × 2, lightweight-assistant × 1>
- メインエージェントによる直接編集: なし / あり（<件数>件）
  - <対象ファイル>: <変更行数> / <判定根拠。ステップ2の1〜5をどう満たしたか>

直接編集が「あり」の場合は、ステップ2のどの条件で許容されたのかを件ごとに1行で書く。ステップ1に該当していたのに直接編集した場合は、その事実をそのまま記録する（隠さない）。

注意事項

• 委譲はタスク単位で判定する: 「実装の委任（判断ロジック）」に従う（ステップ1該当で委譲、ステップ2の5条件全充足のみ直接実装、割れたら委譲。滑り坂ガード付き。1タスクに複数エージェントを重ねず、検証目的の起動はしない）
• デフォルトブランチで作業しない: フェーズ0で必ず確認。途中でもファイル編集前には pwd を再確認することを推奨
• サブエージェントの結果を鵜呑みにしない: 完了報告は「やったつもり」を示すだけ。git diff で実際の差分を必ず検証する。残作業が判明した場合は新しい Agent を起動するなどして完遂させる
• 未完の処理を残したまま完了報告してターンを終えない: ターンを終えるとプロセスが正常終了し、ワーカーがPR未作成のまま完了扱いでラベル遷移を進めてしまう。最終報告を出してよいのは、フェーズ7まで完遂した（またはフェーズ6でIssueをクローズした、または中断条件・フェーズ7のPR未作成手順で理由を出力した）場合のみ
• スキル実行ステップは Skill ツールで確実に発火: 代替実装で誤魔化さず、フェーズ4の取りこぼし検知で未実行ステップがないか必ず確認する
• コメントは残さない: 生成コードに「なぜ」を説明する以外のコメントを入れないよう、サブエージェントへのブリーフィングにも明記する
• エラーの根本原因に向き合う: テスト失敗時に --no-verify やテストのスキップで誤魔化さない。原因を特定してから修正する
• E2Eテストを置き去りにしない: 「E2Eテストの取り扱い（共通ルール）」に従い、ユニットテストのpassだけで完了扱いにしない
• ユーザーに判断を求めない: フェーズ0の中断条件以外は本スキル内のルールで自動決定し、曖昧な場合は安全側（破壊的でない側）を選んで根拠を最終報告に明記する
• PR未作成時はIssueに必ず説明を残す: コード変更不要ならフェーズ6の構造化コメントを投稿してからクローズする（サイレントクローズ禁止）。PR作成に失敗したらフェーズ7の手順どおり cc-need-human-check を必ず付与する（このラベルがないと外側ワーカーがPR不在のまま cc-pr-created を付けて完了扱いにしてしまう）