yodogawa 2.1.3 → 2.3.0

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

@@ -1,128 +1,130 @@
----
-name: b-003-create-task-research
-description: タスク実装前に既存コード・ベストプラクティス・再利用候補・リスクを調査し b-research.md に記録する。タスク定義確定後、実装計画作成前に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
-argument-hint: "[task-id]"
----
-
-# CreateTaskResearch (b-003)
-
-## 目的
-
-- 実装に着手する前に、最適なアプローチ・技術・注意点を整理する。
-- 既存コードやコンポーネントを把握し、重複実装や手戻りを防止する。
-- 技術選定・リスク・参考資料を記録し、実装計画 (b-004) の入力とする。
-
-## 前提
-
-- `CreateTaskDefinition (b-002)` が完了し、`a-definition.md` に目的・変更内容が記載されている。
-- タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
-- テンプレート: `../../templates/tasks/task-template/b-research.md`（スキル配置ディレクトリ起点の相対参照）
-
-## 手順
-
-`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
-
-### 1. ドキュメントとテンプレートの準備
-
-対象タスクディレクトリを確認する。
-
-```bash
-ls -d docs/tasks/task*
-```
-
-このスキルの配置ディレクトリ（`skills/b-003-create-task-research/`）を起点に、相対パス `../../templates/tasks/task-template/b-research.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/b-research.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
-
-### 2. 調査計画の立案
-
-- `a-definition.md` を読み、変更対象・技術要件・制約を抽出。
-- 調査する観点を整理：例）類似実装、利用ライブラリ、外部API仕様、セキュリティ要件。
-- 調査メモを残しながら進めると、ドキュメント作成がスムーズ。
-
-### 3. 既存実装と再利用候補の調査
-
-- コードベースを検索し、類似ロジックやコンポーネントを洗い出す。
-- 再利用できるファイル・モジュール・カスタムフック・APIクライアントをリスト化。
-- 参考にできる実装パターン（バリデーション、エラーハンドリング等）と課題点を併記。
-- 詳細な調査観点・分析項目は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
-
-### 4. ベストプラクティス・外部情報の調査
-
-- 公式ドキュメント、信頼できる記事、社内ナレッジを確認し、採用すべきパターン/アンチパターンを整理。
-- 調査内容（タイトル、要点、URL）を記録。例）フォームバリデーション、非同期通信、セキュリティガイドライン。
-
-### 5. 技術選定と比較（必要時）
-
-- 新規導入・置き換え候補のライブラリ/サービスを比較。
-- 比較観点: メンテ状況、TypeScript対応、バンドルサイズ、コスト、既存スタックとの親和性。
-- 選定理由と却下理由を記録。チーム合意が必要な場合はその旨も記載。
-- 詳細な比較観点は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
-
-### 6. 技術的リスクと対策
-
-- パフォーマンス、セキュリティ、スケーラビリティ、依存サービス等のリスクを洗い出す。
-- 影響度と優先度（高/中/低）を付与し、軽減策やPoCの必要有無を記載。
-- リスクカテゴリ一覧とセキュリティチェック項目は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
-
-### 7. ドキュメントへの反映
-
-1. `docs/tasks/task{ID}-{SLUG}/b-research.md` を編集し、以下を記入：
-   - ベストプラクティス / 参考リンク
-   - 既存コード・再利用コンポーネント
-   - 技術選定（比較表含む）
-   - 技術的リスク・制約
-   - メモ / 次に確認すべき事項
-2. HTMLコメントはガイドとして残す。
-3. 各セクションの表テンプレートは [examples/research-tables.md](examples/research-tables.md) を参照。
-
-### 8. 構造チェック
-
-```bash
-grep "## ベストプラクティス" docs/tasks/task{ID}-{SLUG}/b-research.md \
- && grep "## 既存コード調査" docs/tasks/task{ID}-{SLUG}/b-research.md \
- && grep "## 技術選定" docs/tasks/task{ID}-{SLUG}/b-research.md \
- && grep "## 技術的リスク" docs/tasks/task{ID}-{SLUG}/b-research.md \
- && echo "OK" || echo "MISSING SECTION"
-```
-
-チェックリスト:
-
-- [ ] 参考リンク・出典が記載されている
-- [ ] 再利用できるコード/コンポーネントが明確
-- [ ] 技術選定理由と代替案が整理されている
-- [ ] リスクに軽減策と優先度が付与されている
-
-### 9. Git への追加（任意）
-
-```bash
-git add docs/tasks/task{ID}-{SLUG}/b-research.md
-git commit -m "docs(task): 技術調査メモの作成 task{ID}"
-```
-
-## 完了条件
-
-- `b-research.md` に以下が網羅されている：
-  - ベストプラクティス／参考資料
-  - 既存コード・再利用コンポーネント
-  - 技術選定と比較（必要に応じて）
-  - 技術的リスクと対策
-  - 追加のメモ／未解決事項
-- 実装計画 (b-004) に渡せるレベルで情報が整理されている。
-- 関係者が内容を確認し、疑問があれば解消済み。
-
-## エスカレーション
-
-- **既存コードが見つからない**: 「コードベースを検索しても見つからない場合、他メンバーに確認し、再利用可否を判断してください。」
-- **ライブラリ選定で決め手がない**: 「評価軸を追加（保守実績、サポート、コストなど）し、比較表を拡張してください。」
-- **リスクが高い**: 「影響が重大なリスクは PoC や専門チーム相談を提案し、スケジュールに反映してください。」
-- **外部サービス依存がある**: 「SLA・レート制限・コストを確認し、代替案やフォールバックを検討してください。」
-- **ドキュメントが不足**: 「ベストプラクティスや参考資料の記載が不十分です。公式ドキュメントや社内ナレッジを追加してください。」
-- **セキュリティリスクが見落とされている**: 「入力バリデーション／XSS/CSRF/SQLi／認証・認可／暗号化／レート制限の観点で再調査してください。」
-- **パフォーマンスリスクが見落とされている**: 「大量データや高負荷時の動作を検討してください。」
-- **新ライブラリ導入がチーム未合意**: 「チームリーダーやメンバーとレビュー・合意を取ってください。」
-
-## 参考
-
-- [reference/investigation-guide.md](reference/investigation-guide.md) — 調査観点・分析項目・リスクカテゴリの詳細
-- [examples/research-tables.md](examples/research-tables.md) — 各セクションの表テンプレート例
+---
+name: b-003-create-task-research
+description: タスク実装前に既存コード・ベストプラクティス・再利用候補・リスクを調査し b-research.md に記録する。タスク定義確定後、実装計画作成前に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+argument-hint: "[task-id]"
+---
+
+# CreateTaskResearch (b-003)
+
+## 目的
+
+- 実装に着手する前に、最適なアプローチ・技術・注意点を整理する。
+- 既存コードやコンポーネントを把握し、重複実装や手戻りを防止する。
+- 技術選定・リスク・参考資料を記録し、実装計画 (b-004) の入力とする。
+
+## 前提
+
+- `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` が過去タスクの振り返りから蓄積する汎用的な学び。無ければスキップ）。
+
+## 手順
+
+`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
+
+### 1. ドキュメントとテンプレートの準備
+
+対象タスクディレクトリを確認する。
+
+```bash
+ls -d docs/tasks/task*
+```
+
+このスキルの配置ディレクトリ（`skills/b-003-create-task-research/`）を起点に、相対パス `../../templates/tasks/task-template/b-research.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/b-research.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
+
+### 2. 調査計画の立案
+
+- `a-definition.md` を読み、変更対象・技術要件・制約を抽出。
+- 調査する観点を整理：例）類似実装、利用ライブラリ、外部API仕様、セキュリティ要件。
+- 調査メモを残しながら進めると、ドキュメント作成がスムーズ。
+
+### 3. 既存実装と再利用候補の調査
+
+- コードベースを検索し、類似ロジックやコンポーネントを洗い出す。
+- 再利用できるファイル・モジュール・カスタムフック・APIクライアントをリスト化。
+- 参考にできる実装パターン（バリデーション、エラーハンドリング等）と課題点を併記。
+- 詳細な調査観点・分析項目は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
+
+### 4. ベストプラクティス・外部情報の調査
+
+- `docs/LESSONS.md` が存在すれば読み、過去タスクの摩擦点・ベストプラクティスを踏まえる（無ければスキップ）。
+- 公式ドキュメント、信頼できる記事、社内ナレッジを確認し、採用すべきパターン/アンチパターンを整理。
+- 調査内容（タイトル、要点、URL）を記録。例）フォームバリデーション、非同期通信、セキュリティガイドライン。
+
+### 5. 技術選定と比較（必要時）
+
+- 新規導入・置き換え候補のライブラリ/サービスを比較。
+- 比較観点: メンテ状況、TypeScript対応、バンドルサイズ、コスト、既存スタックとの親和性。
+- 選定理由と却下理由を記録。チーム合意が必要な場合はその旨も記載。
+- 詳細な比較観点は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
+
+### 6. 技術的リスクと対策
+
+- パフォーマンス、セキュリティ、スケーラビリティ、依存サービス等のリスクを洗い出す。
+- 影響度と優先度（高/中/低）を付与し、軽減策やPoCの必要有無を記載。
+- リスクカテゴリ一覧とセキュリティチェック項目は [reference/investigation-guide.md](reference/investigation-guide.md) を参照。
+
+### 7. ドキュメントへの反映
+
+1. `docs/tasks/task{ID}-{SLUG}/b-research.md` を編集し、以下を記入：
+   - ベストプラクティス / 参考リンク
+   - 既存コード・再利用コンポーネント
+   - 技術選定（比較表含む）
+   - 技術的リスク・制約
+   - メモ / 次に確認すべき事項
+2. HTMLコメントはガイドとして残す。
+3. 各セクションの表テンプレートは [examples/research-tables.md](examples/research-tables.md) を参照。
+
+### 8. 構造チェック
+
+```bash
+grep "## ベストプラクティス" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && grep "## 既存コード調査" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && grep "## 技術選定" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && grep "## 技術的リスク" docs/tasks/task{ID}-{SLUG}/b-research.md \
+ && echo "OK" || echo "MISSING SECTION"
+```
+
+チェックリスト:
+
+- [ ] 参考リンク・出典が記載されている
+- [ ] 再利用できるコード/コンポーネントが明確
+- [ ] 技術選定理由と代替案が整理されている
+- [ ] リスクに軽減策と優先度が付与されている
+
+### 9. Git への追加（任意）
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/b-research.md
+git commit -m "docs(task): 技術調査メモの作成 task{ID}"
+```
+
+## 完了条件
+
+- `b-research.md` に以下が網羅されている：
+  - ベストプラクティス／参考資料
+  - 既存コード・再利用コンポーネント
+  - 技術選定と比較（必要に応じて）
+  - 技術的リスクと対策
+  - 追加のメモ／未解決事項
+- 実装計画 (b-004) に渡せるレベルで情報が整理されている。
+- 関係者が内容を確認し、疑問があれば解消済み。
+
+## エスカレーション
+
+- **既存コードが見つからない**: 「コードベースを検索しても見つからない場合、他メンバーに確認し、再利用可否を判断してください。」
+- **ライブラリ選定で決め手がない**: 「評価軸を追加（保守実績、サポート、コストなど）し、比較表を拡張してください。」
+- **リスクが高い**: 「影響が重大なリスクは PoC や専門チーム相談を提案し、スケジュールに反映してください。」
+- **外部サービス依存がある**: 「SLA・レート制限・コストを確認し、代替案やフォールバックを検討してください。」
+- **ドキュメントが不足**: 「ベストプラクティスや参考資料の記載が不十分です。公式ドキュメントや社内ナレッジを追加してください。」
+- **セキュリティリスクが見落とされている**: 「入力バリデーション／XSS/CSRF/SQLi／認証・認可／暗号化／レート制限の観点で再調査してください。」
+- **パフォーマンスリスクが見落とされている**: 「大量データや高負荷時の動作を検討してください。」
+- **新ライブラリ導入がチーム未合意**: 「チームリーダーやメンバーとレビュー・合意を取ってください。」
+
+## 参考
+
+- [reference/investigation-guide.md](reference/investigation-guide.md) — 調査観点・分析項目・リスクカテゴリの詳細
+- [examples/research-tables.md](examples/research-tables.md) — 各セクションの表テンプレート例

package/skills/b-004-create-task-implementation/SKILL.md

@@ -1,98 +1,98 @@
----
-name: b-004-create-task-implementation
-description: タスクをステップ単位に分割し、各ステップの成果物・受け入れ基準を c-implementation.md に定義する。リサーチ完了後、実装着手前に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
-argument-hint: "[task-id]"
----
-
-# CreateTaskImplementation (b-004)
-
-## 目的
-
-- タスクを実行可能なフェーズとステップに分割し、作業順序と依存関係を明確にする。
-- 各ステップの成果物と受け入れ基準を定義し、作業完了の判断基準を共有する。
-- 実装開始前にテスト計画や懸念点を洗い出し、品質リスクを低減する。
-
-## 前提
-
-- `a-definition.md`（b-002）と `b-research.md`（b-003）が作成済み
-- タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
-- テンプレート: `../../templates/tasks/task-template/c-implementation.md`（スキル配置ディレクトリ起点の相対参照）
-
-## 手順
-
-`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
-
-### 1. ドキュメント確認とテンプレート準備
-
-対象タスクディレクトリを確認する。
-
-```bash
-ls -d docs/tasks/task*
-```
-
-このスキルの配置ディレクトリ（`skills/b-004-create-task-implementation/`）を起点に、相対パス `../../templates/tasks/task-template/c-implementation.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/c-implementation.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
-
-`a-definition.md` から目的・変更内容・受け入れ基準を、`b-research.md` から技術方針・ライブラリ選定・リスクを読み取る。
-
-### 2. フェーズ設計
-
-タスクを 2〜4 フェーズに分割（1 フェーズ = 1〜3 日規模）。分割の考え方と例は [examples/phase-step-template.md](examples/phase-step-template.md#フェーズ分割の目安) を参照。
-
-### 3. ステップ分解
-
-各フェーズを 1〜3 時間で完了できるステップに分割し、Title / Details / Deliverables / Verification を定義。記載例は [examples/phase-step-template.md](examples/phase-step-template.md#ステップ分解のテンプレート) を参照。
-
-### 4. テスト計画
-
-フェーズ／ステップ単位で必要なテスト（ユニット、API、UI、E2E、負荷）とカバレッジ目標、検証コマンド（`npm test`, `playwright test` 等）を記載。例は [examples/phase-step-template.md](examples/phase-step-template.md#テスト計画の記載例) を参照。
-
-### 5. ドキュメント反映
-
-`docs/tasks/task{ID}-{SLUG}/c-implementation.md` に以下を記入:
-
-1. フェーズ一覧（目的、完了条件、依存関係）
-2. フェーズ内ステップ（Title/Details/Deliverables/Verification）
-3. テスト計画
-4. メモ・補足（懸念点、要確認事項、リファクタ案）
-
-HTML コメントは削除せずガイドとして残す。
-
-### 6. 構造チェック
-
-```bash
-grep "## 実装フェーズ" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
-  && grep "## ステップ一覧" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
-  && grep "## テスト計画" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 7. Git への追加（任意）
-
-```bash
-git add docs/tasks/task{ID}-{SLUG}/c-implementation.md
-git commit -m "docs(task): 実装計画の作成 task{ID}"
-```
-
-## 完了条件
-
-- `c-implementation.md` にフェーズ／ステップ／テスト／メモが記載されている
-- ステップの粒度が適切（1〜3 時間）で、成果物が明確
-- フェーズ順序と依存関係が示されている
-- 関係者レビューで疑問がない状態
-
-## エスカレーション
-
-- **フェーズが大きすぎる**: 「1 フェーズが 3 日以上になりそうです。分割してください。」
-- **ステップが抽象的**: 「成果物が特定できません。ファイル名や検証手順を明記してください。」
-- **テスト計画不足**: 「対象機能のテスト戦略が不足しています。ユニット/統合/E2E を再検討してください。」
-- **リスク対策未反映**: 「b-003 で挙げたリスクへの対策ステップがありません。計画に組み込んでください。」
-- **依存関係不明**: 「並行実行可能なフェーズと、順序が必要なフェーズを明示してください。」
-
-## 参考
-
-- [examples/phase-step-template.md](examples/phase-step-template.md) — フェーズ分割、ステップ分解、テスト計画の記載例
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点
+---
+name: b-004-create-task-implementation
+description: タスクをステップ単位に分割し、各ステップの成果物・受け入れ基準を c-implementation.md に定義する。リサーチ完了後、実装着手前に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+argument-hint: "[task-id]"
+---
+
+# CreateTaskImplementation (b-004)
+
+## 目的
+
+- タスクを実行可能なフェーズとステップに分割し、作業順序と依存関係を明確にする。
+- 各ステップの成果物と受け入れ基準を定義し、作業完了の判断基準を共有する。
+- 実装開始前にテスト計画や懸念点を洗い出し、品質リスクを低減する。
+
+## 前提
+
+- `a-definition.md`（b-002）と `b-research.md`（b-003）が作成済み
+- タスクディレクトリ: `docs/tasks/task{ID}-{SLUG}/`
+- テンプレート: `../../templates/tasks/task-template/c-implementation.md`（スキル配置ディレクトリ起点の相対参照）
+
+## 手順
+
+`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
+
+### 1. ドキュメント確認とテンプレート準備
+
+対象タスクディレクトリを確認する。
+
+```bash
+ls -d docs/tasks/task*
+```
+
+このスキルの配置ディレクトリ（`skills/b-004-create-task-implementation/`）を起点に、相対パス `../../templates/tasks/task-template/c-implementation.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/c-implementation.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
+
+`a-definition.md` から目的・変更内容・受け入れ基準を、`b-research.md` から技術方針・ライブラリ選定・リスクを読み取る。
+
+### 2. フェーズ設計
+
+タスクを 2〜4 フェーズに分割（1 フェーズ = 1〜3 日規模）。分割の考え方と例は [examples/phase-step-template.md](examples/phase-step-template.md#フェーズ分割の目安) を参照。
+
+### 3. ステップ分解
+
+各フェーズを 1〜3 時間で完了できるステップに分割し、Title / Details / Deliverables / Verification を定義。記載例は [examples/phase-step-template.md](examples/phase-step-template.md#ステップ分解のテンプレート) を参照。
+
+### 4. テスト計画
+
+フェーズ／ステップ単位で必要なテスト（ユニット、API、UI、E2E、負荷）とカバレッジ目標、検証コマンド（`npm test`, `playwright test` 等）を記載。例は [examples/phase-step-template.md](examples/phase-step-template.md#テスト計画の記載例) を参照。
+
+### 5. ドキュメント反映
+
+`docs/tasks/task{ID}-{SLUG}/c-implementation.md` に以下を記入:
+
+1. フェーズ一覧（目的、完了条件、依存関係）
+2. フェーズ内ステップ（Title/Details/Deliverables/Verification）
+3. テスト計画
+4. メモ・補足（懸念点、要確認事項、リファクタ案）
+
+HTML コメントは削除せずガイドとして残す。
+
+### 6. 構造チェック
+
+```bash
+grep "## 実装フェーズ" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
+  && grep "## ステップ一覧" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
+  && grep "## テスト計画" docs/tasks/task{ID}-{SLUG}/c-implementation.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/c-implementation.md
+git commit -m "docs(task): 実装計画の作成 task{ID}"
+```
+
+## 完了条件
+
+- `c-implementation.md` にフェーズ／ステップ／テスト／メモが記載されている
+- ステップの粒度が適切（1〜3 時間）で、成果物が明確
+- フェーズ順序と依存関係が示されている
+- 関係者レビューで疑問がない状態
+
+## エスカレーション
+
+- **フェーズが大きすぎる**: 「1 フェーズが 3 日以上になりそうです。分割してください。」
+- **ステップが抽象的**: 「成果物が特定できません。ファイル名や検証手順を明記してください。」
+- **テスト計画不足**: 「対象機能のテスト戦略が不足しています。ユニット/統合/E2E を再検討してください。」
+- **リスク対策未反映**: 「b-003 で挙げたリスクへの対策ステップがありません。計画に組み込んでください。」
+- **依存関係不明**: 「並行実行可能なフェーズと、順序が必要なフェーズを明示してください。」
+
+## 参考
+
+- [examples/phase-step-template.md](examples/phase-step-template.md) — フェーズ分割、ステップ分解、テスト計画の記載例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点

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) — 詳細レポートテンプレート