Execute tasks based on GitHub Issue content
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
GitHub Issue $0 の内容を読み取り、実装からPR作成までを完遂するスキル。Instructionsに従って順に実行し、各フェーズの「完了条件」を満たさないまま次のフェーズに進まないこと。
自律実行原則: ユーザーへの確認は行わず、判断はすべて本スキル内のルールで自動決定する。中断条件に該当した場合のみ、理由を出力して終了する。
本スキルの 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 の状態が壊れる。
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 の完了を待つ操作をしないtriage-pr → fix-review-point）へ引き渡すtriage-pr がそのままマージする。値が確定できない箇所は根拠のある推定値で書き、誤っていれば CI が落ちる側に倒す（落ちれば修正ループが拾う）メインエージェント（本スキルを実行しているセッション本体）の役割は「分解・委譲・検証・統合」であり、規模の大きいタスク・並列化できるタスクの実装主体はサブエージェントである。ただし数回のツール呼び出しで終わる作業まで委譲すると、ブリーフィング作成とサブエージェント側の再探索でコストと時間が倍になる。委譲が効くのは (1) メインのコンテキストを実装ログから隔離できる、(2) 独立タスクを並列化できる、(3) 専門エージェント（frontend-implementer）の前提知識を使える、のいずれかが成り立つ場合であり、下記の判定で委譲/直接実装を決める。
判定は着手前に行い、判定結果（どちらを選んだか・根拠となった条件）を記録して最終報告の自己監査に載せる。
frontend-implementer（マークアップ以外のフロントエンド実装＝状態管理・データ取得・API連携・ロジックは同エージェントの担当外。別タスクとして切り出し general-purpose-assistant へ委譲する）Read 済み、CodeGraph の出力に含まれる、または失敗ログが file:line を直接指している）どちらとも言い切れない場合は委譲側に倒す。「たぶん小さい」「たぶん1ファイルで済む」は該当しない根拠にならない。軽量タスクの受け皿として lightweight-assistant を使う。
git diff / テスト・Lintの実行でメインが自分で行う小規模な直接実装を積み上げて実装そのものを丸ごと自分でやってしまう事故を防ぐため、以下を守る。
Edit / Write を使う。sed -i / ファイルへの > >> リダイレクト / patch / cp / mv / rm などシェル経由の書き換えは、差分が検証できずレビューにも残らないため使わないgh ... --body-file - へのヒアドキュメントのように、リポジトリのファイルを変更しない標準入力の利用は可git stash / git checkout / git commit など、スキル本文が指示する git 操作は可npm install <pkg> など）はステップ1で委譲対象のため、メインからは実行しない対象プロジェクトにE2Eテストが存在し、かつタスクがユーザー操作フローに影響する場合、E2Eテストの実装・更新も本スキルの完遂条件に含める。フェーズ1の完了後（サブエージェント起動前）に以下のいずれかに該当するかを一度だけ確認し、判定結果（存在有無・テストの所在・実行コマンド）を後続フェーズで使い回す：
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テスト基盤を新規導入しない（スコープ外の変更となるため）。
並列で以下を確認し、判断は自動で行う。ユーザーに質問しないこと。
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 が途中で壊れた等）。デザインなしで実装を進めず、以下を実行して終了する。
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
gh issue edit $0 --add-label "cc-need-human-check" を実行するcc-need-human-check 付与済み」と明記して終了するcc-need-human-check は issue-worker.ts の共通除外ラベルに含まれるため、付与後はポーリング候補から外れ、人がラベルを外すまで再実行されない。
完了条件: worktree内（クラウド実行では上記のとおり免除）、デフォルトブランチ以外のブランチ、Issue OPEN、作業ツリーがクリーンであること。加えて、cc-ui-design-ready が付いている場合は上記の意味で ## UIデザイン セクションが生きていること。
read-github-issue skill を Skill(skill='read-github-issue', args=<Issue番号>)（必要なら plugin namespace 付きで claude-task-worker:read-github-issue）で起動し、以下を取得する：
返却内容は後続フェーズで各サブエージェントに渡すため、全文を保持しておくこと。
実装に入る前に、Issueが対応不要でないかを確認する。次のいずれかを根拠（コミット・PR・Issue・ファイルの該当箇所）付きで確認できた場合は、フェーズ2以降を実行せず、フェーズ6の「コード変更がない場合」の手順（構造化コメントの投稿 → コメント成功後に close-issue $0 not_planned → 最終報告）で終了する。
根拠を確認できない「たぶん不要」は該当させず、通常どおり実装へ進む。実装途中・実装後に不要と判明した場合も、フェーズ6の同じ手順で扱う。
返却の明示マーキングを尊重しつつ、マーキングが欠けている・不完全な場合は実装プラン各ステップを走査し、以下の兆候があるステップを追加でスキル実行ステップとして抽出する：
○○スキルを実行する」「/○○ を呼ぶ」「claude-task-worker/skills/○○/SKILL.md を発火する」等の明示的な呼び出し指示がある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 でしか得られないfrontend-implementer エージェントに委譲して取得したデザインデータを参照元として渡す（フェーズ3のブリーフィングに .pen パス・スナップショットパス・取得したNode構造を含める）。マークアップ以外は別タスクとして general-purpose-assistant へ委譲し、frontend-implementer が報告した props のシグネチャを配線の入力として渡す.pen を編集しない。デザイン変更が必要な場合はデザインフローへ戻す（Issueにコメントを残し、実装は現行デザインに沿って進めるか、デザイン修正待ちであることを最終報告に明記する）.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を作る.pen の、どの箇所の更新が必要か」をコメントし、デザイン更新は cc-create-ui-design を付け直してデザイン先行フローで対応する必要がある旨を明記する旧フローの残骸への対応: description に ## デザインファイルの更新 セクション（実装PRで .pen も更新させる旧トリアージの指示）が残っている場合も、その指示には従わない。上記の扱いに倒し、セクションが残っていた旨と .pen を更新しなかった理由を最終報告に書く。
フェーズ1で抽出した「スキル実行ステップ」は、原則として メインエージェントが直接 Skill ツールで発火する。サブエージェントに委譲するとスキル固有の副作用（フック・ガードレール・PR作成・ラベル遷移・スナップショット出力等）が保証されず、独自判断で同等処理を手作業実装されるリスクがあるため。
Skill ツールで呼び出す（依存関係のないステップ同士の並列実行はフェーズ4の実行手順に従う）Skill ツールで発火し、代替実装は禁止する」旨を明記するclaude-task-worker/skills/○○/SKILL.md の存在）を確認し、実在すればスキル実行ステップとして確定、実在しなければ通常タスクへ差し戻す通常タスク（スキル実行ステップ以外）は、まずタスクごとに「実装の委任（判断ロジック）」のステップ1〜3で委譲するか自分で実装するかを判定する（ステップ2の全条件を満たす小さなタスクはメインが直接実装してよく、判定結果は自己監査に記録する）。委譲すると決めたタスクは、以下の判断軸でサブエージェントを選定する：
.pen / スナップショット / DESIGN.md / 文章での指定）をマークアップ・スタイル・視覚的な状態のpropsインターフェースへ変換するタスクにのみ使う。.pen を参照元としてUIに変換する場合は必ずこのエージェントを使う。逆に、状態管理・データ取得・API連携・ルーティング・バリデーション/ビジネスロジックはフロントエンドの作業であってもこのエージェントに渡さない.pen 自体の編集・更新は cc-create-ui-design のデザイン先行フロー専任（上記「デザインファイル（.pen）を本スキルで編集しないこと」を参照）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 のシグネチャを入力として渡すgeneral-purpose-assistant）にする以下のいずれかに該当するタスク同士は 逐次 で実行する：
それ以外は 並列 で実行する。並列実行する場合は、1メッセージ内で複数のAgent tool callを発行すること（順次呼び出しでは並列にならない）。
フェーズ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 を実行して変更範囲が宣言通りか検証する。範囲外の変更があれば、当該サブエージェントを再起動して修正させる。
フェーズ2で確定した「スキル実行ステップ」を、依存関係に沿って実行する。
Skill tool call を発行して並列実行するすべての実行完了後、フェーズ1で抽出した「スキル実行ステップ」一覧（期待側）と「実行済みスキル一覧」（実測側。メイン直接発火分 + フェーズ3で委譲した分）を突き合わせる。期待側にあって実測側にないステップ、または期待した副作用（PR作成・ラベル遷移・スナップショット等）が発生していないステップは 未実行 と判定し、依存関係を再確認して本フェーズ内で Skill ツールにより再発火する（サブエージェントに再委譲しない）。
再発火してもスキルが失敗する場合、失敗ログ・対象スキル名・依存関係を最終報告に含めた上で次フェーズへ進む（ユーザーに判断を仰がない）。
フェーズ1で抽出されなかった場合、本フェーズは何もせずスキップしてよい（その旨を最終報告に一行で明記する）。
完了条件: 抽出したすべてのスキル実行ステップが実測側で確認できているか、あるいは再発火失敗として最終報告に記録されていること。
すべてのサブエージェントとスキル実行ステップが完了したら、本体で以下を順に実行：
package.json の scripts.test を確認）scripts の test:e2e / e2e 等）scripts.lint）general-purpose-assistant（単一ファイルの自明な修正なら lightweight-assistant）に 失敗ログ全文と該当ファイルパス を渡して修正させるEdit で修正する。滑り坂ガード（1回ごとに独立判定・修正のたびに再実行・同一ループ内3回で以降は委譲へ切替）を必ず守るユニットテスト/E2Eテスト/Lintコマンドがプロジェクトに存在しない場合はスキップしてよい（その旨を最終報告に含めること）。
修正ループは最大3回まで自動で繰り返す。3回試行しても収束しない場合は、失敗ログ・残課題・推定原因をまとめて最終報告に含めた上でフェーズ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
gh issue comment $0 --body-file - にヒアドキュメントで渡す（Markdownの体裁を保つため）。
## 調査結果サマリ
<Issue要件に対して何を確認したか 1-3行>
## コード変更が不要と判断した理由
<根拠。既に実装済み・要件が再現しない・別Issueでカバー済み等を具体的に>
## 確認したファイル / 参考情報
- <パスやリンクを列挙。なければ「該当なし」>
bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-compat.sh close-issue $0 not_planned を実行する（gh issue close は GraphQL 経由でクラウドセッションのゲートに掛かるため使わない）。コメントに失敗した場合はクローズせず、失敗ログを最終報告に含めて終了する（説明なしでクローズしない）commit-push skill を呼び出し、変更をコミット・push
create-pr skill を呼び出し、PRを作成。args には Issue 番号だけを渡す（Skill(skill='claude-task-worker:create-pr', args='$0')）。ブランチ名や変更内容を添えた自然文を渡さないこと（create-pr は数字を抽出して動くが、番号以外を渡す必要はない）
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 で引く）
commit-push / create-pr の失敗、返却にPR URLが含まれない、想定外エラー等、理由を問わず最終的にPRが存在しないときは以下を必ず実施する：
cc-need-human-check ラベルを付与する（外側ワーカーはこのラベルがある場合、PR不在のまま cc-pr-created を付けて完了扱いにするのを抑止する）：
gh issue edit $0 --add-label "cc-need-human-check"
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` ラベルを付け直してください
cc-need-human-check 付与済み」と原因を明記して終了する（ユーザーに判断を仰がず、ここで処理を終える）最終報告には、以下のフォーマットで自己監査結果を必ず含める。監査は「実装の委任（判断ロジック）」の適用状況をセッション自身で振り返るためのもので、判定の正当化より事実の記録を優先する。
## 実装委任の自己監査
- 起動したサブエージェント: <エージェント名 × 件数。例: general-purpose-assistant × 2, lightweight-assistant × 1>
- メインエージェントによる直接編集: なし / あり（<件数>件）
- <対象ファイル>: <変更行数> / <判定根拠。ステップ2の1〜5をどう満たしたか>
直接編集が「あり」の場合は、ステップ2のどの条件で許容されたのかを件ごとに1行で書く。ステップ1に該当していたのに直接編集した場合は、その事実をそのまま記録する（隠さない）。
pwd を再確認することを推奨git diff で実際の差分を必ず検証する。残作業が判明した場合は新しい Agent を起動するなどして完遂させるSkill ツールで確実に発火: 代替実装で誤魔化さず、フェーズ4の取りこぼし検知で未実行ステップがないか必ず確認する--no-verify やテストのスキップで誤魔化さない。原因を特定してから修正するcc-need-human-check を必ず付与する（このラベルがないと外側ワーカーがPR不在のまま cc-pr-created を付けて完了扱いにしてしまう）No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
GitHub Issueの確認事項（最後のコメント・descriptionの両方）を、コードベース・ドキュメント・そこから参照されている外部リンク（仕様書・ライブラリ公式ドキュメント等）まで調査し、根拠に基づいた回答をコメントに追記するスキル。調査しても事実で決まらず人間の意思決定が必要な項目は、固定セクションで明示して後続のトリアージへ引き渡す。
The English summary is being prepared. Showing the original description.
Write the merged Pencil design reference back into a UI implementation Issue's description. Takes the Issue number as argument, resolves the merged design PR on the `cc-ui-design-<Issue number>` branch, collects the `.pen` and snapshot paths it added, and appends (or replaces) the `## UIデザイン` section at the end of the Issue body using a lost-update-safe edit.
The English summary is being prepared. Showing the original description.
依頼された内容（自然言語の説明、または既存のIssue番号）を要件とTODOに分解し、タスクごとにGitHub Issueを作成するスキル。タスクの整理・分解、複数Issueの一括作成、依存関係の明示が必要な場合に使用する。「この機能をIssueに分けて」「タスクを洗い出してIssueにして」「PRDのIssue #123 を分解して」といったリクエストで発動する。
The English summary is being prepared. Showing the original description.
claude-task-worker のカスタムワーカー（`workerFiles` に登録する TS 定義）を、`AskUserQuestion` で要件を全項目確定させてから生成し、`claude-task-worker list-workers` でロード検証までするスキル。「カスタムワーカーを作って」「独自のワーカーを追加したい」「新しいラベルで動くワーカーを定義したい」といったリクエストで使用する。
The English summary is being prepared. Showing the original description.
claude-task-workerプラグインのバージョンをインクリメントし、commit-pushでコミット・プッシュしたうえでPRを作成する。引数で `major` / `minor` / `patch` を受け取り、対応する部分をインクリメントする（省略時は `patch`）。「バージョンを上げて」「バージョンアップ」「bump version」「メジャーバージョンを上げて」などのリクエストで使用する。
The English summary is being prepared. Showing the original description.
指定されたPR番号のDependabot PRを確認し、依存ライブラリのバージョンアップ内容をCHANGELOGとcontext7から取得して、コード修正が必要かを判定します。修正が必要な場合は修正を行い、pushまで実施します。
The English summary is being prepared. Showing the original description.