yodogawa 2.1.3 → 2.3.0

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

@@ -1,79 +1,79 @@
-# 評価基準・修正ガイダンス
-
-SKILL.md 手順5「実装開始可否の判定」で参照する基準とアクション。
-
-## 総合評価の基準
-
-- **優（実装開始OK）**: Error 0件、Warning 3件以下
-- **良（軽微な修正後に実装開始）**: Error 0件、Warning 4-10件
-- **可（修正後に実装開始）**: Error 1-3件、または Warning 11件以上
-- **不可（大幅な見直しが必要）**: Error 4件以上
-
-## 推奨アクション
-
-- 総合評価が「優」「良」の場合：「実装開始可能です。`/c-001-implement-task` を実行してください。」
-- 総合評価が「可」の場合：「Error を修正後、実装を開始してください。」
-- 総合評価が「不可」の場合：「タスクドキュメント全体の見直しが必要です。チームでレビュー会議を実施することを推奨します。」
-
-## 修正ガイダンス
-
-検出された問題について、修正方法を提案：
-
-- Errorが検出された場合：「以下の問題を優先的に修正してください：」
-- 修正すべきドキュメントとスキルを案内：
-  - 例：「ユーザーストーリーUS-002に対応する実装ステップがありません → `/b-004-create-task-implementation` で実装計画を更新」
-  - 例：「受け入れ基準が一致していません → `/b-002-create-task-definition` でタスク定義を見直し」
-
-ユーザーに確認：「今すぐ修正作業を開始しますか？それとも後で個別に修正しますか？」
-
-## ベストプラクティス
-
-- **実装開始前に必ず実行**: c-001 実行前に b-005 でレビューし、問題を早期発見
-- **段階的レビュー**: b-001完了後、b-002完了後、b-003完了後の各段階で部分レビューを実施
-- **チームレビュー**: 重要なタスクや大規模なタスクはチーム全体でレビュー会議を実施
-- **継続的更新**: 実装中に新しい発見があれば、ドキュメントを更新し、再レビュー
-- **メトリクス記録**: レビュー結果（Error数、Warning数）を記録し、タスク品質を追跡
-- **フィードバックループ**: レビュー結果を基にテンプレートや次のタスクを改善
-
-## 参考: レビュー対象ドキュメント構造
-
-**a-definition.md（タスク定義）**:
-
-- 目的（解決する問題、提供する価値）
-- ユーザーストーリー一覧
-- 変更内容一覧（画面、データモデル、API、その他）
-- 受け入れ基準
-
-**b-research.md（リサーチ）**:
-
-- ベストプラクティス
-- 既存コードの調査
-- 再利用可能なコンポーネント
-- 技術選定
-- 技術的リスクと制約
-
-**c-implementation.md（実装計画）**:
-
-- フェーズ（目的、完了条件）
-- ステップ（成果物、詳細）
-- 受け入れ基準
-
-## 参考: タスクライフサイクルにおける位置づけ
-
-```
-b-001: タスクディレクトリ作成
-  ↓
-b-002: タスク定義作成
-  ↓
-b-003: リサーチ実施
-  ↓
-b-004: 実装計画作成
-  ↓
-b-005: タスクレビュー ← このスキル
-  ↓
-c-001: 実装実行
-  ↓
-c-002: ドキュメント更新
-```
-
-b-005 は実装開始前の「最後の砦」として、タスクの品質と実現可能性を保証する重要な役割を果たします。
+# 評価基準・修正ガイダンス
+
+SKILL.md 手順5「実装開始可否の判定」で参照する基準とアクション。
+
+## 実装開始可否の基準
+
+観点別 PASS/FAIL 表（6項目、SKILL.md手順4）から機械的に導出する（総合スコアや段階評価による恣意的な判断をしない）。
+
+- **PASS（実装開始可）**: 全6観点が PASS（各観点にError相当の指摘が0件）。Warning相当の注記が残っていても着手を妨げない。
+- **FAIL（要修正）**: 1観点以上が FAIL（Error相当の指摘が1件以上）。該当観点の指摘を解消してから再レビューする。
+
+## 推奨アクション
+
+- 実装開始可否が「PASS」の場合：「実装開始可能です。`/c-001-implement-task` を実行してください。」
+- 実装開始可否が「FAIL」の場合：「以下のFAIL観点を修正後、再レビューしてください：」（FAILの観点と根拠(file:line)を列挙）
+- FAILした観点が複数（目安3件以上）の場合：「タスクドキュメント全体の見直しが必要です。チームでレビュー会議を実施することを推奨します。」
+
+## 修正ガイダンス
+
+検出された問題について、修正方法を提案：
+
+- Errorが検出された場合：「以下の問題を優先的に修正してください：」
+- 修正すべきドキュメントとスキルを案内：
+  - 例：「ユーザーストーリーUS-002に対応する実装ステップがありません → `/b-004-create-task-implementation` で実装計画を更新」
+  - 例：「受け入れ基準が一致していません → `/b-002-create-task-definition` でタスク定義を見直し」
+
+ユーザーに確認：「今すぐ修正作業を開始しますか？それとも後で個別に修正しますか？」
+
+## ベストプラクティス
+
+- **実装開始前に必ず実行**: c-001 実行前に b-005 でレビューし、問題を早期発見
+- **段階的レビュー**: b-001完了後、b-002完了後、b-003完了後の各段階で部分レビューを実施
+- **チームレビュー**: 重要なタスクや大規模なタスクはチーム全体でレビュー会議を実施
+- **継続的更新**: 実装中に新しい発見があれば、ドキュメントを更新し、再レビュー
+- **メトリクス記録**: レビュー結果（Error数、Warning数）を記録し、タスク品質を追跡
+- **フィードバックループ**: レビュー結果を基にテンプレートや次のタスクを改善
+
+## 参考: レビュー対象ドキュメント構造
+
+**a-definition.md（タスク定義）**:
+
+- 目的（解決する問題、提供する価値）
+- ユーザーストーリー一覧
+- 変更内容一覧（画面、データモデル、API、その他）
+- 受け入れ基準
+
+**b-research.md（リサーチ）**:
+
+- ベストプラクティス
+- 既存コードの調査
+- 再利用可能なコンポーネント
+- 技術選定
+- 技術的リスクと制約
+
+**c-implementation.md（実装計画）**:
+
+- フェーズ（目的、完了条件）
+- ステップ（成果物、詳細）
+- 受け入れ基準
+
+## 参考: タスクライフサイクルにおける位置づけ
+
+```
+b-001: タスクディレクトリ作成
+  ↓
+b-002: タスク定義作成
+  ↓
+b-003: リサーチ実施
+  ↓
+b-004: 実装計画作成
+  ↓
+b-005: タスクレビュー ← このスキル
+  ↓
+c-001: 実装実行
+  ↓
+c-002: ドキュメント更新
+```
+
+b-005 は実装開始前の「最後の砦」として、タスクの品質と実現可能性を保証する重要な役割を果たします。

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**: スコープが広すぎる（タスク分割を検討）