Menü
Execute tasks based on GitHub Issue content
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | exec-issue |
| description | Execute tasks based on GitHub Issue content |
| argument-hint | [issue-number] |
| hooks | {"Stop":[{"matcher":"","hooks":[{"type":"command","command":"docker compose down --volumes --remove-orphans"}]}]} |
GitHub Issue $0 の内容を読み取り、実装からPR作成までを完遂するスキルです。
Instructionsに従って順に実行し、各フェーズの「完了条件」を満たさないまま次のフェーズに進まないこと。
自律実行原則: ユーザーへの確認は行わず、判断はすべて本スキル内のルールに従って自動で決定する。中断条件に該当した場合のみ、理由を出力して終了する。
本スキルは claude-task-worker の cc-exec-issue ラベルをトリガーに自動起動される想定で、ワーカーはスキルプロセスの同期完了を根拠に cc-in-progress の除去や cc-pr-created 付与といったラベル遷移を進める。そのため、本スキル内部で呼び出す Agent / Skill / Bash を絶対にバックグラウンド実行しないこと：
Agent ツールは既定が run_in_background: true（バックグラウンド）。そのため呼び出しごとに 必ず run_in_background: false を明示指定 し、フォアグラウンドで同期的に結果を受け取ってから次の処理に進む。指定を省略した場合はバックグラウンドで走り、本スキルが未完のまま終了するSkill ツール呼び出しにも run_in_background: true を指定しない（既定は同期）。同期完了を待ってから次へ進むBash ツールにも run_in_background: true を指定しない。既定の同期実行で結果を受け取ってから次の処理に進むAgent / Skill を並列に投げるのは「並列実行」であって「バックグラウンド実行」ではないため許容される。ただし Agent は個別に run_in_background: false を指定 し、その場で同期的に完了を待つ& を付けたり、nohup / disown / setsid などでプロセスをデタッチしたりしないScheduleWakeup などで処理を後回しにしない理由: バックグラウンド化すると処理完了前に本スキルが終了し、ワーカーが「正常完了」と誤認してラベル遷移や後続ワーカー起動に進むため、実装未完のままワーカーが二重起動したり、テスト・PR作成未完のまま cc-pr-created が付与されたりして、Issue/PRの状態が壊れる。Agent ツールの既定が background であることを見落として run_in_background を省略すると、この事故が確実に起きる。
進捗管理などで TaskCreate を使う場合、以下のルールを厳守すること。違反するとバリデーションエラー（missing subject/description や unexpected parameter tasks）で中断し、フェーズが未完のまま外側のワーカーが「正常完了」と誤認する。
tasks / todos などの配列パラメータは存在しない。複数タスクを登録したい場合は、同一メッセージ内で TaskCreate を複数回発行する（並列可）subject（短いタイトル）と description（何をするか）の2つ。いずれもトップレベル文字列として渡し、ネストしたオブジェクトの中に入れないTaskCreate は deferred tool のため、セッション開始時点ではスキーマがプロンプトに含まれない。使用前に必ず ToolSearch(query: "select:TaskCreate") で1回だけスキーマをロードする。ロードせずに呼ぶと typed parameters が文字列化されてクライアント側でも弾かれる並列で以下を確認し、判断は自動で行う。ユーザーに質問しないこと。
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" で自動退避し、その旨を最終報告に明記する完了条件: worktree内、デフォルトブランチ以外のブランチ、Issue OPEN、作業ツリーがクリーンであること。
read-github-issue skill を $0 で呼び出し、以下を取得する：
返却内容は後続フェーズで各サブエージェントに渡すため、全文を保持しておくこと。
返却にスキル実行ステップの明示マーキングがあればそれを尊重する。マーキングが欠けている・不完全と判断される場合は、実装プラン各ステップを走査し、以下の兆候があるステップを追加でスキル実行ステップとして抽出する：
○○スキルを実行する」「/○○ を呼ぶ」「base-tools/skills/○○/SKILL.md を発火する」等の明示的な呼び出し指示があるbase-tools/skills/*/SKILL.md）と一対一で対応する抽出したステップは {ステップ名, 呼び出すべきスキル名, 引数, 依存関係} の構造で保持し、通常タスクと分けて管理する。判定が微妙なステップは「スキル実行ステップ候補」として別に列挙し、フェーズ2で最終判定する（推測で通常タスクに寄せない）。
完了条件: 実装タスクが「並列実行可能なグループ」「逐次グループ」「スキル実行ステップ」の3分類に整理できていること。
フェーズ1で抽出した「スキル実行ステップ」は、原則として メインエージェントが直接 Skill ツールで発火する。サブエージェントに委譲するとスキル固有の副作用（フック・ガードレール・PR作成・ラベル遷移・スナップショット出力等）が保証されず、独自判断で同等処理を手作業実装されるリスクがあるため。
Skill ツールで呼び出すSkill tool call を発行して並列実行してよいSkill ツールで発火し、代替実装は禁止する」旨を明記するbase-tools/skills/○○/SKILL.md の存在）を確認し、実在すればスキル実行ステップとして確定、実在しなければ通常タスクへ差し戻す通常タスク（スキル実行ステップ以外）は、以下の判断軸でサブエージェントを選定し、実行を委任する：
.pen を参照元としてUIに変換する）場合は必ずこのエージェントを使うこと.pen）自体の編集・更新（要素追加、レイアウト変更、スタイル修正、テキスト差し替えなど）。.pen への編集タスクは必ずこのエージェントに任せること以下のいずれかに該当するタスク同士は 逐次 で実行する：
それ以外は 並列 で実行する。並列実行する場合は、1メッセージ内で複数のAgent tool callを発行すること（順次呼び出しでは並列にならない）。
サブエージェントは現在の会話履歴を持たないため、起動時に以下を すべて プロンプトに含めること（自己完結したブリーフィングが品質を決める）。
【背景】Issue #$0「<title>」: <要約 1-2行>
【あなたが担当するタスク】
<タスク名と目的>
【対象範囲（編集可ファイル/ディレクトリ）】
<具体パスを列挙。範囲外を触らないこと>
【触れてはいけないファイル】
<並列実行中の他タスクが触る予定のファイル>
【完了条件】
- <受け入れ基準1>
- <受け入れ基準2>
- 該当箇所のテストが追加・更新され、すべてpassすること
- `npm run lint`（またはプロジェクト指定のlint）に該当ファイルでエラーがないこと
【スキル実行の扱い】
本タスク内で他のスキル（`base-tools/skills/○○/SKILL.md` に定義されるもの）を呼び出す必要がある場合は、**必ず `Skill` ツール経由で対象スキルを発火すること**。代替実装（スキル手順を自前で再現するなど）は禁止する。スキル固有のフック・ガードレール・後処理が失われ、期待される副作用が保証されなくなるため。呼び出すべきスキル名が本ブリーフィング内に明示されている場合は、その名前で `Skill` ツールを呼び出す。対象スキル名が不明・存在しない場合は自前実装で代替せず、その旨を報告して呼び出し元の判断を仰ぐ。
【参考情報】
- Issueのリンク・関連画像パス
- 既存の類似実装の参照先（あれば）
【作業ディレクトリ】
<worktreeの絶対パス>。すべてのコマンドはここを基準に実行すること。
サブエージェントが完了報告を返したら、本体側で git diff --stat を実行して変更範囲が宣言通りか検証する。範囲外の変更があれば、当該サブエージェントを再起動して修正させる。
フェーズ2で確定した「スキル実行ステップ」を、依存関係に沿って実行する。
Skill tool call を発行して並列実行するすべての実行完了後、フェーズ1で抽出した「スキル実行ステップ」一覧（期待側）と「実行済みスキル一覧」（実測側。メインエージェント直接発火分 + フェーズ3でサブエージェントに委譲した分）を突き合わせる。期待側にあって実測側にないステップ、または期待した副作用（PR作成・ラベル遷移・スナップショット等）が発生していないステップは 未実行 と判定し、依存関係を再確認したうえで本フェーズ内で Skill ツールにより再発火する（サブエージェントに再委譲しない）。
再発火してもスキルが失敗する場合、失敗ログ・対象スキル名・依存関係を最終報告に含めた上で次フェーズへ進む（ユーザーに判断を仰がない）。
フェーズ1で抽出されなかった場合、本フェーズは何もせずスキップしてよい（その旨を最終報告に一行で明記する）。
完了条件: 抽出したすべてのスキル実行ステップが実測側で確認できているか、あるいは再発火失敗として最終報告に記録されていること。
すべてのサブエージェントとスキル実行ステップが完了したら、本体で以下を順に実行：
package.json の scripts.test を確認）scripts.lint）general-purpose-assistant に 失敗ログ全文と該当ファイルパス を渡して修正させるテスト/Lintコマンドがプロジェクトに存在しない場合はスキップしてよい（その旨を最終報告に含めること）。
修正ループは最大3回まで自動で繰り返す。3回試行しても収束しない場合は、失敗ログ・残課題・推定原因をまとめて最終報告に含めた上でフェーズ6へ進む（ユーザーに判断を仰がない）。
まず差分の基準ブランチ（BASE_BRANCH）を決定する。Issue $0 が parent（Epic Issue）を持つ場合、worktree は cc-epic-<parent番号> ブランチから派生しているため、epic ブランチを基準にする。デフォルトブランチを基準にすると、epic ブランチへマージ済みの他サブIssueの差分が混ざり、「本Issueでのコード変更の有無」を誤判定する（create-pr スキルのベースブランチ決定と同じ確定的導出を用いる）。
BASE_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
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
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を作成pwd を再確認することを推奨git diff で実際の差分を必ず検証するSkill ツールで直接呼び出す。サブエージェントに委譲する場合もブリーフィングで対象スキル名と Skill ツール発火を必須指示とし、代替実装で誤魔化さない。フェーズ4の取りこぼし検知で未実行のステップがないか必ず確認する--no-verify やテストのスキップで誤魔化さない。原因を特定してから修正するGitHub PRの未解決レビューコメント・会話コメント・CIステータスを確認し、修正プランを作成します。
GitHub Issueの内容を取得し、並列実行可能な単位に分解します。
Triage a single GitHub PR by PR number. Check out the PR's branch, detect conflicts with the target branch via `gh pr status` (and label the PR with `cc-resolve-conflict` if any are found), generate and evaluate a fix plan via create-review-fix-plan, then take action (add cc-fix-onetime label if fixes are needed, or merge the PR if it's ready).
GitHubでPull Request（PR）を作成します。PRのdescriptionには指定されたテンプレートを使用し、必要な情報を記載します。PR作成後、PRのURLを報告します。
コード変更を適切なgitコミット戦略でgit commitし、pushします。基本的には既存のgitコミットへのsquash戦略を採用し、必要に応じてブランチ全体のgitコミット履歴を再構成します。実装完了時やユーザーがgit commitを依頼した時に使用します。
Update an existing GitHub Issue's description based on the issue number. Reads all issue comments and reflects any items not yet captured in the description. After refreshing the description, reviews it for remaining ambiguities or unclear requirements and posts any open questions as a follow-up 確認事項 comment.