Menu
Execute tasks based on GitHub Issue content
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Re-analyze an existing GitHub Issue using its current title and body as input, refresh the implementation plan against the latest code state, and update the Issue in place. Use this when the user provides an Issue number (numeric, `#`-prefixed, or Issue URL) and wants to regenerate the code analysis via the explore-agent subagent. For reflecting comment-driven updates instead, use update-issue. For creating a brand-new Issue from a natural-language task description, use create-issue.
Create an implementation plan and a GitHub Issue based on the task description provided as an argument. Use this when the user supplies a natural-language task description (not an issue number) and wants a new implementation-ready Issue. If the input is an existing issue number, use create-issue-from-issue-number (re-analyze) or update-issue (reflect comments) instead.
GitHub Issueの確認事項に対して、コードベースやドキュメントを徹底的に調査し、根拠に基づいた回答を提供するスキル。Issueの最後のコメントに含まれる確認事項を調査・回答し、コメントに追記する。
ライブラリの情報を確認するためのスキル。Next.js、shadcn、その他のライブラリについて、適切なMCPサーバーを使用して最新のドキュメントと使用方法を取得します。
Create or update the Pencil (`.pen`) design for a UI implementation Issue before any code is written, then open a design-only PR. Takes the Issue number as argument, extracts the design requirements from the Issue description and comments, delegates `.pen` edits to the pencil-design-updater agent, exports snapshot PNGs, pushes them on the fixed `cc-ui-design-<Issue number>` branch, and opens a PR that references the Issue with `Refs #<N>` (never a closing keyword).
Address unresolved review comments on specified PR
| 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\""}]}]} |
GitHub Issue $0 の内容を読み取り、実装からPR作成までを完遂するスキルです。
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の状態が壊れる。
メインエージェント（本スキルを実行しているセッション本体）の役割は「分解・委譲・検証・統合」であり、規模の大きいタスク・並列化できるタスクの実装主体はサブエージェントである。ただし、数回のツール呼び出しで自分で終わる作業まで委譲すると、ブリーフィング作成とサブエージェント側の再探索でコストと時間が倍になる。委譲が効くのは (1) メインのコンテキストを実装ログから隔離できる、(2) 独立タスクを並列化できる、(3) 専門エージェント（frontend-implementer / pencil-design-updater）の前提知識を使える、のいずれかが成り立つ場合であり、下記の判定に従って委譲/直接実装を決める。
判定は着手前に行い、判定結果（どちらを選んだか・根拠となった条件）を記録して最終報告の自己監査に載せる。
frontend-implementer.pen ファイルの編集・更新 → pencil-design-updaterRead 済み、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テスト実行コマンドがあるE2Eテストが存在すると判定した場合：
E2Eテストが存在しない場合は、Issueが明示的に要求しない限りE2Eテスト基盤を新規導入しない（スコープ外の変更となるため）。
並列で以下を確認し、判断は自動で行う。ユーザーに質問しないこと。
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 が途中で壊れた等）。この場合はデザインなしで実装を進めず、以下を実行して終了する。
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 が付いている場合は description の ## UIデザイン セクションに - デザインファイル: 行があり、値が <path>.pen 形式（実パス）で存在すること（見出しのみ・プレースホルダのみでは満たさない）。
read-github-issue skill を $0 で呼び出し、タスク分解結果を取得する。
Skill(skill='read-github-issue', args=<Issue番号>)（必要なら plugin namespace 付きで claude-task-worker:read-github-issue）で起動し、以下を取得する：
返却内容は後続フェーズで各サブエージェントに渡すため、全文を保持しておくこと。
返却にスキル実行ステップの明示マーキングがあればそれを尊重する。マーキングが欠けている・不完全と判断される場合は、実装プラン各ステップを走査し、以下の兆候があるステップを追加でスキル実行ステップとして抽出する：
○○スキルを実行する」「/○○ を呼ぶ」「claude-task-worker/skills/○○/SKILL.md を発火する」等の明示的な呼び出し指示があるclaude-task-worker/skills/*/SKILL.md）と一対一で対応する抽出したステップは {ステップ名, 呼び出すべきスキル名, 引数, 依存関係} の構造で保持し、通常タスクと分けて管理する。判定が微妙なステップは「スキル実行ステップ候補」として別に列挙し、フェーズ2で最終判定する（推測で通常タスクに寄せない）。
完了条件: 実装タスクが「並列実行可能なグループ」「逐次グループ」「スキル実行ステップ」の3分類に整理できていること。
## UIデザイン）がある場合の扱いdescription に ## UIデザイン セクションがある場合、そのIssueは合意済みのPencilデザインを参照元として実装するタスクである。以下を守る。
inspect-pencil-node スキルで対象Nodeの構造・スタイルを取得し、それを根拠に実装する。.pen は暗号化バイナリのため Read / Grep で直接読まないfrontend-implementer エージェントに委譲し、取得したデザインデータを参照元として渡す（フェーズ3のブリーフィングに .pen パス・スナップショットパス・取得したNode構造を含める）.pen を編集しない。デザイン変更が必要な場合はデザインフローへ戻す（Issueにコメントを残し、実装は現行デザインに沿って進めるか、デザイン修正待ちであることを最終報告に明記する）フェーズ1で抽出した「スキル実行ステップ」は、原則として メインエージェントが直接 Skill ツールで発火する。サブエージェントに委譲するとスキル固有の副作用（フック・ガードレール・PR作成・ラベル遷移・スナップショット出力等）が保証されず、独自判断で同等処理を手作業実装されるリスクがあるため。
Skill ツールで呼び出すSkill tool call を発行して並列実行してよいSkill ツールで発火し、代替実装は禁止する」旨を明記するclaude-task-worker/skills/○○/SKILL.md の存在）を確認し、実在すればスキル実行ステップとして確定、実在しなければ通常タスクへ差し戻す通常タスク（スキル実行ステップ以外）は、まずタスクごとに「実装の委任（判断ロジック）」のステップ1〜3で委譲するか自分で実装するかを判定する。委譲すると決めたタスクについて、以下の判断軸でサブエージェントを選定する。ステップ2の全条件を満たす小さなタスクはメインが直接実装してよく、その判定結果は自己監査に記録する：
.pen を参照元としてUIに変換する）場合は必ずこのエージェントを使うこと.pen）自体の編集・更新（要素追加、レイアウト変更、スタイル修正、テキスト差し替えなど）。.pen への編集タスクは必ずこのエージェントに任せること以下のいずれかに該当するタスク同士は 逐次 で実行する：
それ以外は 並列 で実行する。並列実行する場合は、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の差分が混ざり、「本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
gh issue comment $0 --body-file - にヒアドキュメントで渡す（Markdownの体裁を保つため）。
## 調査結果サマリ
<Issue要件に対して何を確認したか 1-3行>
## コード変更が不要と判断した理由
<根拠。既に実装済み・要件が再現しない・別Issueでカバー済み等を具体的に>
## 確認したファイル / 参考情報
- <パスやリンクを列挙。なければ「該当なし」>
gh issue close $0 --reason "not planned" を実行する。コメントに失敗した場合はクローズせず、失敗ログを最終報告に含めて終了する（説明なしでクローズしない）commit-push skill を呼び出し、変更をコミット・pushcreate-pr skill を $0 で呼び出し、PRを作成HEAD_BRANCH=$(git rev-parse --abbrev-ref HEAD)
gh pr list --head "${HEAD_BRANCH}" --state open --json number,url
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 ツールで直接呼び出す。サブエージェントに委譲する場合もブリーフィングで対象スキル名と Skill ツール発火を必須指示とし、代替実装で誤魔化さない。フェーズ4の取りこぼし検知で未実行のステップがないか必ず確認する--no-verify やテストのスキップで誤魔化さない。原因を特定してから修正するcc-need-human-check で人手に委ねる: コード変更を行ったのにPRを作成できなかった場合（commit-push/create-pr の失敗・想定外エラー等）は、フェーズ7の手順どおり cc-need-human-check ラベルを付与し、PR未作成の旨と原因をIssueコメントに残す。このラベルがないと外側ワーカーがPR不在のまま cc-pr-created を付けて完了扱いにしてしまうため、必ず付与する