yodogawa 2.1.3 → 2.3.0

package/skills/a-014-define-infrastructure/SKILL.md

@@ -1,110 +1,118 @@
----
-name: a-014-define-infrastructure
-description: アーキテクチャ設計を基にインフラ構成図・環境構成・運用方針を定義する。アーキテクチャ確定後、デプロイ/運用環境を設計する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineInfrastructure (a-014)
-
-## 目的
-
-- 技術スタックとアーキテクチャ設計を基に、インフラ構成を定義する。
-- クラウドリソース、ネットワーク、セキュリティ、監視を含む全体構成を可視化する。
-- 環境ごとの構成（開発、ステージング、本番）を明確化する。
-- 高可用性、冗長化、スケーラビリティ、セキュリティの方針を定義する。
-
-## 前提
-
-- `docs/project/04-design/01-tech-stack.md` が作成されていること（デプロイ環境、インフラ技術選定済み）。
-- `docs/project/04-design/07-architecture.md` が作成されていること（推奨）。
-- `docs/project/04-design/` ディレクトリが存在すること。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-以下を読み込む:
-
-- `docs/project/04-design/01-tech-stack.md`
-- `docs/project/04-design/07-architecture.md`
-
-不足があれば対応スキルの実行を促す。
-
-### 2. テンプレートの準備
-
-このスキルの配置ディレクトリ（`skills/a-014-define-infrastructure/`）を起点に、相対パス `../../templates/project/04-design/08-infrastructure.md` を Read で読み込み、その内容を `docs/project/04-design/08-infrastructure.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
-
-### 3. インフラ構成の提案
-
-技術スタックとアーキテクチャ図から必要なリソース（VPC, ALB, ECS/EC2, RDS 等）を抽出し、構成案を提示する。
-
-- 「[Cloud Provider] 上に VPC + Public/Private Subnet 構成」
-- 「DB は Managed Service（RDS 等）」
-
-構成図のサンプルは [examples/infrastructure-templates.md](examples/infrastructure-templates.md#インフラ構成図mermaid) を参照。
-
-### 4. 詳細定義（インタビュー）
-
-#### 4.1 ネットワークとセキュリティ
-
-VPC 構成、サブネット分割（Public/Private/Data）、セキュリティグループ、WAF、HTTPS 化。詳細は [examples/infrastructure-templates.md](examples/infrastructure-templates.md#ネットワークセキュリティ) を参照。
-
-#### 4.2 コンピューティングとスケーリング
-
-インスタンス種別・サイズ、Auto Scaling ポリシー（CPU 負荷等）、デプロイ戦略。
-
-#### 4.3 データベースとストレージ
-
-Multi-AZ 構成、リードレプリカ、バックアップ（頻度、保持期間）、PITR の有無。
-
-#### 4.4 環境構成
-
-開発/ステージング/本番環境の差異（リソースサイズ、冗長化、WAF など）。表形式のテンプレートは [examples/infrastructure-templates.md](examples/infrastructure-templates.md#環境構成表) を参照。
-
-### 5. ドキュメント作成
-
-`docs/project/04-design/08-infrastructure.md` に以下を記入する:
-
-- インフラ構成図（Mermaid）
-- 環境構成表
-- 運用方針（バックアップ、監視、セキュリティ）
-
-運用方針の項目一覧は [examples/infrastructure-templates.md](examples/infrastructure-templates.md#運用方針の定義項目) を、非機能要件との対応表は [reference/structure-check.md](reference/structure-check.md#非機能要件との対応確認) を参照。
-
-### 6. 構造チェック
-
-```bash
-grep "\`\`\`mermaid" docs/project/04-design/08-infrastructure.md \
-  && grep "## 環境構成" docs/project/04-design/08-infrastructure.md \
-  && grep "## 主要な運用方針" docs/project/04-design/08-infrastructure.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 7. Git への追加（任意）
-
-```bash
-git add docs/project/04-design/08-infrastructure.md
-git commit -m "docs: インフラ設計の定義"
-```
-
-## 完了条件
-
-- `docs/project/04-design/08-infrastructure.md` が作成されている。
-- インフラの物理構成とネットワーク構成が可視化されている。
-- 環境ごとの差異が明確になっている。
-- 運用上の重要事項（バックアップ、セキュリティ）が定義されている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- **コストが高すぎる**: 「冗長化構成によりコストが増加します。ステージング環境は Single-AZ にするなど、コスト最適化を検討しましょう。」
-- **セキュリティリスク**: 「DB がパブリックサブネットに配置されています。プライベートサブネットへの移動を強く推奨します。」
-- 詳細応答例は [reference/structure-check.md](reference/structure-check.md#エスカレーション時の推奨応答) を参照。
-
-## 参考
-
-- [examples/infrastructure-templates.md](examples/infrastructure-templates.md) — インフラ構成図、環境構成表、運用方針の定義項目
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、非機能要件対応、レビュー質問
+---
+name: a-014-define-infrastructure
+description: アーキテクチャ設計を基にインフラ構成図・環境構成・運用方針を定義する。アーキテクチャ確定後、デプロイ/運用環境を設計する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineInfrastructure (a-014)
+
+## 目的
+
+- 技術スタックとアーキテクチャ設計を基に、インフラ構成を定義する。
+- クラウドリソース、ネットワーク、セキュリティ、監視を含む全体構成を可視化する。
+- 環境ごとの構成（開発、ステージング、本番）を明確化する。
+- 高可用性、冗長化、スケーラビリティ、セキュリティの方針を定義する。
+- Product Brief の「クリティカル制約」を起点に、初期フェーズで保留した**詳細な非機能要件（応答時間・稼働率・スケーラビリティ・RPO/RTO 等の定量値）を本フェーズで定量化・所有する**。
+
+## 前提
+
+- `docs/project/04-design/01-tech-stack.md` が作成されていること（デプロイ環境、インフラ技術選定済み）。
+- `docs/project/04-design/07-architecture.md` が作成されていること（推奨）。
+- `docs/project/01-requirements/01-product-brief.md` の「クリティカル制約」（詳細 NFR 定量化の起点）。
+- `docs/project/04-design/` ディレクトリが存在すること。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+以下を読み込む:
+
+- `docs/project/04-design/01-tech-stack.md`
+- `docs/project/04-design/07-architecture.md`
+
+不足があれば対応スキルの実行を促す。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-014-define-infrastructure/`）を起点に、相対パス `../../templates/project/04-design/08-infrastructure.md` を Read で読み込み、その内容を `docs/project/04-design/08-infrastructure.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
+
+### 3. インフラ構成の提案
+
+技術スタックとアーキテクチャ図から必要なリソース（VPC, ALB, ECS/EC2, RDS 等）を抽出し、構成案を提示する。
+
+- 「[Cloud Provider] 上に VPC + Public/Private Subnet 構成」
+- 「DB は Managed Service（RDS 等）」
+
+構成図のサンプルは [examples/infrastructure-templates.md](examples/infrastructure-templates.md#インフラ構成図mermaid) を参照。
+
+### 4. 詳細定義（インタビュー）
+
+#### 4.1 ネットワークとセキュリティ
+
+VPC 構成、サブネット分割（Public/Private/Data）、セキュリティグループ、WAF、HTTPS 化。詳細は [examples/infrastructure-templates.md](examples/infrastructure-templates.md#ネットワークセキュリティ) を参照。
+
+#### 4.2 コンピューティングとスケーリング
+
+インスタンス種別・サイズ、Auto Scaling ポリシー（CPU 負荷等）、デプロイ戦略。
+
+#### 4.3 データベースとストレージ
+
+Multi-AZ 構成、リードレプリカ、バックアップ（頻度、保持期間）、PITR の有無。
+
+#### 4.4 環境構成
+
+開発/ステージング/本番環境の差異（リソースサイズ、冗長化、WAF など）。表形式のテンプレートは [examples/infrastructure-templates.md](examples/infrastructure-templates.md#環境構成表) を参照。
+
+#### 4.5 詳細な非機能要件（定量化）
+
+Product Brief の「クリティカル制約」を起点に、性能（応答時間・スループット）・可用性（稼働率・RPO/RTO）・スケーラビリティ・セキュリティ等を定量化する。初期フェーズでは保留していた定量値をここで確定する。テンプレートは [examples/non-functional-requirements.md](examples/non-functional-requirements.md)、特に指定が無い場合の標準提案値は [examples/nfr-baseline.md](examples/nfr-baseline.md) を参照。
+
+### 5. ドキュメント作成
+
+`docs/project/04-design/08-infrastructure.md` に以下を記入する:
+
+- インフラ構成図（Mermaid）
+- 環境構成表
+- 運用方針（バックアップ、監視、セキュリティ）
+
+運用方針の項目一覧は [examples/infrastructure-templates.md](examples/infrastructure-templates.md#運用方針の定義項目) を、非機能要件との対応表は [reference/structure-check.md](reference/structure-check.md#非機能要件との対応確認) を参照。
+
+### 6. 構造チェック
+
+```bash
+grep "\`\`\`mermaid" docs/project/04-design/08-infrastructure.md \
+  && grep "## 環境構成" docs/project/04-design/08-infrastructure.md \
+  && grep "## 主要な運用方針" docs/project/04-design/08-infrastructure.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/project/04-design/08-infrastructure.md
+git commit -m "docs: インフラ設計の定義"
+```
+
+## 完了条件
+
+- `docs/project/04-design/08-infrastructure.md` が作成されている。
+- インフラの物理構成とネットワーク構成が可視化されている。
+- 環境ごとの差異が明確になっている。
+- 運用上の重要事項（バックアップ、セキュリティ）が定義されている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **コストが高すぎる**: 「冗長化構成によりコストが増加します。ステージング環境は Single-AZ にするなど、コスト最適化を検討しましょう。」
+- **セキュリティリスク**: 「DB がパブリックサブネットに配置されています。プライベートサブネットへの移動を強く推奨します。」
+- 詳細応答例は [reference/structure-check.md](reference/structure-check.md#エスカレーション時の推奨応答) を参照。
+
+## 参考
+
+- [examples/infrastructure-templates.md](examples/infrastructure-templates.md) — インフラ構成図、環境構成表、運用方針の定義項目
+- [examples/non-functional-requirements.md](examples/non-functional-requirements.md) — 詳細な非機能要件テンプレート（設計フェーズで定量化）
+- [examples/nfr-baseline.md](examples/nfr-baseline.md) — 非機能要件の標準ベースライン提案値
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、非機能要件対応、レビュー質問

package/skills/{a-002-initialize-project → a-014-define-infrastructure}/examples/nfr-baseline.md

@@ -1,6 +1,7 @@
 # 非機能要件の標準ベースライン
 
-SKILL.md 手順6で「標準的な設定で仮置き」する際の提案値。
+a-014（インフラ設計）で詳細な非機能要件を定量化する際、特に指定が無い場合の出発点となる標準提案値。
+Product Brief の「クリティカル制約」で確定済みの制約はそちらを優先する。
 
 ## Web アプリケーションの一般的な目標値
 

package/{templates/project/01-requirements/04-non-functional-requirements.md → skills/a-014-define-infrastructure/examples/non-functional-requirements.md}

@@ -1,115 +1,120 @@
-# 非機能要件一覧
-
-<!--
-何を書くか: システムが「どう動くべきか」を定義する品質要件
-
-目的:
-  - システムの性能基準、セキュリティレベル、信頼性を明確化
-  - アーキテクチャ設計の指針を提供
-  - テスト計画の基準値を設定
-  - ステークホルダーとのSLA（サービスレベル合意）の根拠
-
-特徴:
-  - 機能要件（何ができるか）に対し、非機能要件は「どれくらい良く動くか」を規定
-  - 測定可能で検証可能な基準を設定
-  - プロジェクト初期に定義し、開発全体を通じて継続的に検証
-
-記載のポイント:
-  - 具体的な数値目標を含める（「高速」ではなく「200ms以内」）
-  - 現実的で達成可能な基準を設定
-  - ビジネス要件と技術的実現可能性のバランスを取る
-
-更新頻度:
-  - プロジェクト初期に定義、要件変更時に見直し
-  - システム規模拡大時に再評価（ユーザー数増加など）
-  - 定期的な監視結果に基づいて調整
--->
-
-<!--
-テーブル構成:
-
-【カテゴリ】
-主要なカテゴリと内容:
-
-  性能（Performance）
-    - 応答時間: ユーザー操作からレスポンスまでの時間
-    - スループット: 単位時間あたりの処理件数
-    - リソース使用率: CPU、メモリ、ディスク、ネットワーク
-    - 同時接続数: 同時にアクセス可能なユーザー数
-
-  セキュリティ（Security）
-    - 認証・認可: ログイン方式、アクセス制御
-    - 暗号化: 通信・データの暗号化方式
-    - 監査: ログ記録、アクセス履歴
-    - 脆弱性対策: OWASP Top 10対応など
-    - データ保護: GDPR、個人情報保護法などのコンプライアンス
-
-  可用性（Availability）
-    - 稼働率: システムが利用可能な時間の割合（例: 99.9%）
-    - MTBF: 平均故障間隔
-    - MTTR: 平均復旧時間
-    - バックアップ: バックアップ頻度と保持期間
-    - 障害対応: 検知から復旧までの目標時間
-
-  スケーラビリティ（Scalability）
-    - ユーザー数: 対応可能な最大ユーザー数
-    - データ量: 保存可能なデータの上限
-    - 拡張性: 水平/垂直スケーリングの方式
-    - エラスティシティ: 負荷に応じた自動スケーリング
-
-  ユーザビリティ（Usability）
-    - アクセシビリティ: WCAG準拠レベル
-    - 学習容易性: 新規ユーザーが操作を習得する時間
-    - 多言語対応: サポートする言語
-    - モバイル対応: レスポンシブデザイン、PWA
-
-  保守性（Maintainability）
-    - コード品質: テストカバレッジ、静的解析基準
-    - デプロイ頻度: リリースサイクル
-    - ロールバック時間: 問題発生時の巻き戻し時間
-
-  互換性（Compatibility）
-    - ブラウザ対応: サポートするブラウザとバージョン
-    - デバイス対応: PC、タブレット、スマートフォン
-    - API互換性: 後方互換性の保証期間
-
-【要件】
-  - カテゴリ内の具体的な要件項目名
-  - 簡潔で明確な名称（2-5単語程度）
-  - 例: 「応答時間」「認証方式」「稼働率」
-
-【説明】
-  - 要件の具体的な基準値や条件を記述
-  - 測定可能な数値を含める（必須）
-  - 測定条件や前提条件も必要に応じて記載
-  - 例: 「API応答は95パーセンタイルで200ms以内（通常負荷時）」
-
-ベストプラクティス:
-  - 「速い」「安全」など曖昧な表現を避け、具体的な数値や基準を使う
-  - テスト可能な要件にする（どう検証するか明確にする）
-  - 優先度の高い要件から記載（すべてを満たす必要はない場合もある）
-  - ビジネス影響を考慮した現実的な基準を設定（過度に厳しい基準は開発コストを増大させる）
-  - 競合他社や業界標準を参考にする
-  - システムの成長に応じて要件を見直す（初期は緩く、成熟に伴い厳格化も可）
--->
-
-| カテゴリ | 要件 | 説明 |
-|----------|------|------|
-| <!-- カテゴリ名 --> | <!-- 要件名 --> | <!-- 要件の詳細 --> |
-
----
-
-**例:**
-
-| カテゴリ | 要件 | 説明 |
-|----------|------|------|
-| 性能 | 応答時間 | API応答は200ms以内 |
-| 性能 | 処理能力 | 同時接続1000ユーザーまで対応 |
-| セキュリティ | 認証 | OAuth 2.0 + JWT認証 |
-| セキュリティ | 暗号化 | TLS 1.3による通信暗号化 |
-| セキュリティ | 監査 | 全API呼び出しのログ記録 |
-| 可用性 | 稼働率 | 99.9%の稼働率を維持 |
-| 可用性 | 障害対応 | 検知から復旧まで4時間以内 |
-| スケーラビリティ | ユーザー数 | 10万ユーザーまで対応可能 |
-| スケーラビリティ | データ量 | 1TBまでのデータ保存 |
-| ユーザビリティ | アクセシビリティ | WCAG 2.1 AA準拠 |
+# 非機能要件一覧
+
+<!--
+何を書くか: システムが「どう動くべきか」を定義する品質要件
+
+位置づけ:
+  - これは設計フェーズ（/a-014-define-infrastructure）で必要時に展開する詳細 NFR テンプレート。
+  - 初期フェーズ（要件定義）では詳細 NFR を定量化しない。MVP の作り方を変えるほど重要な制約のみを
+    Product Brief の「クリティカル制約」に記載する。本テンプレートはその制約を起点に詳細化する。
+
+目的:
+  - システムの性能基準、セキュリティレベル、信頼性を明確化
+  - アーキテクチャ設計・インフラ設計の指針を提供
+  - テスト計画の基準値を設定
+  - ステークホルダーとのSLA（サービスレベル合意）の根拠
+
+特徴:
+  - 機能要件（何ができるか）に対し、非機能要件は「どれくらい良く動くか」を規定
+  - 測定可能で検証可能な基準を設定
+  - 設計フェーズで定義し、開発全体を通じて継続的に検証
+
+記載のポイント:
+  - 具体的な数値目標を含める（「高速」ではなく「200ms以内」）
+  - 現実的で達成可能な基準を設定
+  - ビジネス要件と技術的実現可能性のバランスを取る
+
+更新頻度:
+  - 設計フェーズで定義、要件変更時に見直し
+  - システム規模拡大時に再評価（ユーザー数増加など）
+  - 定期的な監視結果に基づいて調整
+-->
+
+<!--
+テーブル構成:
+
+【カテゴリ】
+主要なカテゴリと内容:
+
+  性能（Performance）
+    - 応答時間: ユーザー操作からレスポンスまでの時間
+    - スループット: 単位時間あたりの処理件数
+    - リソース使用率: CPU、メモリ、ディスク、ネットワーク
+    - 同時接続数: 同時にアクセス可能なユーザー数
+
+  セキュリティ（Security）
+    - 認証・認可: ログイン方式、アクセス制御
+    - 暗号化: 通信・データの暗号化方式
+    - 監査: ログ記録、アクセス履歴
+    - 脆弱性対策: OWASP Top 10対応など
+    - データ保護: GDPR、個人情報保護法などのコンプライアンス
+
+  可用性（Availability）
+    - 稼働率: システムが利用可能な時間の割合（例: 99.9%）
+    - MTBF: 平均故障間隔
+    - MTTR: 平均復旧時間
+    - バックアップ: バックアップ頻度と保持期間
+    - 障害対応: 検知から復旧までの目標時間
+
+  スケーラビリティ（Scalability）
+    - ユーザー数: 対応可能な最大ユーザー数
+    - データ量: 保存可能なデータの上限
+    - 拡張性: 水平/垂直スケーリングの方式
+    - エラスティシティ: 負荷に応じた自動スケーリング
+
+  ユーザビリティ（Usability）
+    - アクセシビリティ: WCAG準拠レベル
+    - 学習容易性: 新規ユーザーが操作を習得する時間
+    - 多言語対応: サポートする言語
+    - モバイル対応: レスポンシブデザイン、PWA
+
+  保守性（Maintainability）
+    - コード品質: テストカバレッジ、静的解析基準
+    - デプロイ頻度: リリースサイクル
+    - ロールバック時間: 問題発生時の巻き戻し時間
+
+  互換性（Compatibility）
+    - ブラウザ対応: サポートするブラウザとバージョン
+    - デバイス対応: PC、タブレット、スマートフォン
+    - API互換性: 後方互換性の保証期間
+
+【要件】
+  - カテゴリ内の具体的な要件項目名
+  - 簡潔で明確な名称（2-5単語程度）
+  - 例: 「応答時間」「認証方式」「稼働率」
+
+【説明】
+  - 要件の具体的な基準値や条件を記述
+  - 測定可能な数値を含める（必須）
+  - 測定条件や前提条件も必要に応じて記載
+  - 例: 「API応答は95パーセンタイルで200ms以内（通常負荷時）」
+
+ベストプラクティス:
+  - 「速い」「安全」など曖昧な表現を避け、具体的な数値や基準を使う
+  - テスト可能な要件にする（どう検証するか明確にする）
+  - 優先度の高い要件から記載（すべてを満たす必要はない場合もある）
+  - ビジネス影響を考慮した現実的な基準を設定（過度に厳しい基準は開発コストを増大させる）
+  - 競合他社や業界標準を参考にする
+  - システムの成長に応じて要件を見直す（初期は緩く、成熟に伴い厳格化も可）
+-->
+
+| カテゴリ | 要件 | 説明 |
+|----------|------|------|
+| <!-- カテゴリ名 --> | <!-- 要件名 --> | <!-- 要件の詳細 --> |
+
+---
+
+**例:**
+
+| カテゴリ | 要件 | 説明 |
+|----------|------|------|
+| 性能 | 応答時間 | API応答は200ms以内 |
+| 性能 | 処理能力 | 同時接続1000ユーザーまで対応 |
+| セキュリティ | 認証 | OAuth 2.0 + JWT認証 |
+| セキュリティ | 暗号化 | TLS 1.3による通信暗号化 |
+| セキュリティ | 監査 | 全API呼び出しのログ記録 |
+| 可用性 | 稼働率 | 99.9%の稼働率を維持 |
+| 可用性 | 障害対応 | 検知から復旧まで4時間以内 |
+| スケーラビリティ | ユーザー数 | 10万ユーザーまで対応可能 |
+| スケーラビリティ | データ量 | 1TBまでのデータ保存 |
+| ユーザビリティ | アクセシビリティ | WCAG 2.1 AA準拠 |

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)参照）。
 
 ## コミットメッセージ例