// GitHub Issue の実装を準備から完了まで一貫して行う。ブランチ確認・作成から始まり、仕様書・ルール文書を調査し、類似PRから実装パターンを学習、解決内容（対策・実装計画）を Issue に記載する。UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。トリガー：「この Issue を実装したい」「Issue XXX の着手前準備」「実装計画を立てて」「XXX を実装する Issue の準備をして」
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | impl-issue |
| description | GitHub Issue の実装を準備から完了まで一貫して行う。ブランチ確認・作成から始まり、仕様書・ルール文書を調査し、類似PRから実装パターンを学習、解決内容（対策・実装計画）を Issue に記載する。UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。トリガー：「この Issue を実装したい」「Issue XXX の着手前準備」「実装計画を立てて」「XXX を実装する Issue の準備をして」 |
| user-invocable | true |
| argument-hint | <issue番号 または URL> |
| allowed-tools | Bash(git *), Bash(gh issue view *), Bash(gh issue edit *), Bash(gh pr list *), Bash(gh pr view *), Bash(gh pr diff *), Bash(gh pr edit *), Bash(gh repo view *), Bash(tee *), Bash(python3 *), Bash(curl -s -H *api.figma.com*), AskUserQuestion, Agent, Skill, Read |
GitHub Issue の実装を準備から完了まで一貫して行うオーケストレータ。 UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。
このスキルが Issue に書き込む内容: 解決の内容（対策・実装計画・TODO）のみ。
課題の内容（背景/現象・原因）は /anvil:create-issue が作成済みのため、上書きしない。
以下のチェックリストをコピーして進捗を追跡する：
進捗:
- [ ] Phase 0: リポジトリ情報を解決する
- [ ] Phase 1: ブランチを確認・作成する
- [ ] Phase 2: Issue を確認する
- [ ] Phase 3: 仕様書を調査する
- [ ] Phase 4: 実装ルールを調査する
- [ ] Phase 5: 類似PRを調査する（ユーザにAskUserQuestionで実行するか確認）
- [ ] Phase 6: 既存コードを調査する
- [ ] Phase 7: Figma デザイン仕様書を作成する（UI Issue のみ）
- [ ] Phase 8: デザイン仕様書をレビューする（UI Issue のみ）
- [ ] Phase 9: 実装計画を策定する
- [ ] Phase 10: Issue を更新する（解決内容を追記）
- [ ] Phase 11: 実装に進むか確認する
- [ ] Phase 12: UI 実装を行う（UI Issue のみ）
- [ ] Phase 13: 実装レビューを行う（UI Issue のみ）
- [ ] Phase 14: commit & PR を作成する
.git_information.yaml が存在する場合はそこから取得する：
# .git_information.yaml
github:
owner: "<owner>"
repo: "<repo>"
default_base_branch: develop # Phase 1 のデフォルトとして使用
ファイルが存在しない場合は gh コマンドで取得する（フォールバック）：
gh repo view --json nameWithOwner --jq '.nameWithOwner'
取得した <owner>/<repo> と <default_base_branch> を変数として記録し、以降のすべての --repo 引数に使用する。
現在のブランチを確認する：
git branch --show-current
Issue 番号がブランチ名に含まれているかを判定する:
含まれている（例: fix/12-xxx、feature/12-xxx）→ 対応ブランチと判断し、そのまま Phase 2 へ
含まれていない → AskUserQuestion で確認する:
現在 `<current-branch>` にいます。Issue #N 用の作業ブランチを作成しますか？
- はい: ブランチを作成します
- いいえ: 現在のブランチで作業を続けます
ブランチを作成する場合:
a. ベースブランチを AskUserQuestion で確認する（デフォルト: Phase 0 で取得した default_base_branch、未取得の場合は develop）:
ベースブランチを入力してください（デフォルト: <default_base_branch>）:
他のブランチが必要な場合は入力してください
b. ベースブランチを最新化してブランチを作成する：
git fetch origin <base-branch>
git checkout <base-branch>
git pull --ff-only origin <base-branch>
pull --ff-only が失敗 → AskUserQuestion で対応確認（中止推奨）c. ブランチ名を決定する:
| Issue 内容 | プレフィックス |
|---|---|
| バグ修正 | fix/ |
| 新機能 | feature/ |
| リファクタ | refactor/ |
| 文書 | docs/ |
| その他 | chore/ |
形式: <prefix>/<issue-number>-<slug>（slug は Issue タイトルを kebab-case 化）
git checkout -b <branch-name>
ユーザーから Issue 番号または URL を受け取る
Issue の現在の内容を取得する：
gh issue view <issue番号> --repo <owner>/<repo>
コメントも確認する（既存の調査結果がある場合）：
gh issue view <issue番号> --repo <owner>/<repo> --comments
タイトル・本文・ラベルから実装内容・タスク種別を把握する
既存の TODO や計画が記載されていれば確認する
UI Issue か判定する: 以下のいずれかに該当すれば UI Issue
figma.com/design/）が含まれるUI や 画面 が含まれるUI Issue の場合、PAT 疎通確認（後方での手戻り防止）：
curl -s -H "X-Figma-Token: $FIGMA_PAT" "https://api.figma.com/v1/me"
AskUserQuestion で以下の 3 択を提示する:
/doc-advisor:query-specs を使い、Issue のタイトルと本文をキーワードとして関連仕様書を特定する。
詳細は references/phase-03-spec-investigation.md を参照。
/doc-advisor:query-rules を使い、タスクに関連するルール文書を特定する。
必須ルール:
/doc-advisor:query-rules で "architecture" / "coding" / "layer" 等をクエリして重要文書を特定する今回の実装と同じスコープのマージ済みPRを3件以上探し、実装パターンを学習する。
詳細は references/phase-05-pr-investigation.md を参照。
実装に再利用できる既存クラス・コンポーネントを特定する。
詳細は references/phase-06-code-investigation.md を参照。
条件: Phase 2 で UI Issue と判定された場合のみ実行。それ以外はスキップして Phase 9 へ。
/anvil:prepare-figma スキルを subagent（Agent tool） で実行する。
メインコンテキストで Figma MCP は呼ばない（コンテキスト効率のため）。
Phase 3 で収集した画面設計書情報を渡す：
Agent tool で `/anvil:prepare-figma` を呼び出す:
- 画面 ID: Phase 3 で特定した画面 ID
- 画面設計書パス: Phase 3 で読み込んだ画面設計書のファイルパス
- 確認・調整事項パス: Phase 3 で読み込んだ確認・調整事項のファイルパス（存在する場合）
- Figma URL: 画面設計書に記載されていた Figma URL
デザイン仕様書の出力先は /doc-advisor:query-specs で確認した design/ ディレクトリを使用する。
必須チェックポイント: Phase 9 に進む前にユーザーの承認を得る。
AskUserQuestion で確認する：
デザイン仕様書を確認してください。
- 承認: Phase 9 へ進みます
- 修正要求:
/anvil:prepare-figmaを再実行 or 直接修正します- 中断: ここで中断し、後日再開します
Phase 2〜6（UI Issue の場合は Phase 2〜8）の調査結果をもとに以下を決定する：
UI Issue の場合: デザイン仕様書 + Phase 3〜6 の全調査結果を踏まえて実装設計書も作成する。
実装設計書は「どう作るか」を決定する文書（既存コンポーネント対応表、デザイントークン、状態管理、API連携等）。
出力先: /doc-advisor:query-specs で確認した design/ ディレクトリ。
実装設計書作成前に必ず references/phase-09-impl-design.md を読み込む。
スキルディレクトリに assets/TEMPLATE.md が存在する場合はそれをベースに計画を作成する。
書き込む内容: 解決内容（対策・実装計画・TODO）のみを Issue に追記する。 背景/現象・原因はすでに記載済みのため、上書きしない。
詳細は references/phase-10-issue-update.md を参照。
AskUserQuestion ツールで以下を確認する：
このまま実装を開始しますか？
- はい: 実装を開始します
- いいえ: 計画の見直しや別の作業を優先します
「はい」の場合:
条件: UI Issue の場合のみ実行。非 UI Issue はスキップ。
実装設計書に基づいて UI を実装する。
実装前に必ず references/phase-12-ui-implementation.md を読み込む。
条件: UI Issue の場合のみ実行。非 UI Issue はスキップ。
実装後に三点突合を行い、正しい実装になっているか確認する。
レビュー前に必ず references/phase-13-ui-review.md を読み込む。
commit: /anvil:commit に委譲する。自動 commit はしない。
commit メッセージには Issue 参照を含める：
<type>: <summary>
Closes #<issue-number>
PR 作成: /anvil:create-pr <base-branch> に委譲する。
⚠️ PR 本文の Closes 保証
/anvil:create-prのargument-hintは[base-branch]のみで、Issue 番号を引数で受け取る経路がない（PR 本文は commit 差分・テンプレートから生成される）。 しかし PR 本文には Issue を自動クローズするためCloses #<issue-number>を含める必要がある。したがって impl-issue は以下を必ず行う:
- commit メッセージに
Closes #<issue-number>を含めて push する（上記 commit ステップで担保）。これにより create-pr のテンプレート生成でも本文に反映されやすくなる- create-pr に委譲した後、生成された PR 本文に
Closes #<issue-number>が含まれているか確認する。含まれていない場合はgh pr edit <PR番号> --body-fileで本文を追記する- PR 作成失敗時は
/anvil:create-prを直接再実行せず、/anvil:impl-issue #<issue-number>から再開する（Issue 番号引き継ぎ経路を保つため）将来的に
/anvil:create-prの入力契約に--issue-number引数を追加し、impl-issue 側でCloses #N付き本文を組み立てて渡す運用に移行する。
PR 本文には以下を含める:
Closes #<issue-number>（自動クローズ用、上記の手順で必ず確認・追記する）Phase 追加・改番時はワークフローのチェックリスト・本文見出し・references ファイル名・本参照一覧を同時に更新する