exec-issue

name	exec-issue
description	Execute tasks based on GitHub Issue content
argument-hint	[issue-number]
hooks	{"Stop":[{"matcher":"","hooks":[{"type":"command","command":"node \"${CLAUDE_PLUGIN_ROOT}/scripts/stop-servers.mjs\""}]}]}

Execute Issue

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

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

Instructions

実行モードの制約

本スキル固有のリスク: 本スキルは 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の状態が壊れる。

スコープと出力の規律

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

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

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

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

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

• UI/コンポーネント実装・デザイン適用 → frontend-implementer
• .pen ファイルの編集・更新 → pencil-design-updater
• 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テスト実行コマンドがある

E2Eテストが存在すると判定した場合：

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

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

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

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

• pwd で .claude/worktrees/ 配下にいることを確認する。worktree外なら 中断 し、理由を出力して終了する（デフォルトブランチで作業してはならない）
• gh repo view --json defaultBranchRef -q .defaultBranchRef.name でデフォルトブランチ名を取得し、git rev-parse --abbrev-ref HEAD の現在ブランチと比較する。一致する場合は 中断。デフォルトブランチ名の取得に失敗した場合も 中断 する（fail-safe）
• gh issue view $0 --json number,title,state,labels でIssueが存在し OPEN であることを確認する。CLOSEDなら 中断
• git status --short で未コミット変更を確認する。存在する場合はユーザーに確認せず git stash push -u -m "exec-issue auto-stash $0" で自動退避し、その旨を最終報告に明記する

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

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

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 が付いている場合は description の ## UIデザイン セクションに - デザインファイル: 行があり、値が <path>.pen 形式（実パス）で存在すること（見出しのみ・プレースホルダのみでは満たさない）。

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

read-github-issue skill を $0 で呼び出し、タスク分解結果を取得する。

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

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

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

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

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

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

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

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

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

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

• 実装前に inspect-pencil-node スキルで対象Nodeの構造・スタイルを取得し、それを根拠に実装する。.pen は暗号化バイナリのため Read / Grep で直接読まない
• UIの実装は frontend-implementer エージェントに委譲し、取得したデザインデータを参照元として渡す（フェーズ3のブリーフィングに .pen パス・スナップショットパス・取得したNode構造を含める）
• 実装PRで .pen を編集しない。デザイン変更が必要な場合はデザインフローへ戻す（Issueにコメントを残し、実装は現行デザインに沿って進めるか、デザイン修正待ちであることを最終報告に明記する）
• デザインと実装が乖離せざるを得ない場合（技術的制約など）は、その理由を実装PRのbodyに記載する

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

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

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

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

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

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

• frontend-implementer: UI/コンポーネント実装、デザイン適用、shadcn/ui等のフロントエンド作業。PencilのデザインデータからUIを実装する（.pen を参照元としてUIに変換する）場合は必ずこのエージェントを使うこと
• pencil-design-updater: Pencilファイル（.pen）自体の編集・更新（要素追加、レイアウト変更、スタイル修正、テキスト差し替えなど）。.pen への編集タスクは必ずこのエージェントに任せること
• lightweight-assistant: 内容が具体的で探索不要・単一ファイル編集レベルの軽量タスク（型定義追加、定数追加、設定ファイル更新など）
• general-purpose-assistant: 上記以外、複数ファイルにまたがる実装、調査を伴うタスク、テスト/Lint修正

並列 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の差分が混ざり、「本Issueでのコード変更の有無」を誤判定する（create-pr スキルのベースブランチ決定と同じ確定的導出を用いる）。

BASE_BRANCH=""
if ! PARENT=$(gh issue view "$0" --json parent --jq '.parent.number // empty'); 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. コメント投稿の成功を確認した上で gh issue close $0 --reason "not planned" を実行する。コメントに失敗した場合はクローズせず、失敗ログを最終報告に含めて終了する（説明なしでクローズしない）
  3. 最終報告に「PR未作成・Issueクローズ済み」と判断理由を明記して処理終了
• コード変更がある場合: フェーズ7へ

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

1. commit-push skill を呼び出し、変更をコミット・push
2. create-pr skill を $0 で呼び出し、PRを作成
3. PR作成の成否を必ず検証する。現在ブランチに対応するOpen PRが実在するかを確認する：

   HEAD_BRANCH=$(git rev-parse --abbrev-ref HEAD)
   gh pr list --head "${HEAD_BRANCH}" --state open --json number,url
   

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