yodogawa 2.0.0 → 2.1.0

package/skills/c-001-implement-task/SKILL.md

@@ -1,521 +1,186 @@
----
-name: c-001-implement-task
-description: 実装タスクリストの各ステップを順次実行し、テスト・レビューを経て機能を完成させるワークフロー（speckit.implementスタイル）
-auto_execution_mode: 1
----
-
-# ImplementTask (c-001)
-
-## 目的
-
-- 実装タスクリスト（`c-implementation.md`）の各ステップを順次実行する。
-- 各ステップの成果物を確実に作成し、実装漏れを防止する。
-- ステップごとにテストを実行し、受け入れ基準を満たすことを確認する。
-- フェーズごとに進捗を管理し、完了状態を可視化する。
-- TDD（テスト駆動開発）アプローチに従い、品質を担保する。
-
-## 前提
-
-- タスクディレクトリが既に作成されていること（`/b-000-CreateTaskDirectory` で作成済み）
-- タスク定義ドキュメント（`a-definition.md`）が作成されていること
-- リサーチドキュメント（`b-research.md`）が作成されていること
-- 実装タスクリスト（`c-implementation.md`）が作成されていること（`/b-003-CreateTaskImplementation` で作成済み）
-- タスクディレクトリ形式: `docs/tasks/task000001-{スラッグ}/`
-- 開発環境がセットアップされていること（必要なツール、ライブラリがインストール済み）
-- Git リポジトリが初期化されていること
-
-## Spec-Kit スタイルの実行フロー
-
-このワークフローは 、以下の原則に従います：
-
-1. **仕様駆動開発**: タスク定義とリサーチドキュメントが実行可能な仕様として機能
-2. **段階的な実装**: 一度にすべてを実装せず、ステップごとに進める
-3. **依存関係の尊重**: ステップの順序を守り、前のステップの完了を確認してから次へ
-4. **並列実行の最適化**: 依存関係のないステップは並列実行を検討
-5. **テスト駆動開発**: 各ステップで適切なテストを実行
-6. **継続的な検証**: 受け入れ基準を常に確認
-
-## 手順
-
-### 1. 実装前の検証
-
-#### 1.1. 必須ドキュメントの存在確認
-
-**検証項目**:
-
-- [ ] タスク定義ドキュメント（`a-definition.md`）が存在するか
-- [ ] リサーチドキュメント（`b-research.md`）が存在するか
-- [ ] 実装タスクリスト（`c-implementation.md`）が存在するか
-
-**検証方法**:
-
-- Read ツールで各ドキュメントを確認
-- いずれかが存在しない場合、該当するワークフローを実行するよう促す
-
-#### 1.2. 実装タスクリストの読み込み
-
-- タスクディレクトリ内の `c-implementation.md` を読み込む
-- 例: `docs/tasks/task000001-email-verification/c-implementation.md`
-
-確認すべき内容:
-
-- **フェーズ一覧**: 実装を何フェーズに分けるか
-- **各フェーズの目的と完了条件**
-- **各フェーズのステップ一覧**
-- **各ステップの成果物と詳細**
-- **受け入れ基準**
-
-#### 1.3. 開発環境の確認
-
-**質問1: 開発環境の準備**
-
-- 「開発環境は準備できていますか？」
-- 必要なツールの確認:
-  - Node.js, npm/yarn/pnpm（フロントエンドの場合）
-  - Python, pip/poetry（Python の場合）
-  - .NET SDK（C# の場合）
-  - データベース（PostgreSQL, MySQL, SQLite など）
-  - その他、タスク固有のツール
-
-**確認コマンド例**:
-
-```bash
-node --version
-npm --version
-git --version
-```
-
-#### 1.4. Git 状態の確認
-
-- 現在のブランチを確認
-- 未コミットの変更がないかチェック
-
-```bash
-git status
-git branch --show-current
-```
-
-**質問2: ブランチ戦略**
-
-- 「このタスク用の新しいブランチを作成しますか？」
-- 推奨ブランチ名: `task/{task-id}` または `feature/{スラッグ}`
-- 例: `task/task000001-email-verification`
-
-### 2. 実装の実行
-
-#### 2.1. 現在のフェーズとステップの特定
-
-**質問3: 開始位置**
-
-- 「どのフェーズ、どのステップから開始しますか？」
-- デフォルト: フェーズ 1、ステップ 1
-
-実装タスクリストの構造を解析:
-
-```markdown
-## フェーズ 1: データモデルと API の実装
-
-### ステップ
-
-- [ ] **ステップ 1:** データベーススキーマの定義
-  - **成果物:** `migrations/001_create_users_table.sql`
-  - **詳細:** User テーブルに `email_verified`, ...
-
-- [ ] **ステップ 2:** TypeScript 型定義の追加
-  - **成果物:** `src/types/User.ts`
-  - **詳細:** `User` インターフェースに...
-```
-
-#### 2.2. ステップの実行ループ
-
-各ステップについて、以下を順次実行:
-
-**ステップ実行の流れ**:
-
-1. **ステップ情報の表示**
-   - 「実行中: フェーズ {N}、ステップ {M}」
-   - ステップ名、成果物、詳細を表示
-
-2. **依存関係の確認**
-   - 前のステップが完了しているか確認
-   - 必要な前提条件が満たされているか確認
-
-3. **実装の実行**
-   - 成果物のファイルを作成または編集
-   - リサーチドキュメントのベストプラクティスに従う
-   - 再利用可能なコンポーネントを活用
-
-4. **コードの説明**
-   - 実装した内容を簡潔に説明
-   - 重要な技術的決定を記録
-
-5. **ローカルテストの実行**
-   - 適切なテストコマンドを実行
-   - TypeScript の場合: `npm run type-check` または `tsc --noEmit`
-   - ユニットテストの場合: `npm test` または `pytest`
-   - リンターの場合: `npm run lint`
-
-6. **エラーハンドリング**
-   - エラーが発生した場合、修正を試みる
-   - 修正できない場合、ユーザーに報告し、ガイダンスを求める
-
-7. **ステップの完了マーク**
-   - 実装タスクリスト（`c-implementation.md`）のチェックボックスを更新
-   - `- [ ]` → `- [x]` に変更
-
-8. **Git コミット（オプション）**
-   - ステップごとにコミットするか確認
-   - コミットメッセージ例: `feat(task-{id}): {ステップ名}`
-
-#### 2.3. 並列実行の最適化
-
-**質問4: 並列実行可能なステップ**
-
-- 「依存関係のないステップは並列実行しますか？」
-- 例: フロントエンドとバックエンドのステップが独立している場合
-
-並列実行可能なステップの例:
-
-```markdown
-- [ ] **ステップ 3:** [P] フロントエンドコンポーネント作成
-- [ ] **ステップ 4:** [P] バックエンド API 実装
-```
-
-`[P]` マークがついたステップは並列実行可能。
-
-### 3. フェーズごとの受け入れ基準の確認
-
-#### 3.1. フェーズ完了時のチェック
-
-各フェーズの全ステップが完了したら、受け入れ基準を確認:
-
-**質問5: 受け入れ基準の確認**
-
-- 「フェーズ {N} の受け入れ基準を確認します。」
-
-実装タスクリストから受け入れ基準を抽出:
-
-```markdown
-### フェーズ 1 の受け入れ基準
-- [ ] データベースマイグレーションが成功する
-- [ ] 型定義が正しく適用される（TypeScript コンパイルエラーなし）
-- [ ] メール送信 API がトークンを生成し、メールを送信する
-- [ ] 無効なトークンでアクセスした場合、エラーが返る
-- [ ] トークンの有効期限切れが正しく検出される
-```
-
-#### 3.2. 受け入れ基準のテスト実行
-
-各受け入れ基準について:
-
-1. **自動テストの実行**
-   - ユニットテスト: `npm test`
-   - 統合テスト: `npm run test:integration`
-   - E2E テスト: `npm run test:e2e`
-
-2. **手動確認が必要な項目**
-   - 「手動で確認が必要な項目があります：」
-   - ユーザーに確認を依頼
-
-3. **結果の記録**
-   - 実装タスクリスト（`c-implementation.md`）の受け入れ基準チェックボックスを更新
-   - `- [ ]` → `- [x]` に変更
-
-#### 3.3. フェーズ完了のコミット
-
-**質問6: フェーズ完了のコミット**
-
-- 「フェーズ {N} が完了しました。コミットしますか？」
-
-コミットメッセージ例:
-
-```
-feat(task-{id}): complete phase {N} - {フェーズ名}
-
-- {ステップ1の概要}
-- {ステップ2の概要}
-- {ステップ3の概要}
-
-受け入れ基準:
-- [x] {基準1}
-- [x] {基準2}
-- [x] {基準3}
-```
-
-### 4. 次のフェーズへの移行
-
-#### 4.1. フェーズ間の依存関係確認
-
-**質問7: 次のフェーズへ進む**
-
-- 「フェーズ {N} が完了しました。次のフェーズ {N+1} に進みますか？」
-
-次のフェーズの前提条件を確認:
-
-- 前フェーズの受け入れ基準がすべて満たされているか
-- 必要な環境設定が完了しているか
-
-#### 4.2. 進捗の可視化
-
-現在の進捗を表示:
-
-```
-進捗状況:
-✅ フェーズ 1: データモデルと API の実装 (完了)
-🔄 フェーズ 2: フロントエンド UI の実装 (進行中)
-⏸️ フェーズ 3: テスト・ドキュメント (未着手)
-
-全体進捗: 33% (3/9 ステップ完了)
-```
-
-### 5. 全フェーズ完了後の最終確認
-
-#### 5.1. 最終テストの実行
-
-**質問8: 最終テスト**
-
-- 「全フェーズが完了しました。最終テストを実行します。」
-
-実行するテスト:
-
-- [ ] 全ユニットテストが通る
-- [ ] 全統合テストが通る
-- [ ] E2E テストが通る（該当する場合）
-- [ ] テストカバレッジが基準を満たす（例: 80%以上）
-- [ ] Lint エラーがない
-- [ ] TypeScript コンパイルエラーがない
-- [ ] ビルドが成功する
-
-テストコマンド例:
-
-```bash
-npm run test:all
-npm run lint
-npm run type-check
-npm run build
-```
-
-#### 5.2. タスク定義の受け入れ基準との照合
-
-- タスク定義ドキュメント（`a-definition.md`）の受け入れ基準を確認
-- 実装がすべての受け入れ基準を満たしているか検証
-
-#### 5.3. ドキュメント更新の確認
-
-**質問9: ドキュメント更新**
-
-- 「以下のドキュメントは更新されていますか？」
-  - README.md（セットアップ手順、使い方）
-  - API ドキュメント（必要に応じて）
-  - 環境変数設定（.env.example）
-  - 変更履歴（CHANGELOG.md）
-
-### 6. コミットとPR作成
-
-#### 6.1. 最終コミット
-
-**質問10: 最終コミット**
-
-- 「実装が完了しました。最終コミットを作成しますか？」
-
-コミットメッセージ例:
-
-```
-feat(task-{id}): implement {タスク概要}
-
-実装内容:
-- {変更1}
-- {変更2}
-- {変更3}
-
-受け入れ基準:
-- [x] {基準1}
-- [x] {基準2}
-- [x] {基準3}
-
-テスト:
-- ユニットテスト: 100% 通過
-- 統合テスト: 100% 通過
-- E2E テスト: 100% 通過
-- カバレッジ: 85%
-
-関連ドキュメント:
-- docs/tasks/task{id}-{スラッグ}/a-definition.md
-- docs/tasks/task{id}-{スラッグ}/b-research.md
-- docs/tasks/task{id}-{スラッグ}/c-implementation.md
-```
-
-#### 6.2. PR作成の提案
-
-**質問11: PR作成**
-
-- 「Pull Request を作成しますか？」
-
-PR タイトル例:
-
-```
-feat(task-{id}): {タスク概要}
-```
-
-PR 説明文例:
-
-```markdown
-## 概要
-{タスクの目的と提供する価値}
-
-## 変更内容
-- {変更1}
-- {変更2}
-- {変更3}
-
-## 受け入れ基準
-- [x] {基準1}
-- [x] {基準2}
-- [x] {基準3}
-
-## テスト結果
-- ユニットテスト: ✅ 100% 通過
-- 統合テスト: ✅ 100% 通過
-- E2E テスト: ✅ 100% 通過
-- カバレッジ: 85%
-
-## スクリーンショット
-（該当する場合）
-
-## 関連ドキュメント
-- [タスク定義](docs/tasks/task{id}-{スラッグ}/a-definition.md)
-- [リサーチ](docs/tasks/task{id}-{スラッグ}/b-research.md)
-- [実装タスクリスト](docs/tasks/task{id}-{スラッグ}/c-implementation.md)
-
-## レビュー観点
-- {観点1}
-- {観点2}
-```
-
-### 7. 完成と次のステップ
-
-- 「タスク {task-id} の実装が完了しました！」
-- 実装完了の確認:
-  - [ ] 全ステップが完了している
-  - [ ] 全受け入れ基準が満たされている
-  - [ ] テストが全て通っている
-  - [ ] ドキュメントが更新されている
-  - [ ] コミットが作成されている
-  - [ ] PR が作成されている（該当する場合）
-
-次のステップの提案:
-
-- 「PR のレビューを依頼しますか？」
-- 「次のタスクに取り掛かりますか？」
-
-## 完了条件
-
-- 実装タスクリスト（`c-implementation.md`）の全ステップが完了している
-- 全ステップのチェックボックスが `[x]` になっている
-- 全フェーズの受け入れ基準が満たされている
-- タスク定義（`a-definition.md`）の受け入れ基準が満たされている
-- 全テストが通っている（ユニット、統合、E2E）
-- Lint エラーがない
-- ビルドが成功している
-- ドキュメントが更新されている
-- Git コミットが作成されている
-- PR が作成されている（該当する場合）
-
-## エスカレーション
-
-- 必須ドキュメントが存在しない場合:
-  - 「{ドキュメント名} が見つかりません。先に該当するワークフローを実行してください：」
-    - タスク定義: `/b-001-CreateTaskDefinition`
-    - リサーチ: `/b-002-CreateTaskResearch`
-    - 実装タスクリスト: `/b-003-CreateTaskImplementation`
-
-- 開発環境が準備できていない場合:
-  - 「必要なツールがインストールされていません：{ツール名}」
-  - インストール方法をガイド
-
-- ステップの実装中にエラーが発生した場合:
-  - 「ステップ {N} の実装中にエラーが発生しました：{エラー内容}」
-  - エラーの原因を分析し、修正を試みる
-  - 修正できない場合、ユーザーに報告し、ガイダンスを求める
-
-- テストが失敗した場合:
-  - 「テストが失敗しました：{テスト名}」
-  - 失敗の原因を分析
-  - 修正が必要なコードを特定
-  - 修正を提案または実行
-
-- 受け入れ基準を満たせない場合:
-  - 「受け入れ基準 {基準} を満たせませんでした。」
-  - 原因を調査し、追加の実装が必要か確認
-  - 受け入れ基準の見直しが必要か検討
-
-- 並列実行でコンフリクトが発生した場合:
-  - 「並列実行したステップ間でコンフリクトが発生しました。」
-  - コンフリクトを解決
-  - 必要に応じて順次実行に切り替え
-
-- 前のステップの完了が確認できない場合:
-  - 「ステップ {N} を実行するには、ステップ {N-1} が完了している必要があります。」
-  - 依存関係を確認し、順序を守る
-
-## 実装ループの詳細フロー
-
-```
-開始
- ↓
-[1] 実装前の検証
- ├─ ドキュメント存在確認
- ├─ 実装タスクリスト読み込み
- ├─ 開発環境確認
- └─ Git 状態確認
- ↓
-[2] フェーズループ開始
- ↓
-[3] ステップループ開始
- ├─ ステップ情報表示
- ├─ 依存関係確認
- ├─ 実装実行
- ├─ コード説明
- ├─ ローカルテスト実行
- ├─ エラーハンドリング
- ├─ ステップ完了マーク
- └─ Git コミット（オプション）
- ↓
-[4] 全ステップ完了？
- No → [3] に戻る
- Yes ↓
-[5] フェーズの受け入れ基準確認
- ├─ 受け入れ基準抽出
- ├─ テスト実行
- ├─ 結果記録
- └─ フェーズ完了コミット
- ↓
-[6] 全フェーズ完了？
- No → [2] に戻る
- Yes ↓
-[7] 最終確認
- ├─ 最終テスト実行
- ├─ タスク定義の受け入れ基準照合
- └─ ドキュメント更新確認
- ↓
-[8] コミットとPR作成
- ├─ 最終コミット
- └─ PR作成
- ↓
-完了
-```
-
-## speckit.implement との対応
-
-| speckit.implement | c-001-ImplementTask | 説明 |
-|-------------------|---------------------|------|
-| constitution ファイル確認 | タスク定義ドキュメント確認 | プロジェクトのガバナンスと標準 |
-| specification ドキュメント確認 | タスク定義・リサーチ確認 | 何を構築するかの仕様 |
-| implementation plan 確認 | 実装タスクリスト確認 | 技術スタックと実装計画 |
-| tasks.md 解析 | c-implementation.md 解析 | タスクの分解と順序 |
-| 依存関係の尊重 | ステップの順序確認 | 正しい順序で実行 |
-| 並列実行の最適化 | [P] マークの識別 | 独立したタスクの並列実行 |
-| TDD アプローチ | 各ステップでのテスト実行 | テスト駆動開発 |
-| ローカル CLI コマンド実行 | Bash ツールでコマンド実行 | npm, dotnet, pytest など |
-| 進捗更新 | チェックボックス更新と進捗表示 | 可視化 |
-| エラーハンドリング | エラー分析と修正提案 | 問題解決 |
+---
+name: c-001-implement-task
+description: c-implementation.md のステップを順次実行し、テスト・レビューを経て機能を完成させる。タスクレビュー後、実装を開始する際に使用（speckit.implement スタイル）。
+disable-model-invocation: true
+argument-hint: "[task-id]"
+---
+
+# ImplementTask (c-001)
+
+## 目的
+
+- 実装タスクリスト（`c-implementation.md`）の各ステップを順次実行する。
+- 各ステップの成果物を確実に作成し、実装漏れを防止する。
+- ステップごとにテストを実行し、受け入れ基準を満たすことを確認する。
+- フェーズごとに進捗を管理し、完了状態を可視化する。
+- TDD（テスト駆動開発）アプローチに従い、品質を担保する。
+
+## 前提
+
+- タスクディレクトリが既に作成されていること（`/b-000-CreateTaskDirectory` で作成済み）
+- タスク定義ドキュメント（`a-definition.md`）が作成されていること
+- リサーチドキュメント（`b-research.md`）が作成されていること
+- 実装タスクリスト（`c-implementation.md`）が作成されていること
+- タスクディレクトリ形式: `docs/tasks/task000001-{スラッグ}/`
+- 開発環境がセットアップされていること（必要なツール、ライブラリがインストール済み）
+- Git リポジトリが初期化されていること
+
+## Spec-Kit スタイルの実行フロー
+
+このスキルは以下の原則に従います：
+
+1. **仕様駆動開発**: タスク定義とリサーチドキュメントが実行可能な仕様として機能
+2. **段階的な実装**: 一度にすべてを実装せず、ステップごとに進める
+3. **依存関係の尊重**: ステップの順序を守り、前のステップの完了を確認してから次へ
+4. **並列実行の最適化**: 依存関係のないステップは並列実行を検討
+5. **テスト駆動開発**: 各ステップで適切なテストを実行
+6. **継続的な検証**: 受け入れ基準を常に確認
+
+実装ループ全体の俯瞰図と speckit.implement との対応は [reference/implementation-loop.md](reference/implementation-loop.md) を参照。
+
+## 手順
+
+`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
+
+### 1. 実装前の検証
+
+**必須ドキュメントの存在確認**:
+
+- [ ] タスク定義ドキュメント（`a-definition.md`）
+- [ ] リサーチドキュメント（`b-research.md`）
+- [ ] 実装タスクリスト（`c-implementation.md`）
+
+いずれかが存在しない場合、該当するスキルを実行するよう促す。
+
+**実装タスクリストの読み込み**:
+
+`c-implementation.md` からフェーズ一覧・各フェーズの目的と完了条件・ステップ一覧・成果物・受け入れ基準を確認する。構造例は [examples/task-list-format.md](examples/task-list-format.md) を参照。
+
+**開発環境とGit 状態の確認**:
+
+```bash
+node --version
+git status
+git branch --show-current
+```
+
+- 必要なツール（言語ランタイム、パッケージマネージャ、DB）の有無を確認。
+- このタスク用の新しいブランチ作成を提案。推奨名: `task/{task-id}` または `feature/{スラッグ}`。
+
+### 2. 実装の実行
+
+**開始位置を確認**: どのフェーズ・ステップから開始するか（デフォルト: フェーズ 1、ステップ 1）。
+
+**各ステップ実行の流れ**:
+
+1. **ステップ情報の表示** — 「実行中: フェーズ {N}、ステップ {M}」＋成果物・詳細
+2. **依存関係の確認** — 前のステップ完了と前提条件の充足を確認
+3. **実装の実行** — 成果物のファイルを作成/編集。リサーチのベスプラと再利用コンポーネントを活用
+4. **コードの説明** — 実装内容と重要な技術的決定を簡潔に記録
+5. **検証ループ（最大 3 回）** — 下記フローで、成功するまで修正を繰り返す。詳細は [reference/validation-loop.md](reference/validation-loop.md) を参照。
+   1. 型チェック / Lint / ユニットテストを実行
+   2. 失敗があれば原因を特定して修正
+   3. 再実行して合格を確認
+   4. 3 回試行しても解決しない場合はユーザーにエスカレーション
+6. **ステップの完了マーク** — 全検証が合格したら `c-implementation.md` のチェックボックスを `- [ ]` → `- [x]` に更新
+7. **Git コミット（オプション）** — コミットメッセージは [examples/commit-and-pr.md](examples/commit-and-pr.md) を参照
+
+**並列実行の最適化**:
+
+`[P]` マークがついたステップは依存関係がなく、並列実行を検討する（詳細は [examples/task-list-format.md](examples/task-list-format.md)）。
+
+### 3. フェーズごとの受け入れ基準の確認
+
+各フェーズの全ステップが完了したら、受け入れ基準を確認：
+
+1. **自動テストの実行**
+   - ユニットテスト: `npm test`
+   - 統合テスト: `npm run test:integration`
+   - E2E テスト: `npm run test:e2e`
+
+2. **手動確認が必要な項目** — ユーザーに確認を依頼
+
+3. **結果の記録** — `c-implementation.md` の受け入れ基準チェックボックスを `- [x]` に更新
+
+4. **フェーズ完了コミット** — コミットメッセージ例は [examples/commit-and-pr.md](examples/commit-and-pr.md)
+
+### 4. 次のフェーズへの移行
+
+- 前フェーズの受け入れ基準がすべて満たされているか確認。
+- 必要な環境設定が完了しているか確認。
+- 進捗を可視化してユーザーに共有（例は [examples/task-list-format.md](examples/task-list-format.md)）。
+
+### 5. 全フェーズ完了後の最終確認
+
+**最終テスト**:
+
+- [ ] 全ユニット / 統合 / E2E テストが通る
+- [ ] テストカバレッジが基準を満たす（例: 80%以上）
+- [ ] Lint エラーがない
+- [ ] TypeScript コンパイルエラーがない
+- [ ] ビルドが成功する
+
+```bash
+npm run test:all
+npm run lint
+npm run type-check
+npm run build
+```
+
+**タスク定義の受け入れ基準との照合**:
+
+`a-definition.md` の受け入れ基準をすべての実装が満たしているか検証。
+
+**ドキュメント更新の確認**:
+
+- README.md（セットアップ手順、使い方）
+- API ドキュメント（必要に応じて）
+- 環境変数設定（.env.example）
+- 変更履歴（CHANGELOG.md）
+
+### 6. コミットと PR 作成
+
+- **最終コミット**: 実装全体のまとめコミットを作成。
+- **PR 作成の提案**: Pull Request を作成するか確認。
+- コミットメッセージ・PR タイトル・PR 本文のテンプレートは [examples/commit-and-pr.md](examples/commit-and-pr.md) を参照。
+
+### 7. 完成と次のステップ
+
+- 「タスク {task-id} の実装が完了しました！」
+- 実装完了チェック:
+  - [ ] 全ステップが完了している
+  - [ ] 全受け入れ基準が満たされている
+  - [ ] テストが全て通っている
+  - [ ] ドキュメントが更新されている
+  - [ ] コミットが作成されている
+  - [ ] PR が作成されている（該当する場合）
+- 次のステップの提案: PR レビュー依頼 or 次のタスク着手。
+
+## 完了条件
+
+- `c-implementation.md` の全ステップチェックボックスが `[x]`
+- 全フェーズの受け入れ基準が満たされている
+- `a-definition.md` の受け入れ基準が満たされている
+- 全テスト（ユニット/統合/E2E）が通っている
+- Lint エラーがない
+- ビルドが成功している
+- ドキュメントが更新されている
+- Git コミットが作成されている
+- PR が作成されている（該当する場合）
+
+## エスカレーション
+
+- **必須ドキュメントが不足**: 「{ドキュメント名} が見つかりません。先に該当スキルを実行してください（タスク定義 → `/b-001` / リサーチ → `/b-002` / 実装タスクリスト → `/b-003`）。」
+- **開発環境が未準備**: 「必要なツールがインストールされていません：{ツール名}」とインストール方法をガイド。
+- **ステップ実装中のエラー**: 原因を分析し修正を試行。修正不能ならユーザーに報告しガイダンスを求める。
+- **テスト失敗**: 失敗の原因を分析し、修正が必要なコードを特定して提案 or 実行。
+- **受け入れ基準が満たせない**: 原因調査 → 追加実装 or 基準の見直しを検討。
+- **並列実行でコンフリクト発生**: コンフリクトを解決、必要に応じて順次実行に切り替え。
+- **前のステップの完了未確認**: 依存関係を確認し、順序を守る。
+
+## 参考
+
+- [reference/implementation-loop.md](reference/implementation-loop.md) — 実装ループの詳細フロー図と speckit.implement 対応
+- [reference/validation-loop.md](reference/validation-loop.md) — 検証ループのフロー、実行コマンド、エスカレーション基準
+- [examples/task-list-format.md](examples/task-list-format.md) — 実装タスクリストの構造・受け入れ基準・進捗表示の例
+- [examples/commit-and-pr.md](examples/commit-and-pr.md) — コミットメッセージと PR テンプレート