yodogawa 2.2.0 → 2.3.0

package/CHANGELOG.md

@@ -5,6 +5,12 @@
 フォーマットは [Keep a Changelog](https://keepachangelog.com/ja/1.0.0/) に基づいており、
 このプロジェクトは [Semantic Versioning](https://semver.org/lang/ja/spec/v2.0.0.html) に準拠しています。
 
+## [2.3.0] - 2026-07-04
+
+### 追加
+
+- **メタ振り返りスキル `d-001-review-retrospective` の新設**: A〜Cシリーズ（または1タスク分のb/cサイクル）完了後に、成果物ドキュメント（`c-implementation.md` の振り返り・`b-research.md` のベストプラクティス・`TASK-REVIEW-REPORT.md`）から摩擦点を収集し、対象 SKILL.md への修正案を diff 形式で提示（チャット＋`RETROSPECTIVE-REPORT.md` へ永続化。適用はユーザー承認制で SKILL.md 自体は編集しない）する新フェーズ `d-NNN`（メタ／横断）の最初のスキルを追加しました（#62）。汎用的な学びは `docs/LESSONS.md`（新設テンプレート `templates/LESSONS.md`）に追記専用ログとして蓄積し、`b-003-create-task-research` が次タスクの調査時に参照する導線を追加しています。蓄積先を Issue 記載の `docs/project/LESSONS.md` ではなく `docs/project/` の外に置くのは、`yodogawa doctor` の `id-trace`/`placeholder` が `docs/project/` 配下を無条件に走査し、過去タスクの ID 言及を trace 切れとして誤検知しうるためです。あわせて `d-NNN` 対応のためリポジトリ整合性チェック（`scripts/repo-check.mjs`）のスキルコード正規表現を拡張し、README のスキル数記載を実数へ訂正しました。
+
 ## [2.2.0] - 2026-07-03
 
 ### 追加

package/README.md

@@ -111,12 +111,13 @@ Why? ─── What? ─── How?
 | 📚 ドキュメントがすぐ陳腐化する     | C-002で実装後にドキュメントを自動更新               |
 | 🐛 設計と実装が乖離する             | B-005レビュー & A-015設計レビューで整合性をチェック |
 | 🤖 AIに何を頼めばいいか分からない   | 事前定義されたワークフローに従うだけ                |
+| 🔁 スキルの品質改善が属人化・散発的になる | D-001が実行後の振り返りをSKILL.md修正案に還元       |
 
 ---
 
 ## スキル一覧
 
-開発ライフサイクルに沿って、**3つのシリーズ**を提供しています。
+開発ライフサイクルに沿って、**4つのシリーズ**を提供しています。
 
 ### A-Series：プロジェクト設計
 
@@ -175,6 +176,16 @@ Why? ─── What? ─── How?
 
 ---
 
+### D-Series：メタ／横断
+
+> A〜Cシリーズ（または1タスク分のb/cサイクル）完了後の振り返りに使用
+
+|  #  | コマンド | 名前                    | 説明                                                                       |
+| :-: | :------- | :---------------------- | :------------------------------------------------------------------------- |
+|  1  | `/d-001` | **Review Retrospective** | 成果物ドキュメントから摩擦点を収集し、SKILL.md修正案の提示とLESSONS.md記録を行う |
+
+---
+
 ## 導入
 
 > ℹ️ 再インストールは既存の `skills/` / `templates/`（方法1・方法3）にマージされます（同名ファイルは上書き、不足ファイルは追加）。スキルの**リネーム・削除を反映するには**、再実行前に対象の `.claude/skills/`・`.claude/templates/`（その他 IDE は `.agents/...`）を手動で削除してください。方法2（Plugin）はファイルをコピーしないため対象外です。
@@ -221,7 +232,7 @@ Claude Code から直接マーケットプレイスを追加してインスト
 
 ### `yodogawa doctor` — ドキュメントの健全性検査
 
-`docs/project/` のトレーサビリティと構造をスクリプトで決定的に検査します。レビュー系スキル（`/a-006` / `/a-015` / `/b-005`）が自然言語で指示していた grep 照合の置き換えです。
+`docs/project/` のトレーサビリティと構造をスクリプトで決定的に検査します。レビュー系スキル（`/a-006` / `/a-015` / `/b-005`）が自然言語で指示していた機械的な検査（存在確認・trace切れ・リンク切れ）をスクリプト実行結果の転記に置き換えます。ただし `/b-005` は対象が `docs/tasks/` のため `links` チェックのみが対象で、他の観点はエージェントの読解判断に基づきます。
 
 ```bash
 yodogawa doctor            # カレントディレクトリを検査（人間可読）
@@ -331,10 +342,10 @@ description: プロジェクトのドキュメントディレクトリ構造を
 
 スキルの中核は `name` / `description` と Markdown 本文ですが、各スキルの frontmatter には Claude Code 向けの拡張フィールドも含まれます。これらは Claude Code で機能し、他 IDE（Cursor / Codex / Antigravity）での扱いは各 IDE の仕様に依存します（本プロジェクトでは未検証）。
 
-- **`disable-model-invocation`**: AIエージェントによる自動呼び出しを無効化（前述）。全 22 スキルに設定。
-- **`allowed-tools`**: スキルに必要な最小限のツール権限を明示。22 スキル中 21（`c-001-implement-task` のみ未指定）。
-- **`argument-hint`**: コマンド引数のヒント（例 `[task-id]`）。引数を取る B/C 系の 7 スキルに設定。
-- **`context: fork`**: Claude Code でレビュー系スキル（`a-006` / `a-015` / `b-005`）を別コンテキストで実行させる指定。メインの作業文脈を汚さずに整合性チェックを行うために採用。
+- **`disable-model-invocation`**: AIエージェントによる自動呼び出しを無効化（前述）。全 25 スキルに設定。
+- **`allowed-tools`**: スキルに必要な最小限のツール権限を明示。25 スキル中 24（`c-001-implement-task` のみ未指定）。
+- **`argument-hint`**: コマンド引数のヒント（例 `[task-id]`）。引数を取る B/C/D 系の 8 スキルに設定。
+- **`context: fork`**: Claude Code でレビュー系スキル（`a-006` / `a-015` / `b-005` / `d-001`）を別コンテキストで実行させる指定。メインの作業文脈を汚さずに整合性チェックを行うために採用。
 
 ### テンプレートは記入欄中心、詳細は reference
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "yodogawa",
-  "version": "2.2.0",
+  "version": "2.3.0",
   "description": "AIネイティブIDE向け仕様駆動開発スキル集",
   "homepage": "https://github.com/tkysi-mi/Yodogawa#readme",
   "repository": {

package/skills/a-006-review-requirements-domain/SKILL.md

@@ -28,53 +28,66 @@ allowed-tools: Read, Grep, Glob, Write, Bash
 
 ## 手順
 
-### 1. ドキュメント存在確認
+### 1. doctor によるドキュメント健全性検査
 
 ```bash
-ls -l docs/project/01-requirements/*.md docs/project/02-behavior/*.md docs/project/03-domain/*.md
+npx -y yodogawa doctor --json
 ```
 
-不足があれば、対応する `/a-002`, `/a-002a`, `/a-002b`, `/a-003`, `/a-004` スキルの実行を促す。
+出力される JSON（`{version, ok, summary, checks[], findings[]}`）をそのまま読み込む。**この段階で `ls` や `grep` を再実装しない。** exit code 1（Error あり）は正常系であり、JSON は必ず stdout に出力される。
 
-### 2. 一貫性チェックの実行
+- `findings` のうち `check: "structure"` かつ `file` が `01-requirements/`・`02-behavior/`・`03-domain/` 配下のものを確認する。必須ファイル・見出しの欠落があれば、対応する `/a-002`, `/a-002a`, `/a-002b`, `/a-003`, `/a-004` スキルの実行を促し、手順2には進まない。
+- `04-design/` 配下に関する `structure` の finding（未着手フェーズ）はこのスキルの対象外なので無視する。
+- `id-trace` / `placeholder` の findings は手順2で観点別に振り分ける（対応表は [reference/consistency-checks.md](reference/consistency-checks.md#doctor-findings-の観点マッピング)）。
+- doctor が実行できない場合（未導入・実行失敗）のみ、代替として `ls -l docs/project/01-requirements/*.md docs/project/02-behavior/*.md docs/project/03-domain/*.md` を実行する。
 
-以下の 7 観点を自動検索（grep 等）と手動確認で検証する。詳細な観点・コマンドは [reference/consistency-checks.md](reference/consistency-checks.md) を参照。
+### 2. 一貫性チェックの実行（観点別 PASS/FAIL + 根拠引用）
 
-- **2.1 ユーザーストーリー ↔ シナリオ**: US-XXX に対応する SC-XXX の存在、価値と結果の整合
-- **2.2 MVP スコープ/実装済み機能 ↔ シナリオ**: Must 機能/リグレッション用のカバレッジ
-- **2.3 クリティカル制約 ↔ スコープ/ドメイン**: Product Brief のクリティカル制約（法務・セキュリティ・期限・予算等）が MVP スコープ判断・ドメインモデルに反映されているか（初期フェーズでは定量 NFR ではなく制約を確認。詳細 NFR は a-014 の責務）
-- **2.4 Core Scenario ↔ Domain Sketch**: アクター・中核エンティティ・重要ビジネスルールの対応（Full DDD 採用時は Command / Event / Actor の対応も）
-- **2.5 ユビキタス言語**: 主要要素の登録、禁止用語の検出
-- **2.6 目的との整合性**: Product Brief の価値提案と Domain Sketch の中核エンティティ（Full DDD 採用時は Core Domain）の一致、および**目的 ↔ 成功指標**の整合・成功指標の計測可能性
-- **2.7 MVP 正当化 / 過剰作り込み（YAGNI）**: 各 Must が課題/ペルソナ/指標/仮説に trace するか、Out of Scope と矛盾しないか、安い代替手段で済むものが Must になっていないか
+以下の 7 観点を **PASS / FAIL** で判定する（判定ルール: 観点内に Error 相当の指摘が1件以上あれば FAIL、Warning 相当のみなら PASS+注記）。詳細な観点・doctor対応関係は [reference/consistency-checks.md](reference/consistency-checks.md) を参照。
+
+> **エージェントの役割範囲**
+>
+> - **doctor 対応観点**: エージェントの役割は doctor の出力（JSON）の解釈と修正提案に限定する。`ls`/`grep`/`jq` 等で同じ検査を再実装しない。
+> - **doctor 非対応観点**: エージェントの役割は「読解判断＋証拠引用」である。Read/Grep/Glob を自由に使って該当ドキュメントを確認し、判定には必ず file:line の引用を伴わせる。
+
+- **2.1 ユーザーストーリー ↔ シナリオ**（一部 doctor 対応）: US-XXX に対応する SC-XXX の存在、価値と結果の整合
+- **2.2 MVP スコープ/実装済み機能 ↔ シナリオ**（doctor 対応）: Must 機能/リグレッション用のカバレッジ
+- **2.3 クリティカル制約 ↔ スコープ/ドメイン**（doctor 非対応）: Product Brief のクリティカル制約（法務・セキュリティ・期限・予算等）が MVP スコープ判断・ドメインモデルに反映されているか（初期フェーズでは定量 NFR ではなく制約を確認。詳細 NFR は a-014 の責務）
+- **2.4 Core Scenario ↔ Domain Sketch**（doctor 非対応）: アクター・中核エンティティ・重要ビジネスルールの対応（Full DDD 採用時は Command / Event / Actor の対応も）
+- **2.5 ユビキタス言語**（doctor 非対応）: 主要要素の登録、禁止用語の検出
+- **2.6 目的との整合性**（doctor 非対応）: Product Brief の価値提案と Domain Sketch の中核エンティティ（Full DDD 採用時は Core Domain）の一致、および**目的 ↔ 成功指標**の整合・成功指標の計測可能性
+- **2.7 MVP 正当化 / 過剰作り込み（YAGNI）**（大半が doctor 非対応）: 各 Must が課題/ペルソナ/指標/仮説に trace するか、Out of Scope と矛盾しないか、安い代替手段で済むものが Must になっていないか
+
+`placeholder` の finding はどの観点にも一対一対応しないため、判断材料としてのみ使う（必要なら該当観点のコメント欄に file:line 付きで補足する）。
 
 ### 3. PM Gate 判定（Go / Go with caveats / No-Go）
 
-一貫性チェック（特に 2.7 の MVP 正当化）の結果をもとに、実装着手の可否を判定する。次のチェックリストで評価する:
+観点別 PASS/FAIL 表から次の規則で機械的に導出する（恣意的な総合判断をしない）:
 
-- [ ] 検証する仮説が 1〜3 個に絞れている
-- [ ] すべての Must 機能が 課題 / ペルソナ / 成功指標 / 検証仮説 のいずれかに紐づいている
-- [ ] Not Now / Won't が明示され、理由が書かれている
-- [ ] 手作業・既存ツール・外部サービスで代替できるものを Must にしていない
-- [ ] ステークホルダー・決裁者・関心事が明確である
-- [ ] クリティカル制約が MVP 判断に反映されている
-- [ ] 未決事項が実装開始を妨げないレベルまで減っている
+- **クリティカル観点**: 2.3（クリティカル制約）/ 2.4（Core Scenario↔Domain Sketch）/ 2.7（MVP正当化）
+- **No-Go**: クリティカル観点のいずれかが FAIL、または FAIL の観点数が3以上
+- **Go with caveats**: FAIL が1〜2件あるが、すべて非クリティカル観点（2.1/2.2/2.5/2.6）
+- **Go**: 全観点 PASS（コメント欄の Warning 注記は着手を妨げない）
 
-判定:
+補助チェックリスト（各項目は対応する観点番号の FAIL/PASS を根拠として引用する）:
 
-- **Go**: 上記をおおむね満たし、重大な Error が無い。
-- **Go with caveats**: 着手可だが条件あり（caveat を明記する）。
-- **No-Go**: 重大な Error / 過剰作り込み / 未決があり、実装前に解消が必要。
+- [ ] 検証する仮説が 1〜3 個に絞れている（→ 2.7）
+- [ ] すべての Must 機能が 課題 / ペルソナ / 成功指標 / 検証仮説 のいずれかに紐づいている（→ 2.7）
+- [ ] Not Now / Won't が明示され、理由が書かれている（→ 2.7）
+- [ ] 手作業・既存ツール・外部サービスで代替できるものを Must にしていない（→ 2.7）
+- [ ] ステークホルダー・決裁者・関心事が明確である（→ 2.6）
+- [ ] クリティカル制約が MVP 判断に反映されている（→ 2.3）
+- [ ] 未決事項が実装開始を妨げないレベルまで減っている（→ 全観点）
 
 ### 4. レビュー結果レポートの作成
 
-検出された問題（Error / Warning / OK）と PM Gate 判定をまとめ、`docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` を作成する。フォーマットは [examples/review-report-template.md](examples/review-report-template.md#レポートフォーマット) を参照。
+観点別 PASS/FAIL の結果と PM Gate 判定をまとめ、`docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` を作成する。フォーマットは [examples/review-report-template.md](examples/review-report-template.md#レポートフォーマット) を参照。
 
 必須セクション:
 
-- サマリー（OK / Warning / Error の件数）
-- 詳細（上記 7 観点ごとの結果。2.7 では**過剰作り込み候補**を明示）
-- PM Gate 判定（Go / Go with caveats / No-Go と根拠）
+- サマリー（観点別 PASS/FAIL の件数。doctor summary の errors/warnings を参考値として併記）
+- 詳細（7 観点ごとの PASS/FAIL・根拠(file:line引用)・コメント。2.7 では**過剰作り込み候補**を明示）
+- PM Gate 判定（Go / Go with caveats / No-Go と、観点別表からの導出根拠）
 - 推奨アクション（修正すべきタスクとスキル参照）
 
 ### 5. ステークホルダー要約 / AI コンテキストの生成
@@ -103,7 +116,7 @@ git commit -m "docs: PM Gate レビュー（要約・AI コンテキスト含む
 ## 完了条件
 
 - `docs/project/REVIEW-REPORT-YYYYMMDDHHMMSS.md` が作成され、7 観点の結果と PM Gate 判定（Go / Go with caveats / No-Go）が記録されている。
-- 全ドキュメント間の整合性がチェックされ、結果（OK/Warning/Error）が記録されている。
+- 全ドキュメント間の整合性がチェックされ、観点ごとの判定（PASS/FAIL）と根拠（file:line引用）が記録されている。doctor対応観点はfindingsの転記、非対応観点は読解判断＋引用になっている。
 - 各 Must 機能の MVP 正当化が検査され、trace しない機能が**過剰作り込み候補**としてフラグされている。
 - `docs/project/STAKEHOLDER-SUMMARY.md` と `docs/project/AI_CONTEXT.md` が生成され、`AI_CONTEXT.md` に「作らないもの（must NOT build）」が明記されている。
 - 具体的な修正アクションが提案されている。
@@ -116,7 +129,7 @@ git commit -m "docs: PM Gate レビュー（要約・AI コンテキスト含む
 
 ## 参考
 
-- [examples/review-report-template.md](examples/review-report-template.md) — レビュー結果レポートのフォーマット例、重大度記号、PM Gate 判定の使い方
-- [reference/consistency-checks.md](reference/consistency-checks.md) — 7 観点（MVP 正当化/YAGNI 含む）の詳細なチェック項目、grep コマンド例、エスカレーション基準
+- [examples/review-report-template.md](examples/review-report-template.md) — レビュー結果レポートのフォーマット例、PASS/FAIL判定ルール、PM Gate 判定の使い方
+- [reference/consistency-checks.md](reference/consistency-checks.md) — doctor findingsの観点マッピング、7 観点（MVP 正当化/YAGNI 含む）の詳細なチェック項目、doctor非対応観点のgrep補助例、エスカレーション基準
 - [../../templates/project/STAKEHOLDER-SUMMARY.md](../../templates/project/STAKEHOLDER-SUMMARY.md) — ステークホルダー向け統合1枚もののテンプレート
 - [../../templates/project/AI_CONTEXT.md](../../templates/project/AI_CONTEXT.md) — AI 実装用の圧縮コンテキストのテンプレート

package/skills/a-006-review-requirements-domain/examples/review-report-template.md

@@ -8,68 +8,63 @@ SKILL.md 手順4 で作成する `docs/project/REVIEW-REPORT-*.md` のフォー
 # ドキュメント一貫性レビュー結果
 
 **実施日**: YYYY-MM-DD
+**doctor**: `yodogawa doctor --json` 実行結果 summary = errors: 2, warnings: 3
 
 ## サマリー
 
-- OK: X 項目
-- Warning: X 項目
-- Error: X 項目
+- 観点別判定: PASS 6 / FAIL 1（全7観点）
+- PM Gate 判定: Go with caveats
 
-## 詳細
+## 詳細（観点別 PASS/FAIL）
 
-### 1. ユーザーストーリー ↔ シナリオ
+| 観点 | 判定 | 根拠（file:line） | コメント |
+|:--|:--:|:--|:--|
+| 2.1 ユーザーストーリー ↔ シナリオ | FAIL | `docs/project/01-requirements/05-user-stories.md:18`: 「ペルソナ: P-999」 | US-005 が参照する P-999 が product-brief 未定義（doctor id-trace error）。逆方向coverage・「価値」↔「Then」整合は未確認（doctor非対応部分） |
+| 2.2 MVP スコープ ↔ シナリオ | PASS | `docs/project/02-behavior/01-core-scenarios.md:40`: 「## CS-003 決済」 | 全 Must がシナリオでカバー済み（doctor id-trace: FN未参照Warningなし） |
+| 2.3 クリティカル制約 ↔ スコープ/ドメイン | PASS | `docs/project/01-requirements/01-product-brief.md:23`: 「社内SSO必須」 | MVP Scope・ドメインに反映確認済み（Read手動確認、doctor非対応） |
+| 2.4 Core Scenario ↔ Domain Sketch | PASS | `docs/project/02-behavior/01-core-scenarios.md:52`: 「在庫を引き当てる」 | Domain Sketch の重要ビジネスルールに対応記述あり（Read手動確認、doctor非対応） |
+| 2.5 ユビキタス言語 | PASS | `docs/project/03-domain/02-ubiquitous-language.md:9`: 「ShippingAddress」 | 用語登録済み。禁止用語なし（Read手動確認、doctor非対応） |
+| 2.6 目的との整合性 | PASS | `docs/project/01-requirements/01-product-brief.md:30`: 「North Star: 週次アクティブ率」 | 価値提案と成功指標は整合（Read手動確認、doctor非対応） |
+| 2.7 MVP正当化/過剰作り込み | PASS | `docs/project/01-requirements/02-mvp-scope.md:15`: 「実績バッジ→Not Now」 | 全MustがProduct Briefの課題/指標/仮説にtrace済み（Read手動確認）。注記(Warning): 孤児ペルソナ `01-product-brief.md:8` P-004 が `05-user-stories.md` から未参照（doctor id-trace warning）。過剰ペルソナの可能性、次回改訂で確認 |
 
-- **Error**: US-005 に対応するシナリオが見つかりません。
-- OK: 優先度 High のストーリーはすべてカバーされています。
-
-### 2. MVP スコープ・クリティカル制約
-
-- **Warning**: 実装済み機能「決済」のシナリオが不足しています。
-- OK: Product Brief のクリティカル制約「社内 SSO 必須」が MVP スコープ・ドメインに反映されています。
-
-### 3. シナリオ ↔ ドメインモデル
-
-- **Warning**: シナリオ SC-003 の Command「在庫を引き当てる」がドメインモデルに未定義です。
-
-### 4. ユビキタス言語
-
-- **Error**: 用語「ShippingAddress」がユビキタス言語一覧にありません。
-- **Warning**: 禁止用語「User Data」が `01-domain-sketch.md` で使用されています。
-
-### 5. MVP 正当化 / 過剰作り込み（YAGNI）
+## PM Gate 判定
 
-- **過剰作り込み候補**: Must 機能「実績バッジ」が課題・ペルソナ・成功指標のいずれにも trace しません。Not Now / Won't への変更を検討してください。
-- OK: その他の Must はすべて検証仮説・成功指標に紐づいています。
-- OK: Out of Scope（Won't）と矛盾する実装記述はありません。
+観点別 PASS/FAIL 表から次の規則で導出する（恣意的な総合判断をしない）。
 
-## PM Gate 判定
+- クリティカル観点（2.3/2.4/2.7）はすべて PASS
+- FAIL は 2.1（非クリティカル）の1件のみ → 「Go with caveats」の条件（FAIL1〜2件、すべて非クリティカル）に合致
 
 **判定**: Go with caveats
 
-**根拠**: 整合性は良好。ただし Must「実績バッジ」が正当化されていないため、スコープから外すことを条件に実装着手可。
+**根拠**: FAIL = 2.1（1件、非クリティカル）。クリティカル観点（2.3/2.4/2.7）はすべて PASS。
+
+**caveat**:
+1. 2.1: US-005 のペルソナ参照修正を条件に着手可
 
 ## 推奨アクション
 
-1. `02-mvp-scope.md` の「実績バッジ」を Won't に変更する（過剰作り込み）。
-2. `/a-003-create-scenarios` で US-005 のシナリオを追加する。
-3. `01-domain-sketch.md` の「User Data」を「User Profile」に修正する。
+1. `docs/project/01-requirements/05-user-stories.md` の US-005 ペルソナ参照を修正する。
+2. （Warning注記）孤児ペルソナ P-004 がスコープ漏れか過剰ペルソナか、次回改訂で確認する。
 ```
 
-## 重大度記号の使い方
+## 判定ルールの使い方
 
-| 記号 | 意味 | 対応 |
+| 判定 | 意味 | 根拠列の要件 |
 |:--|:--|:--|
-| OK | 問題なし | 記録のみ |
-| Warning | 軽微な不整合 | 計画的に修正 |
-| Error | 重大な不整合 | 実装前に必ず修正 |
+| PASS | 観点内に Error 相当の指摘が無い | Warning相当の注記があれば file:line 付きでコメント欄に残す（消さない） |
+| FAIL | 観点内に Error 相当の指摘が1件以上 | 根拠列に file:line と該当行の引用が1件以上必須 |
+
+doctor findingsを転記する場合も、`message`をそのままコピペせず、file:lineをReadで開いて実際の行を引用する（詳細は[reference/consistency-checks.md](../reference/consistency-checks.md#doctor-findings-の観点マッピング)）。
 
 ## PM Gate 判定の使い方
 
-| 判定 | 意味 | 次のアクション |
+観点別 PASS/FAIL 表からの機械的導出規則（SKILL.md 手順3参照）:
+
+| 判定 | 導出条件 | 次のアクション |
 |:--|:--|:--|
-| Go | 実装着手してよい | `AI_CONTEXT.md` を実装エージェントへ渡す |
-| Go with caveats | 条件付きで着手可 | caveat を明記し、合意の上で着手 |
-| No-Go | 重大課題あり | 実装前に該当ドキュメントを修正し再レビュー |
+| Go | 全観点 PASS | `AI_CONTEXT.md` を実装エージェントへ渡す |
+| Go with caveats | FAILが1〜2件、すべて非クリティカル観点（2.1/2.2/2.5/2.6） | caveat を明記し、合意の上で着手 |
+| No-Go | クリティカル観点（2.3/2.4/2.7）がFAIL、またはFAIL総数3以上 | 実装前に該当ドキュメントを修正し再レビュー |
 
 ## コミットメッセージ例
 

package/skills/a-006-review-requirements-domain/reference/consistency-checks.md

@@ -1,46 +1,50 @@
 # 一貫性チェック項目詳細
 
-SKILL.md 手順2 で実施する各チェック項目の詳細。自動検索（grep 等）と手動確認を組み合わせる。
+SKILL.md 手順2 で実施する各チェック項目の詳細。doctor が機械的に検出する部分は findings の転記、doctor 非対応の意味内容の判断は Read/Grep による手動確認＋file:line 引用の組み合わせで検証する。
 
-## 2.1 ユーザーストーリー ↔ Core Scenario
+## doctor findings の観点マッピング
 
-- **カバレッジ**: MVP Scope の Must 機能に対応する Core Scenario（Day 1 Happy Path）が存在するか。User Story は要約 AC、Core Scenario は実行時の主要行動という SSoT の住み分けを保つ（全 US を逐一シナリオ化しない）。
-- **整合性**: ストーリーの「価値」と Core Scenario の「結果（Then）」が一致しているか。
+`yodogawa doctor --json`（手順1）の `findings[]` は `docs/project` 配下のみを検査対象とし、`{check, severity, file, line, message}` を返す。以下の対応表に従い、該当する観点へ**そのまま転記**する（grep での再実装はしない）。file:line は Read で開いて実際の行を引用すること（message は合成文のため、原文の引用を別途添える）。
 
-```bash
-# 全ユーザーストーリーの ID 抽出
-grep -oE "US-[0-9]+" docs/project/01-requirements/05-user-stories.md | sort -u
-# Core Scenario 側の対応 Must / フロー参照
-grep -oE "FN-[0-9]+|CS-[0-9]+" docs/project/02-behavior/01-core-scenarios.md | sort -u
-```
+| doctor check | finding 条件 | severity | 対応観点 | 備考 |
+|---|---|---|---|---|
+| `id-trace` | `id` が `US-` の finding（trace切れ） | error | 2.1 | US 側の片方向 trace 切れのみ検出。逆方向（Core Scenario→US の対応漏れ）とストーリーの「価値」↔シナリオ「Then」の整合は非対応（Read で確認） |
+| `id-trace` | `id` が `P-` の finding（trace切れ） | error | 2.1（役割↔ペルソナ） | `05-user-stories.md` が参照する未定義ペルソナ |
+| `id-trace` | `id` が `P-` の finding（孤児＝`05-user-stories.md`から未参照） | warning | 2.7（傍証） | 孤児ペルソナの検出のみ。Must の trace 判断そのものの代替にはならない |
+| `id-trace` | `id` が `FN-` の finding（trace切れ） | error | 2.2 | |
+| `id-trace` | `id` が `FN-` の finding（`02-behavior/01-core-scenarios.md` から未参照） | warning | 2.2 | Must機能のシナリオカバレッジ。doctor が最も強くカバーする部分 |
+| `structure` | `file` が `01-requirements/`〜`03-domain/` 配下 | error/warning | 手順1（前提） | 観点表には含めない。存在確認・必須見出しの欠落シグナル |
+| `placeholder` | 同上 | warning | 参考情報 | どの観点にも一対一対応しない。未記入セクションの兆候として補足に使う程度 |
 
-### ユーザーストーリーの役割 ↔ ペルソナ（trace）
+**doctor が対応しない観点（2.3〜2.6、2.7の大半）は、上記マッピングに現れない。エージェントが Read/Grep で内容を確認し、判定には file:line の引用を必須とする。**
 
-- **役割が宙に浮かない**: `05-user-stories.md` の各ストーリーの「ペルソナ」列が、`01-product-brief.md` のペルソナ表で定義済みの ID（P-XXX）を参照しているか。**未定義のペルソナを参照する US はフラグ**する（役割の trace 切れ）。
-- **逆方向（任意）**: どの US からも参照されない主要ペルソナがあれば、スコープ漏れか過剰ペルソナのどちらかとして確認する。
+## 2.1 ユーザーストーリー ↔ Core Scenario
 
-```bash
-# US が参照するペルソナ ID のうち、Product Brief に未定義のもの（出力があれば trace 切れ）
-comm -23 \
-  <(grep -oE "P-[0-9]+" docs/project/01-requirements/05-user-stories.md | sort -u) \
-  <(grep -oE "P-[0-9]+" docs/project/01-requirements/01-product-brief.md | sort -u)
-```
+- **カバレッジ**: MVP Scope の Must 機能に対応する Core Scenario（Day 1 Happy Path）が存在するか。User Story は要約 AC、Core Scenario は実行時の主要行動という SSoT の住み分けを保つ（全 US を逐一シナリオ化しない）。doctor 非対応（上記マッピング表参照）。Read で `05-user-stories.md` と `02-behavior/01-core-scenarios.md` を確認する。
+- **整合性**: ストーリーの「価値」と Core Scenario の「結果（Then）」が一致しているか。doctor 非対応。
+
+### ユーザーストーリーの役割 ↔ ペルソナ（trace）
+
+- **役割が宙に浮かない**: `05-user-stories.md` の各ストーリーの「ペルソナ」列が、`01-product-brief.md` のペルソナ表で定義済みの ID（P-XXX）を参照しているか。**未定義のペルソナを参照する US はフラグ**する（役割の trace 切れ）。doctor の `id-trace`（P族 trace切れ、上記マッピング表）をそのまま転記する。
+- **逆方向（任意）**: どの US からも参照されない主要ペルソナがあれば、スコープ漏れか過剰ペルソナのどちらかとして確認する。doctor の `id-trace`（P族 孤児、severity=warning）で検出できる。
 
 ## 2.2 MVP スコープ・実装済み機能 ↔ シナリオ
 
-- **MVP スコープ**: `02-mvp-scope.md` の Must 機能にシナリオが存在するか。
-- **実装済み機能**: `06-features-implemented.md`（existing モード）の機能にリグレッション用シナリオが存在するか。
-- **Parking Lot**: `03-parking-lot.md` は backlog のためシナリオ必須ではない（MVP 昇格時に MVP スコープ側で扱う）。
+- **MVP スコープ**: `02-mvp-scope.md` の Must 機能にシナリオが存在するか。doctor の `id-trace`（FN族、上記マッピング表）がそのまま使える。
+- **実装済み機能**: `06-features-implemented.md`（existing モード）の機能にリグレッション用シナリオが存在するか。同じく FN 族で検出される。
+- **Parking Lot**: `03-parking-lot.md` は backlog のためシナリオ必須ではない（MVP 昇格時に MVP スコープ側で扱う）。doctor 非対応（この除外判断自体は Read で確認）。
 
 ## 2.3 クリティカル制約 ↔ スコープ/ドメイン
 
-初期フェーズでは定量 NFR ではなく、Product Brief の「クリティカル制約」を確認する（詳細な定量 NFR は設計フェーズ `/a-014-define-infrastructure` の責務）。
+初期フェーズでは定量 NFR ではなく、Product Brief の「クリティカル制約」を確認する（詳細な定量 NFR は設計フェーズ `/a-014-define-infrastructure` の責務）。**doctor 非対応。** doctor は制約の「反映」という意味内容を判断できないため、Read で確認し file:line を引用する。
 
 - **制約の反映**: `01-product-brief.md` のクリティカル制約（法務・セキュリティ・期限・予算・外部 API 等）が `02-mvp-scope.md` の Must 判断やドメインモデルに反映されているか。
 - **セキュリティ・権限**: 制約に挙げた認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
 
 ## 2.4 Core Scenario ↔ Domain Sketch
 
+**doctor 非対応。** Core Scenario ↔ Domain Sketch の対応関係を機械検査する ID 族は存在しない。Read で確認し file:line を引用する。
+
 - **アクター**: Core Scenario のアクターが Domain Sketch の「アクター / 外部システム」に存在するか。
 - **中核エンティティ**: Core Scenario が扱う対象が Domain Sketch の「中核エンティティ」に定義されているか。
 - **重要ルール**: Critical Failure を防ぐルールが「重要なビジネスルール」に反映されているか。
@@ -48,8 +52,10 @@ comm -23 \
 
 ## 2.5 ユビキタス言語の遵守
 
+**doctor 非対応。**
+
 - **用語定義**: Domain Sketch の主要用語・中核エンティティ（Full DDD 採用時は Aggregate / Command / Event）がユビキタス言語一覧にあるか。
-- **禁止用語**: 各ドキュメントに禁止用語（Data, Process, Manager 等）が使われていないか。
+- **禁止用語**: 各ドキュメントに禁止用語（Data, Process, Manager 等）が使われていないか。**用語の意味判断は doctor では担保できないため、以下の grep は補助検索として引き続き手動実行する（doctor で代替できない）。**
 
 ```bash
 # 禁止用語の簡易検索
@@ -60,6 +66,8 @@ grep -rn "Manager" docs/project/03-domain/ || echo "No 'Manager' found"
 
 ## 2.6 目的との整合性
 
+**doctor 非対応。**
+
 - Product Brief（`01-product-brief.md`）の「価値提案 / 差別化」が Domain Sketch の「中核エンティティ」「重要なビジネスルール」に反映されているか。
 - **価値提案の充足**: 「価値提案 / 差別化」のバリュープロポジション（1文）と差別化ポイント（Why us）が埋まり、Why us が「現在の代替手段・競合スキャン」表の各「弱み」と対応づいているか（漠然と「使いやすい」で済ませていないか）。
 - **目的 ↔ 成功指標**: Product Brief の成功指標（North Star / KPI / Guardrail）が「価値提案 / 解く課題」と整合しているか（目的と無関係な指標を測っていないか）。
@@ -68,10 +76,10 @@ grep -rn "Manager" docs/project/03-domain/ || echo "No 'Manager' found"
 
 ## 2.7 MVP 正当化 / 過剰作り込み（YAGNI / PM Gate）
 
-「要らないものを作らない」を守るためのスコープ妥当性検査。
+「要らないものを作らない」を守るためのスコープ妥当性検査。**大半が doctor 非対応。** 孤児ペルソナ（doctor `id-trace` P族 warning、上記マッピング表）は過剰作り込みの傍証になるが、Must の trace 判断そのものの代替にはならない。以下は Read で確認し file:line を引用する。
 
 - **Must の trace**: `02-mvp-scope.md` の各 Must 機能が、Product Brief の 課題 / ターゲット（ペルソナ）/ 成功指標 / 検証仮説 のいずれかに紐づくか。**いずれにも trace しない Must は過剰作り込み候補としてフラグ**する。
-- **Out of Scope の矛盾**: `02-mvp-scope.md` の Won't / Out of Scope に挙げた機能が、他ドキュメント（シナリオ・ドメインモデル・`05-user-stories.md`）で実装対象として記述されていないか。
+- **Out of Scope の矛盾**: `02-mvp-scope.md` の Won't / Out of Scope に挙げた機能が、他ドキュメント（シナリオ・ドメインモデル・`05-user-stories.md`）で実装対象として記述されていないか。doctor では代替できないため、以下の grep は補助検索として引き続き手動実行する。
 - **安い代替手段**: 手作業・既存ツール・外部サービスで足りるものが Must になっていないか（`02-mvp-scope.md` の「より安い代替手段」列を確認）。
 - **仮説の数**: 検証する仮説が 1〜3 個に絞れているか（多すぎる＝MVP が過大）。
 

package/skills/a-015-review-design/SKILL.md

@@ -29,17 +29,19 @@ allowed-tools: Read, Grep, Glob, Write, Bash
 
 ## 手順
 
-### 1. ドキュメント存在確認
+### 1. doctor によるドキュメント健全性検査
 
 ```bash
-ls -l docs/project/04-design/*.md
+npx -y yodogawa doctor --json
 ```
 
-不足しているドキュメントがあれば、対応するスキルの実行を促す。
+`findings` から `check: "structure"` かつ `file` が `docs/project/04-design/` で始まる項目を確認し、必須ファイル・見出しの欠落があれば対応するスキル（a-007〜a-014）の実行を促す。**`id-trace` は 04-design 配下を対象にした ID 体系を持たないため、5観点すべてに直接的な機械判定は無い**（`bin/lib/project-spec.js` の `ID_FAMILIES` に 04-design 向けの族が定義されていないため）。`placeholder`/`links` の finding は前提整合性の補助シグナルとして使う（未記入セクション・リンク切れの有無）。doctor が実行できない場合のみ、代替として `ls -l docs/project/04-design/*.md` を実行する。
 
-### 2. 一貫性チェックの実行
+### 2. 一貫性チェックの実行（観点別 PASS/FAIL + 根拠引用）
 
-以下の 5 観点を自動検索（grep 等）と手動確認で検証する。詳細な観点・コマンドは [reference/consistency-checks.md](reference/consistency-checks.md) を参照。
+以下の 5 観点を **PASS / FAIL** で判定する（判定ルール: 観点内に Error 相当の指摘が1件以上あれば FAIL、Warning 相当のみなら PASS+注記）。**doctor の id-trace は 04-design を検査対象にしないため、2.1〜2.5 のすべてがエージェント自身の Read/Grep による判断**になる。各判定には file:line の引用を必須とする（詳細は [reference/consistency-checks.md](reference/consistency-checks.md)）。
+
+> **エージェントの役割範囲**: doctor が既に検査済みの機械的観点（手順1の存在確認）は再実装しない。一方、この手順2の5観点はすべて doctor 非対応の意味判断であり、役割は「読解判断＋証拠引用」である。Read/Grep/Glob を自由に使ってよい（むしろ必須）。判断した結果は必ず file:line の引用を伴わせる。
 
 - **2.1 テックスタック ↔ アーキテクチャ**: 選定技術の反映、ADR の記録
 - **2.2 データモデル ↔ ドメインモデル**: Aggregate のカバレッジ、用語統一
@@ -47,14 +49,16 @@ ls -l docs/project/04-design/*.md
 - **2.4 画面設計 ↔ API 仕様**: 必要なエンドポイントのカバレッジ、状態対応
 - **2.5 インフラ ↔ アーキテクチャ**: 構成の網羅、非機能要件の反映
 
+`structure`/`placeholder`/`links` の finding は各観点に一対一対応しないため、判断材料としてのみ利用する。
+
 ### 3. レビュー結果レポートの作成
 
-検出された問題（Error / Warning / OK）をまとめ、`docs/project/DESIGN-REVIEW-REPORT-YYYYMMDDHHMMSS.md` を作成する。フォーマットは [examples/review-report-template.md](examples/review-report-template.md#レポートフォーマット) を参照。
+観点別 PASS/FAIL の結果をまとめ、`docs/project/DESIGN-REVIEW-REPORT-YYYYMMDDHHMMSS.md` を作成する。フォーマットは [examples/review-report-template.md](examples/review-report-template.md#レポートフォーマット) を参照。
 
 必須セクション:
 
-- サマリー（OK / Warning / Error の件数）
-- 詳細（上記 5 観点ごとの結果）
+- サマリー（観点別 PASS/FAIL の件数）
+- 詳細（上記 5 観点ごとの PASS/FAIL・根拠(file:line引用)・コメント）
 - 推奨アクション（修正すべきタスクとスキル参照）
 
 ### 4. 結果の報告と修正提案
@@ -73,7 +77,7 @@ git commit -m "docs: 設計整合性レビューレポートの作成"
 ## 完了条件
 
 - `docs/project/DESIGN-REVIEW-REPORT-YYYYMMDDHHMMSS.md` が作成されている。
-- 全設計ドキュメント間の整合性がチェックされ、結果（OK/Warning/Error）が記録されている。
+- 全設計ドキュメント間の整合性がチェックされ、観点ごとの判定（PASS/FAIL）と根拠（file:line引用）が記録されている。
 - 具体的な修正アクションが提案されている。
 
 ## エスカレーション
@@ -84,5 +88,5 @@ git commit -m "docs: 設計整合性レビューレポートの作成"
 
 ## 参考
 
-- [examples/review-report-template.md](examples/review-report-template.md) — レビュー結果レポートのフォーマット例、重大度記号
-- [reference/consistency-checks.md](reference/consistency-checks.md) — 5 観点の詳細なチェック項目、grep コマンド例、エスカレーション基準
+- [examples/review-report-template.md](examples/review-report-template.md) — レビュー結果レポートのフォーマット例、PASS/FAIL判定ルール
+- [reference/consistency-checks.md](reference/consistency-checks.md) — 5 観点の詳細なチェック項目（すべてdoctor非対応）、grep補助例、エスカレーション基準

package/skills/a-015-review-design/examples/review-report-template.md

@@ -8,49 +8,37 @@ SKILL.md 手順3 で作成する `docs/project/DESIGN-REVIEW-REPORT-*.md` のフ
 # 設計ドキュメント一貫性レビュー結果
 
 **実施日**: YYYY-MM-DD
+**doctor**: `structure` 検査のみ利用（04-design配下の存在確認）。`id-trace` は 04-design 非対応のため5観点はすべてRead手動確認。
 
 ## サマリー
 
-- OK: X 項目
-- Warning: X 項目
-- Error: X 項目
+- 観点別判定: PASS 3 / FAIL 2（全5観点）
+- 総合: FAIL（FAIL観点: 2.2, 2.4）
 
-## 詳細
+## 詳細（観点別 PASS/FAIL）
 
-### 1. テックスタック ↔ アーキテクチャ
-
-- OK: 選定技術はアーキテクチャパターンに適合しています。
-
-### 2. データモデル ↔ ドメインモデル
-
-- **Error**: Aggregate「Order」に対応するテーブル定義が見つかりません。
-
-### 3. API 仕様 ↔ データモデル
-
-- **Warning**: API レスポンスのフィールド `user_rank` がデータモデルにありません。
-
-### 4. 画面設計 ↔ API 仕様
-
-- **Error**: 「注文履歴画面」に必要な `GET /api/orders/history` が定義されていません。
-
-### 5. インフラ ↔ アーキテクチャ
-
-- OK: 冗長化構成はアーキテクチャの可用性要件を満たしています。
+| 観点 | 判定 | 根拠（file:line） | コメント |
+|:--|:--:|:--|:--|
+| 2.1 テックスタック ↔ アーキテクチャ | PASS | `docs/project/04-design/07-architecture.md:14`: 「PostgreSQL, Redis」 | tech-stackの選定技術がarchitecture図に反映（Read手動確認） |
+| 2.2 データモデル ↔ ドメインモデル | FAIL | `docs/project/03-domain/01-domain-sketch.md:20`: 「中核エンティティ: Order」 | Aggregate「Order」に対応するテーブル定義が `05-data-model.md` に無い |
+| 2.3 API仕様 ↔ データモデル | PASS | `docs/project/04-design/06-api-spec.md:33`: 「user_rank」 | データモデルの派生フィールドとして明示あり |
+| 2.4 画面設計 ↔ API仕様 | FAIL | `docs/project/04-design/03-screen-design.md:41`: 「注文履歴画面」 | `GET /api/orders/history` が定義されていない |
+| 2.5 インフラ ↔ アーキテクチャ | PASS | `docs/project/04-design/08-infrastructure.md:10`: 「Multi-AZ構成」 | 可用性要件を満たす |
 
 ## 推奨アクション
 
 1. `/a-011-define-data-model` で `orders` テーブルを定義する。
 2. `/a-012-define-api-spec` で `GET /api/orders/history` を追加する。
-3. `/a-011-define-data-model` で `user_rank` のカラム追加を検討する。
 ```
 
-## 重大度記号の使い方
+## 判定ルールの使い方
 
-| 記号 | 意味 | 対応 |
+| 判定 | 意味 | 根拠列の要件 |
 |:--|:--|:--|
-| OK | 問題なし | 記録のみ |
-| Warning | 軽微な不整合 | 計画的に修正 |
-| Error | 重大な不整合 | タスク分解前に必ず修正 |
+| PASS | 観点内に Error 相当の指摘が無い | Warning相当の注記があれば file:line 付きでコメント欄に残す（消さない） |
+| FAIL | 観点内に Error 相当の指摘が1件以上 | 根拠列に file:line と該当行の引用が1件以上必須 |
+
+5観点すべてdoctor非対応のため、判定は必ずRead/Grepによる手動確認＋file:line引用で行う（[reference/consistency-checks.md](../reference/consistency-checks.md)参照）。
 
 ## コミットメッセージ例
 

package/skills/a-015-review-design/reference/consistency-checks.md

@@ -1,14 +1,16 @@
 # 設計ドキュメント間の一貫性チェック項目
 
-SKILL.md 手順2 で実施する 5 観点の詳細。自動検索（grep 等）と手動確認を組み合わせる。
+SKILL.md 手順2 で実施する 5 観点の詳細。**5観点すべて doctor 非対応**（`bin/lib/project-spec.js` の `ID_FAMILIES` に 04-design 向けの ID 族が定義されていないため、`id-trace` は 04-design 配下を検査対象にしない）。手順1の doctor 呼び出しは `structure` チェックによる存在確認・必須見出し確認にのみ使う。5観点はすべて Read/Grep による手動確認＋file:line引用で判定する。
 
 ## 2.1 テックスタック ↔ アーキテクチャ
 
 - **整合性**: `01-tech-stack.md` で選定された技術がアーキテクチャ図（`07-architecture.md`）のコンポーネントと一致しているか。
 - **ADR**: 重要な技術選定理由が ADR として記録されているか。
 
+以下の grep は固定語リストによる補助検索であり、判定の代わりにはならない（新しい技術選定が語彙に含まれず検出漏れになりうる）。判定は必ず Read で該当箇所を確認し file:line を引用して行う。
+
 ```bash
-# tech-stack で挙がった技術が architecture に登場するか
+# tech-stack で挙がった技術が architecture に登場するか（補助検索）
 grep -oE "PostgreSQL|Redis|NestJS|Next.js" docs/project/04-design/01-tech-stack.md | sort -u
 grep -oE "PostgreSQL|Redis|NestJS|Next.js" docs/project/04-design/07-architecture.md | sort -u
 ```

package/skills/b-003-create-task-research/SKILL.md

@@ -19,6 +19,7 @@ argument-hint: "[task-id]"
 - `CreateTaskDefinition (b-002)` が完了し、`a-definition.md` に目的・変更内容が記載されている。
 - タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
 - テンプレート: `../../templates/tasks/task-template/b-research.md`（スキル配置ディレクトリ起点の相対参照）
+- `docs/LESSONS.md` があれば参照する（`d-001-review-retrospective` が過去タスクの振り返りから蓄積する汎用的な学び。無ければスキップ）。
 
 ## 手順
 
@@ -49,6 +50,7 @@ ls -d docs/tasks/task*
 
 ### 4. ベストプラクティス・外部情報の調査
 
+- `docs/LESSONS.md` が存在すれば読み、過去タスクの摩擦点・ベストプラクティスを踏まえる（無ければスキップ）。
 - 公式ドキュメント、信頼できる記事、社内ナレッジを確認し、採用すべきパターン/アンチパターンを整理。
 - 調査内容（タイトル、要点、URL）を記録。例）フォームバリデーション、非同期通信、セキュリティガイドライン。
 

package/skills/b-005-review-task/SKILL.md

@@ -32,14 +32,27 @@ ls -d docs/tasks/task*
 
 - レビュー対象のタスクIDとスラッグを特定。
 - 不足ドキュメントがあれば該当スキル(b-002/b-003/b-004)に差し戻す。
+- **注記**: この存在確認は doctor では代替できない。`yodogawa doctor` の `structure`/`id-trace`/`placeholder` は `docs/project/` 固定で `docs/tasks/` を検査対象にしないため、ここは従来どおり `ls`/`Glob` で確認する。
 
-### 2. 各ドキュメントの読み込み
+### 2. 前提整合性の自動検査（doctor links のみ）
+
+```bash
+npx -y yodogawa doctor --json
+```
+
+`findings` のうち `check: "links"` かつ `file` が `docs/tasks/task{ID}-{SLUG}/` で始まる項目のみを確認する（`links` は `docs/` 全体を検査対象にする唯一のチェックのため、docs/tasks 内の相対リンク切れはここで拾える）。**`structure`/`id-trace`/`placeholder` の finding はこのタスクディレクトリに関係しないため無視する。** リンク切れがあれば前提整合性 FAIL としてレポートの「前提整合性」節に記録する（手順4の観点別 PASS/FAIL とは別枠）。doctor が実行できない場合は前提整合性の確認を省略してよい。
+
+### 3. 各ドキュメントの読み込み
 
 - `a-definition.md`: 目的/ユーザーストーリー/変更内容/受け入れ基準
 - `b-research.md`: ベストプラクティス/再利用コード/技術選定/リスク
 - `c-implementation.md`: フェーズ/ステップ/成果物/テスト計画
 
-### 3. 一貫性チェック
+### 4. 一貫性チェック（観点別 PASS/FAIL + 根拠引用）
+
+以下の 6 観点は**すべて doctor 非対応**（`structure`/`id-trace`/`placeholder` が `docs/tasks/` を検査対象にしないため）。エージェントが `a-definition.md` / `b-research.md` / `c-implementation.md` を Read して判断し、判定には file:line の引用を必須とする（判定ルール: 観点内に Error 相当の指摘が1件以上あれば FAIL、Warning 相当のみなら PASS+注記）。
+
+> **エージェントの役割範囲**: 手順2の doctor links チェックは出力の解釈と修正提案に限定する（再実装しない）。この手順4の6観点はすべて doctor 非対応の意味判断であり、役割は「読解判断＋証拠引用」である。
 
 | # | 観点 | チェック内容 |
 |---|------|--------------|
@@ -50,11 +63,9 @@ ls -d docs/tasks/task*
 |5|実装計画の完全性|フェーズ順序・ステップ粒度・テスト計画が適切か|
 |6|タスク全体の実現性|目的/スコープ/依存関係/期間が妥当か|
 
-チェックの際は `OK / Warning / Error` を付与し、根拠をメモする。
-
-各観点のチェックリスト・検出すべき問題パターンは [reference/consistency-checks.md](reference/consistency-checks.md) を参照。
+各観点は **PASS / FAIL** で判定し、根拠（file:line引用）を必ず添える。各観点のチェックリスト・検出すべき問題パターンは [reference/consistency-checks.md](reference/consistency-checks.md) を参照。
 
-### 4. レポート作成
+### 5. レポート作成
 
 `docs/tasks/task{ID}-{SLUG}/TASK-REVIEW-REPORT.md` に以下を記入（詳細版テンプレートは [examples/review-report-template.md](examples/review-report-template.md) を参照）：
 
@@ -62,16 +73,21 @@ ls -d docs/tasks/task*
 # タスクレビュー結果: task{ID}-{SLUG}
 **実施日**: YYYY-MM-DD
 
-## 判定
-- 総合評価: [OK / Conditional OK / NG]
-- 実装開始可否: [可 / 要修正]
+## 前提整合性（doctor links）
+- docs/tasks 内リンク: [PASS/FAIL] – 根拠(file:line)
 
-## 詳細
-- 定義 ↔ 実装（変更内容）: [OK/Warn/Error] – コメント
-- 定義 ↔ 実装（ユーザーストーリー）: ...
-- リサーチ ↔ 実装: ...
-- 実装計画の完全性: ...
-- タスク全体の実現性: ...
+## 判定
+- 実装開始可否: [PASS / FAIL]
+
+## 詳細（観点別 PASS/FAIL）
+| # | 観点 | 判定 | 根拠（file:line） | コメント |
+|--:|:--|:--:|:--|:--|
+|1|定義 ↔ 実装（変更内容）| [PASS/FAIL] | ... | ... |
+|2|定義 ↔ 実装（ユーザーストーリー）| ... | ... | ... |
+|3|定義 ↔ 実装（受け入れ基準）| ... | ... | ... |
+|4|リサーチ ↔ 実装| ... | ... | ... |
+|5|実装計画の完全性| ... | ... | ... |
+|6|タスク全体の実現性| ... | ... | ... |
 
 ## 修正が必要な項目
 1. **カテゴリ**: ...
@@ -83,13 +99,13 @@ ls -d docs/tasks/task*
 - 推奨事項:
 ```
 
-### 5. 実装開始可否の判定とユーザー報告
+### 6. 実装開始可否の判定とユーザー報告
 
-- 総合評価（優/良/可/不可）と実装可否をレポートに明記する。
-- ユーザーに Error 件数・Warning 件数・総合評価を報告し、次のアクションを案内する。
+- 実装開始可否（PASS/FAIL）をレポートに明記する（全6観点PASSならPASS、1つでもFAILならFAILの単純AND判定）。
+- ユーザーに FAILした観点と根拠(file:line)を報告し、次のアクションを案内する。
 - 判定基準・修正ガイダンス・ベストプラクティスは [reference/assessment-criteria.md](reference/assessment-criteria.md) を参照。
 
-### 6. Git への追加（任意）
+### 7. Git への追加（任意）
 
 ```bash
 git add docs/tasks/task{ID}-{SLUG}/TASK-REVIEW-REPORT.md
@@ -98,13 +114,13 @@ git commit -m "docs(task): レビューレポート作成 task{ID}"
 
 ## 完了条件
 
-- 全観点に対して判定とコメントが記載されている。
+- 全観点に対して PASS/FAIL 判定と根拠（file:line引用）が記載されている。
 - 修正事項がカテゴリ別・優先度付きで整理されている。
-- 実装可否が明記され、関係者に共有済み。
+- 実装開始可否（PASS/FAIL）が明記され、関係者に共有済み。
 
 ## エスカレーション
 
-- **Error 多発**: 「致命的な不整合が複数あります。タスクドキュメント全体の再検討が必要です。」
+- **FAILした観点が複数（目安3件以上）**: 「致命的な不整合が複数あります。タスクドキュメント全体の再検討が必要です。」
 - **目的未達**: 「現在の実装計画では目的を達成できません。定義や計画を更新してください。」
 - **リスク未対策**: 「リサーチで検出されたリスクが計画に反映されていません。対策を追加してください。」
 - **テスト不足**: 「テスト計画が不十分です。ユニット/統合/E2Eを補完してください。」
@@ -112,6 +128,6 @@ git commit -m "docs(task): レビューレポート作成 task{ID}"
 
 ## 参考
 
-- [reference/consistency-checks.md](reference/consistency-checks.md) — 一貫性チェックの詳細項目
-- [reference/assessment-criteria.md](reference/assessment-criteria.md) — 評価基準・修正ガイダンス・ベストプラクティス・タスクライフサイクル
+- [reference/consistency-checks.md](reference/consistency-checks.md) — 一貫性チェックの詳細項目（6観点すべてdoctor非対応）
+- [reference/assessment-criteria.md](reference/assessment-criteria.md) — PASS/FAIL判定基準・修正ガイダンス・ベストプラクティス・タスクライフサイクル
 - [examples/review-report-template.md](examples/review-report-template.md) — 詳細レポートテンプレート

package/skills/b-005-review-task/examples/review-report-template.md

@@ -1,62 +1,52 @@
 # レビューレポート詳細テンプレート
 
-SKILL.md 手順4「レポート作成」で利用する詳細版テンプレート。簡易版は SKILL.md 本体にある。
+SKILL.md 手順5「レポート作成」で利用する詳細版テンプレート。簡易版は SKILL.md 本体にある。
 
 ## 詳細テンプレート
 
 ```markdown
 # タスクレビュー結果: task{ID}-{SLUG}
-**実施日**: YYYY-MM-DD
 
-## 判定
-- 総合評価: [OK / Conditional OK / NG]
-- 実装開始可否: [可 / 要修正]
+**実施日**: YYYY-MM-DD
 
-## 詳細チェック
-1. **定義 ↔ 実装**:
-   - 画面変更は全てステップに含まれています。
-   - **Error**: APIエンドポイント `POST /api/verify` の実装ステップが漏れています。
+## 前提整合性（doctor links）
 
-2. **リサーチ ↔ 実装**:
-   - **Warning**: リスクとして挙げられた「メール送信遅延」への対策が計画に見当たりません。
+| 項目 | 判定 | 根拠（file:line） |
+|:--|:--:|:--|
+| docs/tasks 内リンク | PASS | 該当ファイルへのリンク切れなし（`yodogawa doctor --json` の `links` finding に該当なし） |
 
-3. **計画の完全性**:
-   - ステップの粒度は適切です。
+## 判定
 
-## 推奨アクション
-1. `c-implementation.md` にAPI実装ステップを追加する。
-2. メール送信処理を非同期キューに入れる設計を計画に追加する。
+- 実装開始可否: FAIL
 
-## 実装計画の完全性
-- フェーズ分割妥当性: [評価]
-- ステップ粒度: [評価]
-- テスト計画包括性: [評価]
-- 検出された問題: X件
+## 詳細（観点別 PASS/FAIL）
 
-## タスク全体の実現可能性
-- 目的との整合性: [評価]
-- スコープの適切性: [評価]
-- 依存関係の明示: [評価]
-- 検出された問題: X件
+| # | 観点 | 判定 | 根拠（file:line） | コメント |
+|--:|:--|:--:|:--|:--|
+|1|定義 ↔ 実装（変更内容）| FAIL | `docs/tasks/task000003-auth-login/a-definition.md:22`: 「POST /api/verify」 | 対応する実装ステップが c-implementation.md に無い |
+|2|定義 ↔ 実装（ユーザーストーリー）| PASS | `docs/tasks/task000003-auth-login/c-implementation.md:10`: 「Step2: ログイン画面実装」 | 全USに対応ステップあり |
+|3|定義 ↔ 実装（受け入れ基準）| PASS | `docs/tasks/task000003-auth-login/a-definition.md:40`: 「- [ ] 3回失敗でロック」 | 対応ステップで実現される |
+|4|リサーチ ↔ 実装| FAIL | `docs/tasks/task000003-auth-login/b-research.md:18`: 「メール送信遅延リスク」 | 対策がc-implementation.mdに見当たらない |
+|5|実装計画の完全性| PASS | `docs/tasks/task000003-auth-login/c-implementation.md:5`: 「Phase1完了条件: ...」 | フェーズ完了条件明記 |
+|6|タスク全体の実現性| PASS | `docs/tasks/task000003-auth-login/a-definition.md:5`: 「目的: ログイン簡素化」 | 実装計画と整合 |
 
-## 次のアクション
+## 修正が必要な項目
 
-1. [最優先で修正すべき項目]
-2. [次に修正すべき項目]
-3. [余裕があれば修正する項目]
+1. **APIエンドポイント漏れ**: `POST /api/verify` の実装ステップを `c-implementation.md` に追加する。
+2. **リスク対策未反映**: メール送信を非同期キュー化する設計を計画に追加する。
 
-## レビュー所見
+## 所見
 
 ### 強み
-[このタスクドキュメントの優れている点]
+（このタスクドキュメントの優れている点）
 
 ### 改善点
-[改善すべき点、懸念事項]
+（改善すべき点、懸念事項）
 
 ### 推奨事項
-[実装開始前に対応すべき事項]
+（実装開始前に対応すべき事項）
 
 ## 備考
 
-[追加のコメント、質問事項など]
+（追加のコメント、質問事項など）
 ```

package/skills/b-005-review-task/reference/assessment-criteria.md

@@ -2,18 +2,18 @@
 
 SKILL.md 手順5「実装開始可否の判定」で参照する基準とアクション。
 
-## 総合評価の基準
+## 実装開始可否の基準
 
-- **優（実装開始OK）**: Error 0件、Warning 3件以下
-- **良（軽微な修正後に実装開始）**: Error 0件、Warning 4-10件
-- **可（修正後に実装開始）**: Error 1-3件、または Warning 11件以上
-- **不可（大幅な見直しが必要）**: Error 4件以上
+観点別 PASS/FAIL 表（6項目、SKILL.md手順4）から機械的に導出する（総合スコアや段階評価による恣意的な判断をしない）。
+
+- **PASS（実装開始可）**: 全6観点が PASS（各観点にError相当の指摘が0件）。Warning相当の注記が残っていても着手を妨げない。
+- **FAIL（要修正）**: 1観点以上が FAIL（Error相当の指摘が1件以上）。該当観点の指摘を解消してから再レビューする。
 
 ## 推奨アクション
 
-- 総合評価が「優」「良」の場合：「実装開始可能です。`/c-001-implement-task` を実行してください。」
-- 総合評価が「可」の場合：「Error を修正後、実装を開始してください。」
-- 総合評価が「不可」の場合：「タスクドキュメント全体の見直しが必要です。チームでレビュー会議を実施することを推奨します。」
+- 実装開始可否が「PASS」の場合：「実装開始可能です。`/c-001-implement-task` を実行してください。」
+- 実装開始可否が「FAIL」の場合：「以下のFAIL観点を修正後、再レビューしてください：」（FAILの観点と根拠(file:line)を列挙）
+- FAILした観点が複数（目安3件以上）の場合：「タスクドキュメント全体の見直しが必要です。チームでレビュー会議を実施することを推奨します。」
 
 ## 修正ガイダンス
 

package/skills/b-005-review-task/reference/consistency-checks.md

@@ -1,6 +1,6 @@
 # 一貫性チェックの詳細項目
 
-SKILL.md 手順3「一貫性チェック」で参照する詳細項目。
+SKILL.md 手順4「一貫性チェック」で参照する詳細項目。**6観点すべて doctor 非対応**（`structure`/`id-trace`/`placeholder` は `docs/project` 固定で `docs/tasks/` を検査対象にしない。唯一 `links` が `docs/` 全体を検査するが、相対リンク切れの検出に限られ意味的整合性は見ない）。すべて `a-definition.md` / `b-research.md` / `c-implementation.md` を Read して判断し、判定には file:line の引用を必須とする。番号は SKILL.md 手順4の観点表（1〜6）に対応する。
 
 ## チェック1: タスク定義 ↔ 実装計画（変更内容のカバレッジ）
 
@@ -54,16 +54,75 @@ SKILL.md 手順3「一貫性チェック」で参照する詳細項目。
 
 - ❌ **Error**: ユーザーストーリーに対応する実装ステップがない
 
-## チェック3: 実装計画の完全性
+## チェック3: タスク定義 ↔ 実装計画（受け入れ基準のカバレッジ）
 
-- フェーズ分割妥当性: [評価]
-- ステップ粒度: [評価]
-- テスト計画包括性: [評価]
-- 検出された問題: X件
+### 3.1. 受け入れ基準と実装ステップの対応
 
-## チェック4: タスク全体の実現可能性
+- タスク定義（a-definition.md）の受け入れ基準一覧を抽出
+- 各受け入れ基準を満たす実装ステップ（またはテスト計画）が c-implementation.md に存在するか確認
 
-- 目的との整合性: [評価]
-- スコープの適切性: [評価]
-- 依存関係の明示: [評価]
-- 検出された問題: X件
+**チェック項目**:
+
+- [ ] すべての受け入れ基準に対応する実装ステップ・テストが存在する
+- [ ] 受け入れ基準が「誰が読んでも同じ判定になる」具体性を持つ（例: 「正しく動作する」のような検証不能な表現でない）
+
+**検出すべき問題**:
+
+- ❌ **Error**: 受け入れ基準に対応する実装ステップ・テストが c-implementation.md に無い
+- ⚠️ **Warning**: 受け入れ基準の表現が曖昧で検証方法が定まらない
+
+## チェック4: リサーチ ↔ 実装計画
+
+### 4.1. 技術選定・リスク対策の反映
+
+- リサーチ（b-research.md）の技術選定が実装計画（c-implementation.md）のステップに反映されているか確認
+- リサーチで挙げたリスクへの対策が実装計画に含まれているか確認
+
+**チェック項目**:
+
+- [ ] 選定技術が実装計画のステップと矛盾しない
+- [ ] リサーチで指摘したリスクごとに、対応する対策・ステップが実装計画にある
+
+**検出すべき問題**:
+
+- ❌ **Error**: b-research.md の技術選定と c-implementation.md の記述が矛盾する
+- ⚠️ **Warning**: リサーチで挙げたリスクへの対策が実装計画に見当たらない
+
+## チェック5: 実装計画の完全性
+
+### 5.1. フェーズ・ステップ・テスト計画の妥当性
+
+- フェーズ分割: 各フェーズに目的・完了条件が明記され、後続フェーズが依存する成果物が先行フェーズで作られているか確認
+- ステップ粒度: 1ステップが数時間規模に収まる具体性か（オープンエンドな粗いステップが無いか）確認
+- テスト計画: 各受け入れ基準に対応するテスト（ユニット/統合/E2E）が計画されているか確認
+
+**チェック項目**:
+
+- [ ] 各フェーズに完了条件が明記されている
+- [ ] 後続フェーズが依存する成果物が先行フェーズのステップに含まれる
+- [ ] ステップ粒度が実装可能な単位に分割されている
+- [ ] 受け入れ基準を網羅するテスト計画がある
+
+**検出すべき問題**:
+
+- ❌ **Error**: フェーズの完了条件が無い、または後続フェーズが依存する成果物がどのフェーズにも存在しない
+- ⚠️ **Warning**: ステップ粒度が大きすぎる（分割検討）、テスト計画が受け入れ基準の一部を欠く
+
+## チェック6: タスク全体の実現可能性
+
+### 6.1. 目的・スコープ・依存関係の整合性
+
+- 目的との整合性: a-definition.md の目的と c-implementation.md の成果物が一致するか確認
+- スコープの適切性: 変更内容がタスクとして妥当な粒度か（分割すべき規模でないか）確認
+- 依存関係の明示: 他タスク・外部チーム・環境変数等への依存が明記されているか確認
+
+**チェック項目**:
+
+- [ ] a-definition.md の目的と実装計画の成果物が一致する
+- [ ] スコープが単一タスクとして妥当な粒度である
+- [ ] 他タスク・外部要因への依存が明記されている
+
+**検出すべき問題**:
+
+- ❌ **Error**: 目的と実装計画が矛盾する、または必須の依存関係が未記載
+- ⚠️ **Warning**: スコープが広すぎる（タスク分割を検討）

package/skills/d-001-review-retrospective/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: d-001-review-retrospective
+description: A〜Cシリーズ（または1タスク分のb/cサイクル）完了後、成果物ドキュメント（振り返り・ベストプラクティス・レビューレポート）から摩擦点を収集し、対象SKILL.mdへの修正案をdiff形式で提示、docs/LESSONS.mdに汎用的な学びを記録する。A〜Cシリーズ完了後の振り返りタイミングで使用。
+disable-model-invocation: true
+argument-hint: "[task-id ...]"
+context: fork
+allowed-tools: Read, Grep, Glob, Write, Bash
+---
+
+# ReviewRetrospective (d-001)
+
+## 目的
+
+- A〜Cシリーズ（または1タスク分のb/cサイクル）の実行経験から摩擦点（詰まった・脱線した・手戻りした箇所）を成果物ドキュメントから収集する。
+- 摩擦点をスキル・手順単位にマッピングし、対象 SKILL.md への具体的な修正案を diff 形式で提示する（適用はユーザー承認制。SKILL.md自体は編集しない）。
+- 汎用的な学びを `docs/LESSONS.md` に追記し、次のタスクのリサーチ（`b-003`）が参照できるようにする。
+
+## 前提
+
+- 対象タスクの成果物ドキュメント（`a-definition.md` / `b-research.md` / `c-implementation.md`）が `docs/tasks/task{ID}-{SLUG}/` に存在すること。特に `c-implementation.md` の `## 振り返り` セクションが記入済みであること。
+- `b-005-review-task` を実施済みなら `docs/tasks/task{ID}-{SLUG}/TASK-REVIEW-REPORT.md` も入力として使う（無ければスキップ）。
+- 修正案の永続化先: `docs/tasks/task{ID}-{SLUG}/RETROSPECTIVE-REPORT.md`
+- 汎用的な学びの蓄積先: `docs/LESSONS.md`（無ければこのスキルが `../../templates/LESSONS.md` から新規作成——スキル配置ディレクトリ起点の相対参照）
+- **注記**: `docs/LESSONS.md` は意図的に `docs/project/` の外に置く。`yodogawa doctor` の `id-trace`/`placeholder` は `docs/project/` 配下を無条件に走査し、`US-`/`FN-` 等のID風文字列を trace 切れとして誤検知しうるため（過去タスクで言及したIDが後日リナンバー・削除されると発生する）。
+
+## 手順
+
+`$ARGUMENTS` に1つ以上の `task{ID}-{SLUG}` があればそれを対象にする。未指定ならユーザーに対象範囲（直近のA〜Cシリーズ全体 or 特定タスク群）を確認する。
+
+### 1. 対象タスクの成果物収集
+
+対象タスクごとに:
+
+```bash
+ls -d docs/tasks/task*
+```
+
+- `c-implementation.md` の `## 振り返り` セクション（うまくいったこと／改善すべきこと／次のタスクへのフィードバック）を Read。
+- `b-research.md` の `## 実装時に発見したベストプラクティス` `## 技術的リスクの結果` を Read。
+- `TASK-REVIEW-REPORT.md` があれば `## 所見` の改善点・推奨事項を Read。
+
+未記入・未存在なら該当タスクをスキップし、理由を記録する。
+
+### 2. 摩擦点の抽出とスキル・手順へのマッピング
+
+収集した記述から摩擦点候補を洗い出し、原因となったスキル・手順を Read/Grep で特定する（例:「b-003の手順4で外部調査に時間がかかった」→ `skills/b-003-create-task-research/SKILL.md` の該当手順）。
+分類基準・マッピング方法の詳細は [reference/friction-point-mapping.md](reference/friction-point-mapping.md) を参照。
+
+### 3. 対象 SKILL.md への修正案の作成
+
+対象 SKILL.md を Read し、摩擦点を解消する具体的な修正案を diff 形式（`-`/`+` 行）で作成する。**SKILL.mdファイル自体は編集しない**（Writeツールはこの手順では使わない。適用要否はユーザーが判断する）。
+
+### 4. レポート作成
+
+`docs/tasks/task{ID}-{SLUG}/RETROSPECTIVE-REPORT.md` に摩擦点一覧・SKILL.md修正案（diff）を記入する（詳細版テンプレートは [examples/retrospective-report-template.md](examples/retrospective-report-template.md) を参照）。複数タスクを対象にした場合は1レポートに集約する。
+
+### 5. LESSONS.md への記録
+
+個別スキルへの修正提案にとどまらない汎用的な学び（複数スキルに共通するパターン、プロジェクト固有の注意点等）を抽出する。
+`docs/LESSONS.md` を Read し、同一 task-id の見出し（`### YYYY-MM-DD — task{ID}: ...`）が既に無いか Grep で確認する。既にあればスキップして重複を報告する。無ければ末尾に新規エントリを追記する（Write）。
+
+### 6. レポート出力
+
+チャットに以下を出力する:
+
+- 摩擦点一覧（タスクID・該当スキル・根拠file:line）
+- 対象SKILL.mdごとの修正案（diff形式。手順4で保存したレポートへのパスも明記）
+- LESSONS.mdへの追記内容のサマリ（スキップした場合はその旨）
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/RETROSPECTIVE-REPORT.md docs/LESSONS.md
+git commit -m "docs(retrospective): 振り返りレポート作成 task{ID}"
+```
+
+## 完了条件
+
+- 対象タスクの成果物ドキュメントを全て読み込んでいる（未記入タスクはスキップ理由を記録）。
+- 摩擦点ごとに file:line の根拠付きで SKILL.md 修正案（diff形式）が提示されている（チャット＋`RETROSPECTIVE-REPORT.md`）。
+- `docs/LESSONS.md` への追記が完了している（新規作成含む。重複時はスキップ）。
+- **SKILL.md自体は書き換えられていない**（提示のみ）。
+
+## エスカレーション
+
+- **成果物ドキュメントが不十分**: 「振り返りセクションが記入されていません。`c-002-update-documentation` で振り返りを記入してから再実行してください。」
+- **摩擦点が見つからない**: 「今回の対象タスクでは明確な摩擦点が見つかりませんでした。」と報告して終了する（無理に指摘を作らない）。
+- **修正案が複数スキルにまたがる／大規模**: 優先度（頻度・影響度）を付けて提示し、一度に大量の変更を提案しない。
+
+## 参考
+
+- [reference/friction-point-mapping.md](reference/friction-point-mapping.md) — 摩擦点の分類基準・スキル手順へのマッピング方法
+- [examples/retrospective-report-template.md](examples/retrospective-report-template.md) — RETROSPECTIVE-REPORT.md詳細テンプレート

package/skills/d-001-review-retrospective/examples/retrospective-report-template.md

@@ -0,0 +1,50 @@
+# 振り返りレポート詳細テンプレート
+
+SKILL.md 手順4「レポート作成」で利用する詳細版テンプレート。
+
+## 詳細テンプレート
+
+```markdown
+# 振り返りレポート: task{ID}-{SLUG}（複数タスク対象時は対象一覧を記載）
+
+**実施日**: YYYY-MM-DD
+**対象タスク**: task000003-auth-login, task000004-password-reset
+
+## 摩擦点一覧
+
+| # | 分類 | タスクID | 該当スキル | 根拠（file:line） | 優先度 |
+|--:|:--|:--|:--|:--|:--:|
+|1|手戻り|task000003-auth-login|`b-004-create-task-implementation`|`docs/tasks/task000003-auth-login/c-implementation.md:88`: 「テスト計画に異常系が無く後から追加した」|高|
+|2|詰まり|task000004-password-reset|`b-003-create-task-research`|`docs/tasks/task000004-password-reset/b-research.md:12`: 「外部APIのレート制限調査に時間がかかった」|中|
+
+## 対象SKILL.mdごとの修正案（diff形式）
+
+### `skills/b-004-create-task-implementation/SKILL.md`
+
+理由: 摩擦点#1（テスト計画に「正常系／異常系」の観点が明記されておらず、異常系テストの記載漏れが手戻りの原因になった。b-002の受け入れ基準策定（正常系/異常系/性能/セキュリティの観点を明記）と対称的な記述にする）
+
+\`\`\`diff
+ ### 4. テスト計画
+ 
+-フェーズ／ステップ単位で必要なテスト（ユニット、API、UI、E2E、負荷）とカバレッジ目標、検証コマンド（`npm test`, `playwright test` 等）を記載。例は [examples/phase-step-template.md](examples/phase-step-template.md#テスト計画の記載例) を参照。
++フェーズ／ステップ単位で必要なテスト（ユニット、API、UI、E2E、負荷）を**正常系／異常系**の観点で記載し、カバレッジ目標、検証コマンド（`npm test`, `playwright test` 等）を記載。例は [examples/phase-step-template.md](examples/phase-step-template.md#テスト計画の記載例) を参照。
+\`\`\`
+
+**適用要否はユーザー判断**（このレポートは提案のみ。SKILL.mdは編集していない）。
+
+## docs/LESSONS.md への追記内容
+
+- 追記した: `### YYYY-MM-DD — task000003-auth-login: テスト計画に異常系観点の明記が無く手戻りが発生`
+- スキップした（重複）: なし
+
+## 所見
+
+### 強み
+（今回のA〜Cサイクルで機能した点）
+
+### 改善点
+（今回検出できなかった摩擦点、次回のretrospectiveで補強すべき観点）
+
+### 推奨事項
+（優先度「高」の修正案から着手することを推奨、等）
+```

package/skills/d-001-review-retrospective/reference/friction-point-mapping.md

@@ -0,0 +1,30 @@
+# 摩擦点の分類基準・スキル手順へのマッピング方法
+
+SKILL.md 手順2「摩擦点の抽出とスキル・手順へのマッピング」で参照する詳細ガイド。
+
+## 摩擦点の分類
+
+収集した記述（`## 振り返り` / ベストプラクティス / レビューレポートの所見）から、以下のパターンに該当する記述を摩擦点候補として拾う。
+
+| 分類 | 典型的な記述例 | 想定される原因 |
+|------|----------------|----------------|
+| 詰まり | 「〜の判断基準が分からず手が止まった」「〜の手順の意図が不明瞭だった」 | 対象スキルの手順説明・判定基準の記述不足 |
+| 脱線 | 「〜を調査するはずが別の作業に時間を使った」「スコープ外の作業をしてしまった」 | 対象スキルの前提・スコープ境界の記述不足 |
+| 手戻り | 「後になって〜が抜けていることに気づき修正した」「〜のチェックが漏れていた」 | 対象スキルの完了条件・チェックリストの不足 |
+| 誤解 | 「〜だと思っていたが実際は違った」 | 対象スキルの用語・説明の曖昧さ |
+
+一般的な感想・個別タスク固有の詳細（例: 特定のライブラリのバージョン問題）は摩擦点として扱わない（スキル定義の改善につながらないため）。
+
+## スキル・手順へのマッピング
+
+1. 摩擦点の記述から、関連するフェーズ（A/B/C/D）とスキル名を推測する（例:「実装計画の粒度」→ `b-004-create-task-implementation`）。
+2. 該当する `skills/{code}/SKILL.md` を Read し、`## 手順` 内で摩擦点に対応する箇所を Grep（見出し番号・キーワード検索）で特定する。
+3. 特定できない場合（複数スキルにまたがる、または既存スキルのどこにも対応しない）は、レポートの「マッピング不能」欄に記録し、無理に1箇所へ押し込めない。
+
+## 修正案の優先度付け
+
+- **高**: 複数タスクで同じ摩擦点が繰り返し報告されている（`docs/LESSONS.md` の既存エントリと突き合わせて確認）。
+- **中**: 単一タスックだが Error 相当（作業がやり直しになった・成果物に不整合が生じた）。
+- **低**: 単一タスクの Warning 相当（読みにくかった・迷ったが自己解決できた）。
+
+優先度「高」「中」の摩擦点のみ SKILL.md 修正案として提示する。「低」は `docs/LESSONS.md` への記録にとどめ、SKILL.md 修正案は作らない（頻度の低い指摘でスキルを肥大化させない）。

package/templates/LESSONS.md

@@ -0,0 +1,15 @@
+# Lessons Learned
+
+<!--
+何のドキュメントか: A〜Cシリーズ運用で得られた汎用的な学び（複数タスク・複数スキルに共通するパターン）を蓄積する追記専用ログ。
+                    d-001（Review Retrospective）が振り返り実行のたびに末尾へ1エントリ追記する。b-003（Task Research）が次タスクの調査時に参照する。
+
+原則:
+  - 個別タスク固有の詳細は書かない（それは各タスクの c-implementation.md / RETROSPECTIVE-REPORT.md に残る）。ここは「次のタスクでも使える」学びだけを書く。
+  - 追記は末尾に時系列で積む。既存エントリは編集・削除しない（監査性を優先）。
+  - docs/project/ の外に置く（yodogawa doctor の id-trace/placeholder は docs/project/ 配下のみを検査するため、意図的に対象外にしている）。
+-->
+
+## 学びの記録
+
+<!-- d-001 が振り返りのたびに1エントリを追記する。見出しは `### YYYY-MM-DD — task{ID}: <一言タイトル>` 形式。 -->