Execute Issue Skill | Agent Skills

Execute Issue

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

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

Instructions

フェーズ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" で自動退避し、その旨を最終報告に明記する

完了条件: worktree内、デフォルトブランチ以外のブランチ、Issue OPEN が確認でき、作業ツリーがクリーンであること。

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

read-github-issue skill を $0 で呼び出し、以下を取得する：

Issue概要（タイトル・目的・背景）
分解されたタスク一覧（目的・対象範囲・完了条件付き）
タスク間の依存関係

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

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

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

タスクを以下の基準で振り分けて実行計画を立てる：

サブエージェント選定

frontend-implementer: UI/コンポーネント実装、デザイン適用、shadcn/ui等のフロントエンド作業
lightweight-assistant: 内容が具体的で探索不要・単一ファイル編集レベルの軽量タスク（型定義追加、定数追加、設定ファイル更新など）
general-purpose-assistant: 上記以外、複数ファイルにまたがる実装、調査を伴うタスク、テスト/Lint修正

並列 vs 逐次の判断

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

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

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

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

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

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

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

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

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

【完了条件】
- <受け入れ基準1>
- <受け入れ基準2>
- 該当箇所のテストが追加・更新され、すべてpassすること
- `npm run lint`（またはプロジェクト指定のlint）に該当ファイルでエラーがないこと

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

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

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

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

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

プロジェクトのテストコマンドを実行（package.json の scripts.test を確認）
プロジェクトのLintコマンドを実行（scripts.lint）
失敗した場合、general-purpose-assistant に 失敗ログ全文と該当ファイルパス を渡して修正させる
修正後、再度テストとLintを実行

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

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

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

git status --short
git diff origin/$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')..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クローズ済み」と判断理由を明記して処理終了。
コード変更がある場合: フェーズ6へ

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

commit-push skill を呼び出し、変更をコミット・push
create-pr skill を $0 で呼び出し、PRを作成
作成されたPRのURLを最終報告として出力

注意事項

デフォルトブランチで作業しない: フェーズ0で必ず確認。途中でもファイル編集前には pwd を再確認することを推奨
サブエージェントの結果を鵜呑みにしない: 完了報告は「やったつもり」を示すだけ。git diff で実際の差分を必ず検証する
コメントは残さない: 生成コードに「なぜ」を説明する以外のコメントを入れないよう、サブエージェントへのブリーフィングにも明記する
エラーの根本原因に向き合う: テスト失敗時に --no-verify やテストのスキップで誤魔化さないこと。原因を特定してから修正する
ユーザーに判断を求めない: フェーズ0の中断条件以外は、すべて本スキル内のルールに基づいて自動で意思決定する。曖昧な場合は「より安全な側（破壊的でない側）」を選択し、その判断と根拠を最終報告に明記する
PR未作成時はIssueに必ず説明を残す: コード変更が不要と判断した場合は、フェーズ5のテンプレートに沿った構造化コメントを投稿してからIssueをクローズする。説明なしのサイレントクローズは禁止する

Agent Skills: Execute Issue

Install this agent skill to your local

Skill Files