| name | x-implementing-plan |
| description | 計画ファイル（docs/frontend/plans/*.md など）のパスを受け取り、その計画に従って実装を行うスキル。 実装・リンター・テスト・コードレビュー・計画ファイル更新を一連で実行し、完了報告まで行う。 「plans/〇〇.md の計画に従って実装して」「この計画を実装して」「計画どおりに実装して」 「Acceptance Criteria を全部パスした状態で終わらせて」「計画ファイルのパスを渡すから実装して」 「じゃあ実装に移って」「さっきの計画でお願い」のような依頼で使う。 計画ファイルのパスが引数に含まれていれば積極的に起動する。 直前の会話で x-planning-implementation スキルが計画ファイルを生成した場合も積極的に起動を提案する。
|
| allowed-tools | ["Bash","Read","Edit","Write","Glob","Grep","Skill","TaskCreate","TaskUpdate","TaskList"] |
implementing-plan
計画ファイルを入力として受け取り、実装・検証・コードレビュー・計画ファイル更新までを一連で完了させるスキルです。
ユーザーへの確認は実装完了後の最終報告時のみです。途中で止まりません。
フロー（7フェーズ）
各フェーズは順番どおりに実行します。前のフェーズが完了しない限り次に進みません。
タスク登録（実行開始時に必ず実施）
フローを開始する前に、全ステップをTaskCreateで登録します。各ステップを開始するときTaskUpdateでin_progressへ、完了したときcompletedへ更新します。
| # | subject | blockedBy |
|---|
| 1 | Phase 1: 計画の読み込みと把握 | — |
| 2 | Phase 2: 実装 | 1 |
| 3 | Phase 3: Acceptance Criteriaの検証 | 2 |
| 4 | Phase 4: コードレビュー | 3 |
| 5 | Phase 5: 計画ファイルの更新 | 4 |
| 6 | Phase 6: ふりかえり | 5 |
| 7 | Phase 7: 完了報告 | 6 |
Phase 1: 計画の読み込みと把握
引数から計画ファイルのパスを特定して読み込みます。パスが渡されていない場合は会話のコンテキストから推定します。
把握する内容は以下の通りです。
Context — 作業対象ディレクトリ・技術スタック・制約Goal — 実装の完成形Non-goals — スコープ外（実装しない）Constraints — 設計原則・依存ルール・変更禁止ファイルReferences — 倣うべき類似実装Acceptance Criteria — 完了条件と検証コマンドOpen Questions for Implementation — 実装中の判断保留事項
計画ファイルにセクション欠落やTBDが残っている場合は、Phase 6の完了報告に「読み込み時に検出した未定義箇所」として記録し、可能な範囲で推論して進みます。推論が困難な場合のみPhase 6でユーザーに確認します。
完了条件: 全セクションを読み、各Acceptance Criteriaの検証コマンドを把握していること。
Phase 2: 実装
計画の指示にしたがってコードを書きます。
実装の進め方は以下の通りです。
Referencesに挙げられた類似実装を読んでパターンを確認するConstraintsにしたがって実装する（変更禁止ファイルは絶対に触らない）Non-goalsに記載された内容は実装しないOpen Questions for Implementationのif-then条件にマッチする状況が発生したら、そこへ書かれた判断どおりに進める
実装中の判断ルール
計画に書かれていない判断が必要になった場合は、以下の通りです。
| 状況 | 対応 |
|---|
ConstraintsとReferencesが矛盾している | Constraintsを優先し、矛盾内容をPhase 6の報告に記録する |
| スコープ内か判断が難しい変更 | Non-goalsに該当しない・Goalに照らして必要なら実装し、Phase 6で内容を報告する |
| 計画に記述がなく推論も難しい判断 | 最小限の安全な実装を選び、Phase 6で判断内容を報告してユーザーに確認を求める |
完了条件: 実装ファイルが揃い、構文エラーがない状態。
Phase 3: Acceptance Criteriaの検証
計画に記載された検証コマンドをすべて実行します。
各Acceptance Criteriaの検証コマンドを実行する
→ 失敗した場合はコードを修正して再実行する
→ 全て合格するまでループする（上限: 5回）
上限（5回）に達しても全条件をパスできない場合はPhase 6で報告し、ユーザーに相談します。
TypeScriptプロジェクトの場合は必ず型チェックとlintも通します。実行コマンドはContextに記載のパッケージマネージャー（npm / pnpm / yarn / bun）とpackage.jsonのscriptsを参照して決定します。
cd <Context に記載のディレクトリ> && <パッケージマネージャー> run typecheck
cd <Context に記載のディレクトリ> && <パッケージマネージャー> run lint:fix
lint:fixスクリプトがpackage.jsonに存在しない場合はnpx eslint --fix <変更したファイル>を実行します。自動修正後もエラーが残る場合はコードを修正して再実行します。ACにlintが含まれていなくても省略しません。
完了条件: 全Acceptance Criteriaが合格していること、かつlintエラーがゼロであること。
Phase 4: コードレビュー（x-thorough-code-reviewスキル）
x-thorough-code-reviewスキルを起動してローカルブランチの変更をレビューします。
Skill: x-thorough-code-review
モード: ローカル
設計書: <計画ファイルのパス>
レビューのループ制御は以下の通りです。
レビュー実行（1回目）
→ must/should の指摘があれば修正 → Phase 3（検証）→ レビュー再実行
→ must/should の指摘があれば修正 → Phase 3（検証）→ レビュー再実行
→ must/should の指摘があれば修正 → Phase 3（検証）→ レビュー再実行（3回目）
→ 3回目終了後は以下の終了条件を評価する
終了条件（ループを抜けてPhase 5へ進む）は以下の通りです。
| 状態 | 対応 |
|---|
| 指摘なし | そのままPhase 5へ |
| nitのみ残っている | Phase 6でユーザーに判断を委ねる |
| 3回目でもmust/shouldが残っている | Phase 6でブロッカーとして報告し、ユーザーに判断を委ねる |
must/shouldの修正が発生するたびにx-thorough-code-reviewスキルをフルで再実行します。修正が連鎖して別の箇所に影響していることがあるためです。再レビューの差分は小さいので実際の作業量は少なくなります。
指摘への対応方針
指摘に対しては、より厳格な実装を採用します。「動けばいい」ではなく、指摘の意図を汲んで設計・型・ロジックをより堅牢な方向へ修正します。
指摘対応時、引数の値域・戻り値の形式・副作用など暗黙の前提があればJSDocを追記します。名前と型だけで伝わる場合は書きません。
x-thorough-code-reviewスキルが起動できない場合は、その旨をPhase 6の報告に記載してスキップします。
テスト補完（実装の問題指摘があった場合）
[ロジック]``[設計]``[型]カテゴリのmust/should指摘を修正した場合、その問題がPhase 3のテストで検出できなかった理由を考察します。
考察の手順は以下の通りです。
- 修正した問題を一言で表す（例:「境界値00:00の処理が誤っていた」）
- その問題をカバーするテストケースが既存テストに存在するか確認する
- 存在しない場合はテストを追加してからPhase 3（検証）に戻る
テスト補完の判断基準は以下の通りです。
- 「テストがあれば事前に検出できた」→ テストを追加する
- 「コードレビューでしか検出できない設計的な問題だった」→ テストは追加せず、Phase 6の報告に理由を記載する
テスト追加の目的は「同じ見落としを繰り返さないこと」です。指摘された表面的な症状だけをカバーするのではなく、同種の問題を幅広くカバーするテストを書きます。
完了条件: 終了条件のいずれかを満たしていること。テスト補完が必要だった場合は、追加テストもパスしていること。
Phase 5: 計画ファイルの更新
計画ファイルのAcceptance Criteriaチェックボックスをすべて[x]に更新します。
続いて、計画ファイルの末尾に検証結果セクションを追記します（すでに存在する場合は更新します）。
## Verification Results（検証結果）
実施日: <YYYY-MM-DD>
### Acceptance Criteria
| 条件 | 結果 |
|---|---|
| <Acceptance Criteria 1> | ✅ パス |
| <Acceptance Criteria 2> | ✅ パス |
### Code Review
- レビュー実施: あり / なし（スキップ理由: <理由>）
- must指摘: <N>件 → すべて修正済み
- should指摘: <N>件 → すべて修正済み
- nit指摘: <N>件 → <修正したもの / スキップしたもの>
#### 指摘一覧
| 重要度 | カテゴリ | 内容 | 対応 |
|---|---|---|---|
| must | `[ロジック]` | <指摘内容> | 修正済み（<修正の概要>） |
| should | `[設計]` | <指摘内容> | 修正済み（<修正の概要>） |
| nit | `[その他]` | <指摘内容> | スキップ（<理由>） |
指摘がなかった場合は「指摘なし」と記載する。
完了条件: 計画ファイルのチェックボックスがすべて[x]になっており、検証結果セクションが追記されていること。
Phase 6: ふりかえり（x-retrospectiveスキル）
x-retrospectiveスキルを起動し、このセッションのふりかえりを実施します。
Skill: x-retrospective
完了条件: x-retrospectiveスキルが完了していること。
Phase 7: 完了報告
実装結果とふりかえり結果をまとめてユーザーに報告します。
## 実装完了報告
### 計画どおりに実装できたこと
- <実装したファイル・機能>
- <実装したファイル・機能>
### 問題があって修正したこと
- <問題の内容> → <対応内容>
- 出所: <テスト失敗 / コードレビュー(重要度) / 型エラー>
### Acceptance Criteria
- [x] <条件1>（検証コマンド: `<コマンド>`）
- [x] <条件2>（検証コマンド: `<コマンド>`）
### 計画ファイル
- 更新済み: <計画ファイルのパス>
### ふりかえり
- ふりかえりファイル: <x-retrospectiveスキルが更新したファイルのパス>
- Keep: <主なKeep項目>
- Problem: <主なProblem項目>
- Try/Action: <主なTry/Action項目>
### ローカル確認手順
#### 起動コマンド
計画ファイルの `Context` に記載されたディレクトリ・パッケージマネージャー・スクリプト名を使う。
```bash
# 開発サーバーの起動（Context のディレクトリとスクリプトに合わせて変更する）
cd <Context に記載のディレクトリ> && <パッケージマネージャー> run dev
確認ページ
| URL | 説明 |
|---|
<Context に記載のローカルURL>/<実装したパス> | <実装した機能の説明> |
確認する動作
確認をお願いします。
「問題があって修正したこと」が何もない場合はそのセクションを省略します。
## 制約事項
- 計画ファイルの`Constraints`は必ず守ります — 変更禁止ファイルを変更した場合はすぐに元に戻してください
- Acceptance Criteriaが全てパスしていない状態で終了しません — Phase 3の上限到達時は報告してユーザーに委ねます
- `x-thorough-code-review`スキルは省略しません — 起動できない場合のみ理由を明記してスキップします
- 計画ファイルの更新は必須です — チェックボックス更新と検証結果追記を忘れないでください
## アンチパターン
| アンチパターン | 内容 |
|---|---|
| 実装中の中断 | Phase 3〜6でユーザーに都度確認しません。報告はPhase 7のみです |
| スコープ外の実装 | `Non-goals`に書かれたものは実装しません |
| 検証なし完了 | コンパイルだけ通っても Acceptance Criteriaの検証コマンドを実行しないまま完了しません |
| チェックボックス更新漏れ | Phase 5で計画ファイルの更新を忘れないでください |
