| name | impl-issue |
| description | GitHub Issue の実装を準備から完了まで一貫して行う。triage の判定調査結果（仕様書・ルール・類似PR・既存コードの特定）を引き継ぎ、実装計画の策定・Issue への解決内容記載・実装・レビューまで進める。UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。
`/anvil:triage-issue` が軽量実装と判定した Issue に対して Skill ツール経由でのみ起動される（ユーザーからの直接起動は不可）。
|
| user-invocable | false |
| 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(gh api *), Bash(tee *), Bash(python3 *), Bash(curl -s -H *api.figma.com*), AskUserQuestion, Agent, Skill, Read, Write, Edit, Grep, Glob |
anvil:impl-issue
GitHub Issue の実装を準備から完了まで一貫して行うオーケストレータ。
UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。
[!IMPORTANT]
本スキルは user-invocable: false であり、/anvil:impl-issue として直接起動できない。/anvil:triage-issue が軽量実装と判定した後、Skill ツール経由で起動されることが唯一の開始経路。判定調査の結果（仕様書・ルール・類似 PR・既存コードの特定）は triage から引き継ぎ、Phase 2〜5 では再調査しない（引き継いだ参照先の精読は行う）。
このスキルが Issue に書き込む内容: 解決の内容（対策・実装計画・TODO）のみ。
課題の内容（背景/現象・原因）は /anvil:create-issue が作成済みのため、上書きしない。
Goal
Issue の調査・ブランチ確認・実装計画の Issue 記載・UI の場合はデザイン仕様書・実装・レビューまで、全 Phase を完走すること。AskUserQuestion が必要な判断点以外はユーザー介入なしに継続する。
フロー継続 [MANDATORY]
Phase 完了後は立ち止まらず次の Phase に自動で進む。不明点がある場合のみ AskUserQuestion で確認する。
ワークフロー
全 Phase の一覧。Phase 0 と Phase 13 は anvil 固有の前処理・後処理。Phase 1-12 が impl-issue の本体。
| # | Phase | 対象 |
|---|
| 0 | 前処理（リポジトリ解決・ブランチ準備） | 全て |
| 1 | Issue の内容を把握する | 全て |
| 2 | 仕様書を確認する | 全て |
| 3 | 実装ルールを確認する | 全て |
| 4 | 類似 PR を学習する | 全て |
| 5 | 既存コードを確認する | 全て |
| 6 | Figma デザイン仕様書を作成する | UI Issue のみ |
| 7 | デザイン仕様書をレビューする | UI Issue のみ |
| 8 | 実装計画を策定する | 全て |
| 9 | Issue を更新する（解決内容を追記） | 全て |
| 10 | 実装に進むか確認する | 全て |
| 11 | UI 実装を行う | UI Issue のみ |
| 12 | 実装レビューを行う | UI Issue のみ |
| 13 | 後処理（commit & PR 作成・Closes 保証） | 全て |
Phase 0: 前処理（リポジトリ解決・ブランチ準備）
0-1: リポジトリ情報を解決する
.git_information.yaml が存在する場合はそこから取得する：
github:
owner: "<owner>"
repo: "<repo>"
default_base_branch: develop
ファイルが存在しない場合は gh コマンドで取得する（フォールバック）：
gh repo view --json nameWithOwner --jq '.nameWithOwner'
取得した <owner>/<repo> と <default_base_branch> を変数として記録し、以降のすべての --repo 引数に使用する。
引数が Issue URL の場合のリポジトリ整合チェック [MANDATORY]
本スキルの引数として Issue URL（例: https://github.com/<owner>/<repo>/issues/<N>）が渡された場合、URL から <url-owner>/<url-repo> と <N> を抽出する。
<url-owner>/<url-repo> が現在のリポジトリ（上で解決した値）と一致 → 続行。以降は <N> を Issue 番号として扱う- 不一致 →
AskUserQuestion で次の 3 択を提示する:
- 中断（推奨）: 「対象リポに移動して
/anvil:triage-issue <N> から再実行してください」と案内し終了
- 読み取り専用で続行:
gh issue view --repo <url-owner>/<url-repo> で Issue 内容のみ取得し、ブランチ作成 / Closes 連動 / PR 作成は現在のリポで行う。Closes #<N> ではなく Closes <url-owner>/<url-repo>#<N> を使用する（Phase 13 にも反映）
- 中止: 終了コード非ゼロで停止
Issue 番号のみ（URL ではない）で渡された場合はこのチェックは不要。
0-2: triage 引き継ぎを確認する（read-only preflight）[MANDATORY]
ブランチ操作（0-3）より前に、副作用のない読み取り専用チェックとして実行する。 user-invocable: false は直接スラッシュ起動を隠すだけで実行時ゲートにはならないため、経路違反（triage を経由しない起動）を検知する唯一の手段は本チェックである。ここで失敗した場合、ブランチ作成・checkout 等の副作用は一切発生させない。
-
Issue の内容とコメントを取得する：
gh issue view <issue番号> --repo <owner>/<repo>
gh issue view <issue番号> --repo <owner>/<repo> --comments
-
triage の調査結果を確定する: Phase 2〜5 の入力となる調査結果（関連仕様書・ルール文書・類似 PR・既存コードの特定結果）を以下の優先順で確定する:
- 同一セッションで triage を実行した直後 → コンテキスト上の調査結果をそのまま使う
- コンテキストに無い（セッションを跨いだ再開等）→ 取得したコメントから
<!-- anvil:triage-result:v1:start --> 〜 <!-- anvil:triage-result:v1:end --> のマーカーブロックを探す。複数存在する場合は最も新しい（コメント一覧の末尾に近い）ブロックのみを採用する（手書きコメントや旧スキーマのマーカーなしコメントは無視する）
- どちらにも無い（マーカーブロックが 1 件も見つからない）→ 自前調査にフォールバックせず停止し、「
/anvil:triage-issue <N> を先に実行してください」と案内する（入口一本化の経路違反を検知するため。triage-issue はマーカーを軽量実装判定の場合のみ付与するため、SDD 判定の Issue はこの分岐で自動的に検知される）
-
実装再開の判定（PR 作成失敗からの再開検知）: 現在のブランチ名に Issue 番号が含まれる場合のみ判定する。別ブランチの探索・リモートブランチの checkout は行わない（狭い happy path のみ扱う。それ以外は人間に対象ブランチへの checkout を促す）。
現在のブランチ名に Issue 番号が含まれ、かつ以下のすべてに該当する場合、Phase 2〜12 は完了済みで PR 作成のみが未達と推定できる:
- 現在のブランチがベースブランチに対して commit が進んでいる
- Issue 本文に
impl-issue が Phase 9 で書き込む解決内容セクションが既に存在する
該当する場合、AskUserQuestion で確認する:
Issue #<N> は実装・commit まで完了しているようです（PR 作成のみ未達と推定）。
- Phase 13（commit 差分確認・PR 作成）から再開する（推奨）
- 最初から通常のフロー（Phase 1〜）を実行し直す
「Phase 13 から再開する」を選んだ場合、Phase 1〜12 をすべてスキップし Phase 13 へ直接進む（現在のブランチが対象のため checkout 不要）。
現在のブランチ名に Issue 番号が含まれない場合は再開判定をせず、通常のフロー（0-3 のブランチ確認）へ進む。対象 Issue のブランチで作業したい場合は、ユーザーが手動で git checkout <branch-name> してから本スキルを再実行する。
0-3: ブランチを確認・作成する
0-2 で「Phase 13 から再開する」を選んだ場合は本ステップをスキップする（対象ブランチは既に存在し checkout 済みのはずのため、現在のブランチをそのまま使う）。
-
現在のブランチを確認する：
git branch --show-current
-
Issue 番号がブランチ名に含まれているかを判定する:
-
含まれている（例: fix/12-xxx、feature/12-xxx）→ 対応ブランチと判断し、そのまま Phase 1 へ
-
含まれていない → AskUserQuestion で確認する:
現在 `<current-branch>` にいます。Issue #N 用の作業ブランチを作成しますか？
- はい: ブランチを作成します
- いいえ: 現在のブランチで作業を続けます
-
ブランチを作成する場合:
a. ベースブランチを AskUserQuestion で確認する（デフォルト: Phase 0-1 で取得した default_base_branch、未取得の場合は develop）。
b. ベースブランチの最新状態を取得する。ベースブランチをローカルに checkout しない（git worktree でベースブランチが既に別 worktree に checkout 済みの環境でも失敗しないため）：
git fetch origin <base-branch>
fetch が失敗 → AskUserQuestion で対応確認（中止推奨）
c. ブランチ名を決定する。
判定順序 [MANDATORY]:
-
Issue のラベルから判定（最優先・決定的）。リポジトリで使われているラベル命名は揺れるので、以下の語句を部分一致・大文字小文字無視で照合する。複数一致した場合は表の上位を優先：
| プレフィックス | 一致するラベル語句（部分一致・case-insensitive） |
|---|
fix/ | bug, fix, defect, 修正, 不具合 |
feature/ | feature, enhancement, feat, 新機能, 機能追加 |
refactor/ | refactor, refactoring, cleanup, リファクタ |
docs/ | doc, docs, documentation, 文書 |
chore/ | chore, build, ci, test, dependencies, その他 |
-
どのラベルにも該当しない場合は AskUserQuestion でユーザーに選択させる：
Issue のラベルからブランチ種別が判定できませんでした。プレフィックスを選択してください:
- fix/ : バグ修正
- feature/ : 新機能
- refactor/ : リファクタ
- docs/ : 文書
- chore/ : その他
-
タイトルや本文から自動推測しない（非決定的になるため）。
形式: <prefix>/<issue-number>-<slug>（slug は Issue タイトルを kebab-case 化、英数字以外は - に置換、連続 - は 1 つに正規化、末尾 - 除去）
d. fetch した origin/<base-branch> を起点に新規ブランチを作成する。--no-track 必須: 付けないと upstream が origin/<base-branch> に設定される。push.default=simple（Git のデフォルト）では素の git push はブランチ名不一致でエラー終了するだけだが、push.default=upstream 等の設定ではそのままベースブランチへ push されてしまうため、設定に依存せず安全にするには --no-track が必須：
git checkout -b <branch-name> origin/<base-branch> --no-track
Phase 1: Issue の内容を把握する
triage 引き継ぎの確定・実装再開判定は Phase 0-2 で完了済み（本 Phase では再実行しない）。
-
タイトル・本文・ラベルから実装内容・タスク種別を把握する（内容は Phase 0-2 で取得済み）
-
既存の TODO や計画が記載されていれば確認する
-
UI Issue か判定する: 次の表で判定し、判断が割れた場合は AskUserQuestion でユーザーに確認する
| 観点 | UI Issue | データ / API / ドメイン Issue |
|---|
| 実装対象が UI / 画面ディレクトリ（プロジェクト規約） | ✅ | ✗ |
| Figma URL が「実装対象」として記載 | ✅ | ✗（参考添付なら非 UI） |
| 画面設計書への参照が「実装対象」として記載 | ✅ | ✗（参考添付なら非 UI） |
| ラベルに UI / 画面相当の表示 | ✅ | ✗ |
| ラベルに data / domain / infrastructure / api 相当 | ✗ | ✅ |
| 実装対象がドメイン層 / データ層のみ | ✗ | ✅ |
- 「Figma URL や画面名が参考として書かれているだけ」のデータ / API Issue を UI Issue と誤判定しないこと。
-
UI Issue と判定された場合のみ、Figma PAT 疎通確認を実施する（後方での手戻り防止）：
curl -s -H "X-Figma-Token: $FIGMA_PAT" "https://api.figma.com/v1/me"
- 成功 → 続行
- 失敗 → サイレントスキップしない。
AskUserQuestion で以下の 3 択を提示する:
- 再指定: PAT を設定し直して再実行する手順を案内し、ユーザーが整え次第再試行
- 非 UI Issue へ切替: 種別を非 UI Issue に変更し、Figma 関連 Phase はそもそも実行しない
- 中断: 非ゼロ終了コードで処理を停止し、stderr に未充足項目（FIGMA_PAT）と充足手順を出力する
Phase 2: 仕様書を確認する
関連仕様書の特定は triage の判定調査で完了している（Phase 0-2 で確定した調査結果を使う）。/forge:query-db-specs による再検索は行わない。
引き継がれた各仕様書参照は kind: local_path または kind: github_url を持つ（外部リポジトリ・symlink 経由の仕様書は triage 側で local_path を保持できず github_url のみになる。triage-issue references/phase-02-spec-investigation.md 参照）。種別に応じて取得方法を分岐する [MANDATORY]:
-
kind: local_path → Read tool でそのまま精読する（同一セッションで既に読了済みのものは再読不要）
-
kind: github_url → Read tool では開けない。記録されている URL は外部リポジトリ（symlink 実体）のものであり、現在の <owner>/<repo>（Phase 0-1 で解決した値）とは別リポジトリである。URL 自体から <url-owner> / <url-repo> / <ref>（ブランチ・タグ・コミット。無ければ HEAD） / <path> をパースし、以下で取得する:
gh api "repos/<url-owner>/<url-repo>/contents/<path>?ref=<ref>"
レスポンスの content（base64）をデコードして精読する。取得に失敗した場合（別 API 形式のリポジトリ・private リポジトリで権限不足等）は黙って読み飛ばさず、AskUserQuestion でユーザーに内容確認の方法を確認する
-
UI Issue の場合の追加記録: 画面設計書・確認/調整事項ドキュメントが存在する場合、必ず読み、以下を記録する（Phase 6 で /anvil:prepare-figma に渡す）:
- 画面設計書ファイルパス / 画面設計書の GitHub URL（Issue 記載用）
- 確認・調整事項ファイルパス（存在する場合）
- Figma URL（画面設計書に記載されているもの）
- 画面 ID・画面名
-
精読中に未特定の関連仕様書が判明した場合のみ、追加で読み込む（全体の再検索はしない）
Phase 3: 実装ルールを確認する
ルール文書の特定は triage の判定調査で完了している。/forge:query-db-rules による再検索は行わない。
- 引き継がれたルール文書をすべて実際に Read tool で読み込む
- CLAUDE.md に記載されているプロジェクト構造・アーキテクチャの説明を確認する
Phase 4: 類似実装済み PR を学習する
類似 PR の特定は triage の判定調査で完了している。gh pr list --search による再探索は行わない。引き継がれた PR 番号それぞれについて gh pr view / gh pr diff --name-only で内容を確認し、以下の観点で実装パターンを学習する:
- どのレイヤー・どのディレクトリのファイルが変更されているか
- ドメインモデル・値オブジェクト / リポジトリ・データソースの実装パターン
- 依存性注入・コンポジションの設定方法、状態管理の実装スタイル
- テスト対象範囲とテストの書き方
原則: 今回の実装は学習した PR と同じスコープ・同じ実装方法を採用する。独自パターンを混入させない。乖離する必要がある場合は、設計書に理由を明記する。
Phase 5: 既存コードを確認する
再利用可能な既存コードの特定は triage の判定調査で完了している。新規の全体探索は行わない。
Phase 6: Figma デザイン仕様書を作成する（UI Issue のみ）
条件: Phase 1 で UI Issue と判定された場合のみ実行。それ以外はスキップして Phase 8 へ。
Phase 6 開始時の依存ツール確認
UI Issue と判定された＝ Figma からの取り込みが必要、と確定した時点で、/anvil:prepare-figma を呼ぶ前に必要ツールの有無をオーケストレータ側で確認する。
AI は依存ツールを勝手にインストールしない。
確認対象は /anvil:prepare-figma の前提条件セクションを参照する。
不足している場合は AskUserQuestion で次の選択肢を提示する。
id | label（ユーザーに見せる） | AI の次アクション |
|---|
install_by_ai | AI が必要ツールをインストールする | インストール実行 → 完了後に Phase 6 続行 |
install_manually | 手動でインストールするので待機 | 中断・ユーザー作業完了の合図を待つ |
skip_preview | プレビュー生成をスキップし仕様書のみ作成 | /anvil:prepare-figma に skip_preview=true を渡して続行 |
abort | 中断 | impl-issue 自体を終了 |
/anvil:prepare-figma 呼び出し
/anvil:prepare-figma スキルを subagent（Agent ツール、subagent_type: general-purpose） で実行する。
メインコンテキストで Figma MCP は呼ばない（コンテキスト効率のため）。
Phase 2 で収集した画面設計書情報を渡す：
Agent tool で /anvil:prepare-figma を呼び出す:
- 画面 ID: Phase 2 で特定した画面 ID
- 画面設計書パス: Phase 2 で読み込んだ画面設計書のファイルパス
- 確認・調整事項パス: Phase 2 で読み込んだ確認・調整事項のファイルパス（存在する場合）
- Figma URL: 画面設計書に記載されていた Figma URL
/anvil:prepare-figma は以下を実行する（詳細は当該 SKILL を参照）:
- 画面設計書を Read で読み込み
- nodeId 発見・検証 + Figma URL 確定
- MCP で詳細取得 + 必要に応じ PAT で精度補完
- デザイン仕様書作成（Figma URL 必須記載、レイアウト定義を含む）
- レイアウト定義から AI 理解プレビュー画像を自動生成
- AI 自己検証ループ: Figma SS と AI プレビュー画像を Read で読み込み、構造誤りが無くなるまでレイアウト定義修正 → 再レンダリングを繰り返す
- 三点突合（デザイン仕様書 vs 画面設計書 vs Figma）でテキスト整合性も確認
出力先: /anvil:prepare-figma が specs/design/{id}/ に出力する（1 画面 = 1 ディレクトリ）。後続 Phase 8 の実装設計書もここに同居させる。
Phase 7: デザイン仕様書をレビューする（UI Issue のみ）
必須チェックポイント: Phase 8 に進む前にユーザーの承認を得る。
レビューは 「視覚比較」を中心に行う ことで、AI の構造理解の誤りを暴く。
- 生成されたデザイン仕様書を Read で読み込み、視覚比較セクションの 2 枚（Figma SS と AI プレビュー）を確認する
- ユーザーに提示し、
AskUserQuestion で確認する：
デザイン仕様書を確認してください。
視覚比較セクションの 2 枚（Figma と AI プレビュー）を必ず見比べてください。
- 承認: 構造が一致している。Phase 8 へ進みます
- 修正要求: 差異があるのでレイアウト定義を修正して再レンダリングします
- 中断: ここで中断し、後日再開します
ユーザーが修正要求した場合、/anvil:prepare-figma を再呼び出ししてレイアウト定義を修正・再レンダリングする。
Phase 8: 実装計画を策定する
Phase 1〜5（UI Issue の場合は Phase 1〜7）の調査結果をもとに以下を決定する：
- 実装スコープ: どのレイヤーに何を実装するか（具体的なクラス名・ファイルパスまで）
- 実装順序: 依存関係を考慮した実装の順番
- スコープ外: 今回実装しないもの（理由・担当）。異常系・防御的実装をスコープに含めるか迷う場合は
/forge:query-forge-rules で「比例性」「過剰設計」等を検索して判断基準を確認する
- 参考 PR: 実装方法の根拠となる PR
Phase 8 で作成する成果物は次の 2 つ。用途・出力先・参照テンプレートが異なるので混同しないこと。
実装設計書は UI Issue の場合のみ作成する。既存コンポーネント対応表、Typography 対応表、アクション一覧、状態管理、API 連携等を含む。
Typography 対応表は references/phase-11-typography-mapping.md に従い、デザイン仕様書の全テキストノードを列挙すること。
実装設計書 作成前に必ず references/phase-08-impl-design.md を読む。
Phase 9: Issue を更新する（解決内容を追記）
書き込む内容: 解決内容（対策・実装計画・TODO）のみを Issue に追記する。
背景 / 現象・原因はすでに記載済みのため、上書きしない。
[!WARNING]
gh issue edit --body-file は本文の完全置換であり追記コマンドではない。実装計画のみを書いたファイルを
そのまま渡すと既存の背景・現象・原因が消える。必ず既存本文を取得してから実装計画を末尾に結合した全文を
--body-file に渡す（手順は references/phase-09-issue-update.md 参照）。
実装計画を Issue に記載する。参照は GitHub / Figma で開けるもののみ記載する。
Issue 更新前に必ず references/phase-09-issue-update.md を読む。
Phase 10: 実装に進むか確認する
AskUserQuestion ツールで以下を確認する：
このまま実装を開始しますか？
- はい: 実装を開始します
- いいえ: 計画の見直しや別の作業を優先します
「はい」の場合:
- UI Issue → Phase 11 へ進む（Phase 11 → Phase 12 → Phase 13）
- 非 UI Issue → Issue に記載した実装計画の TODO に沿って順番に実装を進める。実装完了後は Phase 12 → Phase 13 へ進む
Phase 11: UI 実装を行う（UI Issue のみ）
条件: UI Issue の場合のみ実行。
[!IMPORTANT]
デザイン仕様書 = 構造の正 / Figma = ビジュアル詳細の正。
仕様書の値（順序・サイズ・色・padding・font・条件分岐）をそのままコードに転記する。
実装前に必ず references/phase-11-ui-implementation.md を読む。
Typography 照合前に必ず references/phase-11-typography-mapping.md を読む。
実装手順:
- デザイン仕様書と実装設計書を Read
- Typography 対応表を作成（全テキストノード → トークン。実装設計書 or コンポーネント先頭コメント）
- アクション一覧・状態表を読み、タップ挙動を同時実装する計画を立てる
- 実装コードを書く前に、対応する仕様書ノード + Typography 行をコードコメントへ転記
- 既存コンポーネント流用時は Grep で値差分照合（font / color / size / padding）
- 共用コンポーネントを 1 画面の typography に書き換えない（画面専用コンポーネントを作る）
- 実装完了後、下記セルフチェックを通す
実装後セルフチェック [MANDATORY]
references/phase-11-ui-implementation.md の「実装後セルフチェック」を実施する。
不合格があれば修正してから Phase 12 へ。妥協する場合は AskUserQuestion で確認。
Phase 12: 実装レビューを行う
実装内容を Issue 種別で分岐してレビューする。サイレントスキップ禁止 [MANDATORY]。
UI Issue の場合
実装後に三点突合（Figma デザイン仕様書 + 実装設計書 + 実装コード）を行い、正しい実装になっているか確認する。
レビュー前に必ず references/phase-12-ui-review.md を読む。
レビュー手順:
- デザイン仕様書と実装設計書を読み込む
- Figma MCP でデザインを確認する（
get_design_context → get_screenshot → get_metadata）
- 実装後キャプチャ: 最新コード反映後の実装画面を、プロジェクトのプラットフォームに応じた手段（Emulator / Simulator / Web ブラウザ / Desktop アプリ等）で実機キャプチャする
- これは AI プレビュー生成ではない。Phase 11 の最終実装を実アプリ上で確認するためのキャプチャ。
- 三点突合: Figma SS・実装キャプチャ・コード/設計書を突き合わせ、差異を洗い出す
- 類似画面との実装パターン比較を行う
- 実装ルール確認チェックリストを確認する（デザイントークン、アセット参照、i18n 等）
- 差異があれば修正し、再度突合する
- 完了後:
- プロジェクトのコード生成コマンドを実行する（必要な場合）
- 新規コンポーネント作成時はカタログへの追加 + コンポーネント一覧文書の更新
非 UI Issue の場合
Skill ツールで /forge:review code を委譲実行する（デフォルトは --diff --interactive --codex）。
Skill ツールで /forge:review code を呼び出す
- 対象: 現ブランチの未 commit 差分
- 指摘発生時: reviewer の提示に従って修正、または --auto-critical 等を別途呼び直す
- 指摘なし: そのまま Phase 13 へ進む
レビュー結果（指摘件数・対応有無）は Phase 13 の commit メッセージ・PR 本文に簡潔に反映する。
Phase 13: 後処理（commit & PR 作成・Closes 保証）
13-1: commit
/anvil:commit に委譲する。自動 commit はしない。
commit メッセージには Issue 参照を含める。Issue が現在のリポと別リポ（Phase 0-1 の整合チェック参照）なら Closes <url-owner>/<url-repo>#<N> 形式、同一リポなら Closes #<N> 形式：
<type>: <summary>
Closes #<issue-number> # 同一リポの場合
# または
Closes <owner>/<repo>#<issue-number> # 別リポの場合
13-2: 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 する（13-1 で担保）。これにより create-pr のテンプレート生成でも本文に反映されやすくなる
- create-pr に委譲した後、生成された PR 本文に
Closes #<issue-number> が含まれているか確認する。含まれていない場合は gh pr edit <PR番号> --body-file で本文を追記する
- PR 作成失敗時は
/anvil:create-pr を直接再実行せず、/anvil:triage-issue #<issue-number> から再開する（impl-issue は直接起動できないため）。再起動された impl-issue は Phase 0-2 の「実装再開の判定」がブランチの commit 状況と Issue の解決内容セクションから実装済みを検知し、「Phase 13 から再開する」を選べば Phase 1〜12 を再実行せず直接 Phase 13 に進む（triage 側も Phase 1〜9 のフル再調査を経由するため、この検知がないと不要な再調査・再計画が発生する）
将来的に /anvil:create-pr の入力契約に --issue-number 引数を追加し、impl-issue 側で Closes #N 付き本文を組み立てて渡す運用に移行する。
PR 本文には以下を含める:
Closes #<issue-number>（自動クローズ用、上記の手順で必ず確認・追記する）- 対応した受け入れ条件のチェックリスト
レビュー指摘対応時の必須ルール
- リベースができません。
- レビュー指摘の修正は 1 つずつコミットしないとリプライできません。
- PR review comment に対応する場合は、原則として 1 review comment / 1 修正 / 1 commit / 1 reply で進める。
- 複数コメントをまとめて修正・コミットしない。関連が強く不可分な場合でも、先にユーザーへ確認する。
- 各コミット後、その review comment に対して「どのコミットで何を直したか」を個別に返信できる状態にする。
- ビルドエラー・解析エラー・ユーザーが未解決と言及した問題がある場合は、コミットを作成せず、先に再現確認と修正を行う。
参照
Phase 追加・改番時はワークフローのチェックリスト・本文見出し・references ファイル名・本参照一覧を同時に更新する
