yodogawa 2.1.1 → 2.2.0

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

@@ -2,37 +2,53 @@
 
 SKILL.md 手順2 で実施する各チェック項目の詳細。自動検索（grep 等）と手動確認を組み合わせる。
 
-## 2.1 ユーザーストーリー ↔ シナリオ
+## 2.1 ユーザーストーリー ↔ Core Scenario
 
-- **カバレッジ**: すべての US-XXX に対応する SC-XXX が存在するか。
-- **整合性**: ストーリーの「価値」とシナリオの「結果（Then）」が一致しているか。
+- **カバレッジ**: MVP Scope の Must 機能に対応する Core Scenario（Day 1 Happy Path）が存在するか。User Story は要約 AC、Core Scenario は実行時の主要行動という SSoT の住み分けを保つ（全 US を逐一シナリオ化しない）。
+- **整合性**: ストーリーの「価値」と Core Scenario の「結果（Then）」が一致しているか。
 
 ```bash
 # 全ユーザーストーリーの ID 抽出
 grep -oE "US-[0-9]+" docs/project/01-requirements/05-user-stories.md | sort -u
-# シナリオ側の参照
-grep -oE "US-[0-9]+" docs/project/02-behavior/01-scenarios.md | sort -u
+# Core Scenario 側の対応 Must / フロー参照
+grep -oE "FN-[0-9]+|CS-[0-9]+" docs/project/02-behavior/01-core-scenarios.md | sort -u
 ```
 
-## 2.2 実装済み機能・予定機能 ↔ シナリオ
+### ユーザーストーリーの役割 ↔ ペルソナ（trace）
 
-- **実装済み機能**: `02-features-implemented.md` の機能にリグレッション用シナリオが存在するか。
-- **予定機能**: `03-features-planned.md` の優先度 High 機能にシナリオが存在するか。
+- **役割が宙に浮かない**: `05-user-stories.md` の各ストーリーの「ペルソナ」列が、`01-product-brief.md` のペルソナ表で定義済みの ID（P-XXX）を参照しているか。**未定義のペルソナを参照する US はフラグ**する（役割の trace 切れ）。
+- **逆方向（任意）**: どの US からも参照されない主要ペルソナがあれば、スコープ漏れか過剰ペルソナのどちらかとして確認する。
 
-## 2.3 非機能要件 ↔ ドメインモデル
+```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)
+```
+
+## 2.2 MVP スコープ・実装済み機能 ↔ シナリオ
+
+- **MVP スコープ**: `02-mvp-scope.md` の Must 機能にシナリオが存在するか。
+- **実装済み機能**: `06-features-implemented.md`（existing モード）の機能にリグレッション用シナリオが存在するか。
+- **Parking Lot**: `03-parking-lot.md` は backlog のためシナリオ必須ではない（MVP 昇格時に MVP スコープ側で扱う）。
 
-- **パフォーマンス**: `04-non-functional-requirements.md` の要件（読み込み速度、スループット等）に対し、Read Model や CQRS が検討されているか。
-- **セキュリティ**: 認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
+## 2.3 クリティカル制約 ↔ スコープ/ドメイン
 
-## 2.4 シナリオ ↔ ドメインモデル
+初期フェーズでは定量 NFR ではなく、Product Brief の「クリティカル制約」を確認する（詳細な定量 NFR は設計フェーズ `/a-014-define-infrastructure` の責務）。
 
-- **Command**: シナリオの When（アクション）がドメインモデルの Command として定義されているか。
-- **Event**: シナリオの Then（結果）が Domain Event として定義されているか。
-- **Actor**: シナリオの Actor がドメインモデルに存在するか。
+- **制約の反映**: `01-product-brief.md` のクリティカル制約（法務・セキュリティ・期限・予算・外部 API 等）が `02-mvp-scope.md` の Must 判断やドメインモデルに反映されているか。
+- **セキュリティ・権限**: 制約に挙げた認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
+
+## 2.4 Core Scenario ↔ Domain Sketch
+
+- **アクター**: Core Scenario のアクターが Domain Sketch の「アクター / 外部システム」に存在するか。
+- **中核エンティティ**: Core Scenario が扱う対象が Domain Sketch の「中核エンティティ」に定義されているか。
+- **重要ルール**: Critical Failure を防ぐルールが「重要なビジネスルール」に反映されているか。
+- **Full DDD 採用時**: `01-domain-model.md` がある場合は、When→Command / Then→Event / Actor の対応も確認する。
 
 ## 2.5 ユビキタス言語の遵守
 
-- **用語定義**: ドメインモデルの主要要素（Aggregate, Command, Event）がユビキタス言語一覧にあるか。
+- **用語定義**: Domain Sketch の主要用語・中核エンティティ（Full DDD 採用時は Aggregate / Command / Event）がユビキタス言語一覧にあるか。
 - **禁止用語**: 各ドキュメントに禁止用語（Data, Process, Manager 等）が使われていないか。
 
 ```bash
@@ -44,8 +60,27 @@ grep -rn "Manager" docs/project/03-domain/ || echo "No 'Manager' found"
 
 ## 2.6 目的との整合性
 
-- システム概要（`01-system-overview.md`）の「目的」とドメインモデルの「Core Domain」が一致しているか。
-- ビジネス価値の提供元が Core に寄っているか（Generic に偏っていないか）。
+- Product Brief（`01-product-brief.md`）の「価値提案 / 差別化」が Domain Sketch の「中核エンティティ」「重要なビジネスルール」に反映されているか。
+- **価値提案の充足**: 「価値提案 / 差別化」のバリュープロポジション（1文）と差別化ポイント（Why us）が埋まり、Why us が「現在の代替手段・競合スキャン」表の各「弱み」と対応づいているか（漠然と「使いやすい」で済ませていないか）。
+- **目的 ↔ 成功指標**: Product Brief の成功指標（North Star / KPI / Guardrail）が「価値提案 / 解く課題」と整合しているか（目的と無関係な指標を測っていないか）。
+- **計測可能性**: 各成功指標に計測方法（どこで・どう取得）が記載され、計測可能か。今すぐ取れない指標が代理指標に置き換えられているか（MVP 段階は仮説値で可）。
+- Full DDD（`01-domain-model.md`）採用時は、ビジネス価値の提供元が Core Domain に寄っているか（Generic に偏っていないか）も確認する。
+
+## 2.7 MVP 正当化 / 過剰作り込み（YAGNI / PM Gate）
+
+「要らないものを作らない」を守るためのスコープ妥当性検査。
+
+- **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`）で実装対象として記述されていないか。
+- **安い代替手段**: 手作業・既存ツール・外部サービスで足りるものが Must になっていないか（`02-mvp-scope.md` の「より安い代替手段」列を確認）。
+- **仮説の数**: 検証する仮説が 1〜3 個に絞れているか（多すぎる＝MVP が過大）。
+
+> 成功指標と目的の整合（目的 ↔ 成功指標）・計測可能性は [2.6 目的との整合性](#26-目的との整合性)で検査する。
+
+```bash
+# Out of Scope（Won't）に挙げた機能名が他 doc に混入していないか（例）
+grep -rn "{Won't機能名}" docs/project/02-behavior/ docs/project/03-domain/
+```
 
 ## エスカレーションの判断材料
 

package/skills/a-007-define-tech-stack/SKILL.md

@@ -9,7 +9,7 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 ## 目的
 
-- 既存の要件ドキュメント（システム概要、非機能要件、ドメインモデル）を分析し、適合する技術スタックを推奨する。
+- 既存の要件ドキュメント（Product Brief（クリティカル制約含む）、ドメインモデル）を分析し、適合する技術スタックを推奨する。
 - 推奨案を提示した上で、ユーザーと詳細なインタビューを行い、すべての技術選定を明確化する。
 - 技術選定の理由、バージョン、選定タイミング（初期/中期/後期/随時）を明確に記録する。
 
@@ -27,18 +27,15 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ls -la docs/project/04-design/ 2>/dev/null || echo "ディレクトリが存在しません"
 ```
 
-要件ドキュメント（`01-system-overview.md`, `03-features-planned.md`, `04-non-functional-requirements.md`）とドメインモデル（`01-domain-model.md`）を読み込む。
+要件ドキュメント（`01-product-brief.md`（クリティカル制約含む）, `02-mvp-scope.md`）とドメイン（`01-domain-sketch.md`、Full DDD 採用時は `01-domain-model.md`）を読み込む。
 
 ### 2. テンプレートの準備
 
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/04-design/01-tech-stack.md" "docs/project/04-design/01-tech-stack.md"
-```
+このスキルの配置ディレクトリ（`skills/a-007-define-tech-stack/`）を起点に、相対パス `../../templates/project/04-design/01-tech-stack.md` を Read で読み込み、その内容を `docs/project/04-design/01-tech-stack.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
 
 ### 3. 要件分析と推奨技術スタックの生成
 
-- **システム特性の分析**: アプリケーションタイプ（SPA/SSR 等）、非機能要件、ドメイン複雑度
+- **システム特性の分析**: アプリケーションタイプ（SPA/SSR 等）、クリティカル制約（NFR の要点）、ドメイン複雑度
 - **レイヤー別推奨**: フロントエンド / バックエンド / データベース / インフラ・CI/CD / 監視・テスト
 - **提示形式**: 各技術に「推奨理由」と「代替案」を付ける
 

package/skills/a-008-define-repository-structure/SKILL.md

@@ -16,7 +16,7 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ## 前提
 
 - `docs/project/04-design/01-tech-stack.md` が作成されていること（`/a-007-define-tech-stack` 実行済み）。
-- `docs/project/03-domain/01-domain-model.md` が作成されていること（推奨）。
+- `docs/project/03-domain/01-domain-sketch.md` が作成されていること（推奨。Full DDD 採用時は `01-domain-model.md`）。
 - `docs/project/04-design/` ディレクトリが存在すること。
 
 ## 手順
@@ -31,10 +31,7 @@ ls -la docs/project/04-design/01-tech-stack.md 2>/dev/null || echo "ファイル
 
 ### 2. テンプレートの準備
 
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/04-design/02-repository-structure.md" "docs/project/04-design/02-repository-structure.md"
-```
+このスキルの配置ディレクトリ（`skills/a-008-define-repository-structure/`）を起点に、相対パス `../../templates/project/04-design/02-repository-structure.md` を Read で読み込み、その内容を `docs/project/04-design/02-repository-structure.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
 
 ### 3. アーキテクチャパターンの提案
 

package/skills/a-009-define-screen-design/SKILL.md

@@ -17,7 +17,7 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 ## 前提
 
 - `docs/project/01-requirements/05-user-stories.md` が作成されていること。
-- `docs/project/02-behavior/01-scenarios.md` が作成されていること。
+- `docs/project/02-behavior/01-core-scenarios.md` が作成されていること。
 - `docs/project/04-design/` ディレクトリが存在すること。
 
 ## 手順
@@ -27,17 +27,14 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 以下を読み込む:
 
 - `docs/project/01-requirements/05-user-stories.md`
-- `docs/project/02-behavior/01-scenarios.md`
+- `docs/project/02-behavior/01-core-scenarios.md`
 - `docs/project/04-design/01-tech-stack.md`（存在する場合）
 
 不足があれば対応スキル（`/a-002`, `/a-003`, `/a-007`）の実行を促す。
 
 ### 2. テンプレートの準備
 
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/04-design/03-screen-design.md" "docs/project/04-design/03-screen-design.md"
-```
+このスキルの配置ディレクトリ（`skills/a-009-define-screen-design/`）を起点に、相対パス `../../templates/project/04-design/03-screen-design.md` を Read で読み込み、その内容を `docs/project/04-design/03-screen-design.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
 
 ### 3. 画面の抽出と提案
 

package/skills/a-010-define-design-system/SKILL.md

@@ -28,11 +28,7 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 ### 2. テンプレートの準備
 
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/04-design/04-design-system.md" \
-   "docs/project/04-design/04-design-system.md"
-```
+このスキルの配置ディレクトリ（`skills/a-010-define-design-system/`）を起点に、相対パス `../../templates/project/04-design/04-design-system.md` を Read で読み込み、その内容を `docs/project/04-design/04-design-system.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
 
 ### 3. カラーパレットの定義
 

package/skills/a-011-define-data-model/SKILL.md

@@ -9,14 +9,14 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 ## 目的
 
-- ドメインモデル（Aggregates）と画面設計を基に、データベース構造を定義する。
+- ドメイン（Domain Sketch の中核エンティティ、Full DDD 採用時は Aggregates）と画面設計を基に、データベース構造を定義する。
 - エンティティ（テーブル）、属性（カラム）、リレーションシップを明確化する。
 - データ型、制約（NOT NULL、UNIQUE、CHECK）、インデックス戦略を決定する。
 - Mermaid ERD（Entity Relationship Diagram）で視覚化し、開発者間の認識を統一する。
 
 ## 前提
 
-- `docs/project/03-domain/01-domain-model.md` が作成されていること。
+- `docs/project/03-domain/01-domain-sketch.md` が作成されていること（Full DDD 採用時は `01-domain-model.md`）。
 - `docs/project/04-design/01-tech-stack.md` が作成されていること（DB 選定済み）。
 - `docs/project/04-design/03-screen-design.md` が作成されていること。
 - `docs/project/04-design/` ディレクトリが存在すること。
@@ -27,7 +27,7 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 以下を読み込む:
 
-- `docs/project/03-domain/01-domain-model.md`
+- `docs/project/03-domain/01-domain-sketch.md`（Full DDD 採用時は `01-domain-model.md`）
 - `docs/project/04-design/01-tech-stack.md`
 - `docs/project/04-design/03-screen-design.md`
 
@@ -35,10 +35,7 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 ### 2. テンプレートの準備
 
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/04-design/05-data-model.md" "docs/project/04-design/05-data-model.md"
-```
+このスキルの配置ディレクトリ（`skills/a-011-define-data-model/`）を起点に、相対パス `../../templates/project/04-design/05-data-model.md` を Read で読み込み、その内容を `docs/project/04-design/05-data-model.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
 
 ### 3. エンティティの抽出と提案
 

package/skills/a-012-define-api-spec/SKILL.md

@@ -36,10 +36,7 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 ### 2. テンプレートの準備
 
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/04-design/06-api-spec.md" "docs/project/04-design/06-api-spec.md"
-```
+このスキルの配置ディレクトリ（`skills/a-012-define-api-spec/`）を起点に、相対パス `../../templates/project/04-design/06-api-spec.md` を Read で読み込み、その内容を `docs/project/04-design/06-api-spec.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
 
 ### 3. API スタイルの確認と提案
 

package/skills/a-013-define-architecture/SKILL.md

@@ -31,10 +31,7 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 ### 2. テンプレートの準備
 
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/04-design/07-architecture.md" "docs/project/04-design/07-architecture.md"
-```
+このスキルの配置ディレクトリ（`skills/a-013-define-architecture/`）を起点に、相対パス `../../templates/project/04-design/07-architecture.md` を Read で読み込み、その内容を `docs/project/04-design/07-architecture.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/04-design/`）が無ければ作成する。
 
 ### 3. アーキテクチャの提案
 

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

@@ -13,11 +13,13 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 - クラウドリソース、ネットワーク、セキュリティ、監視を含む全体構成を可視化する。
 - 環境ごとの構成（開発、ステージング、本番）を明確化する。
 - 高可用性、冗長化、スケーラビリティ、セキュリティの方針を定義する。
+- 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/` ディレクトリが存在すること。
 
 ## 手順
@@ -33,10 +35,7 @@ allowed-tools: Read, Write, Edit, Bash, Grep, Glob
 
 ### 2. テンプレートの準備
 
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/04-design/08-infrastructure.md" "docs/project/04-design/08-infrastructure.md"
-```
+このスキルの配置ディレクトリ（`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. インフラ構成の提案
 
@@ -65,6 +64,10 @@ Multi-AZ 構成、リードレプリカ、バックアップ（頻度、保持
 
 開発/ステージング/本番環境の差異（リソースサイズ、冗長化、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` に以下を記入する:
@@ -110,4 +113,6 @@ git commit -m "docs: インフラ設計の定義"
 ## 参考
 
 - [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/reference/consistency-checks.md

@@ -15,7 +15,7 @@ grep -oE "PostgreSQL|Redis|NestJS|Next.js" docs/project/04-design/07-architectur
 
 ## 2.2 データモデル ↔ ドメインモデル
 
-- **カバレッジ**: ドメインモデルの Aggregate（`01-domain-model.md`）がデータモデル（`05-data-model.md`）のエンティティとして定義されているか。
+- **カバレッジ**: ドメインの中核エンティティ（`01-domain-sketch.md`、Full DDD 採用時は `01-domain-model.md` の Aggregate）がデータモデル（`05-data-model.md`）のエンティティとして定義されているか。
 - **用語統一**: テーブル名・カラム名がユビキタス言語と一致しているか。
 
 ## 2.3 API 仕様 ↔ データモデル

package/skills/b-001-create-task-directory/SKILL.md

@@ -28,18 +28,25 @@ allowed-tools: Read, Write, Bash, Glob
 
 命名規則の詳細は [examples/naming-convention.md](examples/naming-convention.md) を参照。
 
-### 2. スクリプトの実行
+### 2. タスク ID の採番とディレクトリ作成
 
-決定したスラッグを引数にして `create-task.sh` を呼び出す。スクリプトが既存タスク走査・ID 採番・形式チェック・ディレクトリ作成までを自動実行する。
+決定したスラッグについて、次を順に行う。
+
+1. **形式チェック**: スラッグが正規表現 `^[a-z0-9]+(-[a-z0-9]+)*$`（英小文字・数字・ハイフンのみ、連続ハイフン禁止）に一致するか確認。3〜5 語を推奨（範囲外は警告のみで続行）。違反時はエスカレーション参照。
+2. **ID の採番**: `docs/tasks/` 配下の `task{6桁数字}-*` ディレクトリから最大 ID を求め、+1 を 6 桁ゼロ詰めした `task{ID}`（例: `task000003`）とする。タスクが無ければ `task000001`。
+3. **ディレクトリ作成**: `docs/tasks/task{ID}-{SLUG}` を作成する。
 
 ```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-bash "$SCRIPT_DIR/scripts/create-task.sh" "<SLUG>"
+# 既存タスクを確認して最大 ID を把握
+ls -d docs/tasks/task* 2>/dev/null
+
+# 採番した ID とスラッグでディレクトリを作成（{ID}/{SLUG} は実値に置換）
+mkdir -p "docs/tasks/task{ID}-{SLUG}"
 ```
 
 ### 3. 結果の確認
 
-スクリプトの終了コードが 0 であることと、出力された作成パス（`docs/tasks/task{ID}-{SLUG}`）を確認。
+作成パス（`docs/tasks/task{ID}-{SLUG}`）が生成されたことを確認。
 
 ### 4. 次のステップの案内
 
@@ -53,9 +60,8 @@ bash "$SCRIPT_DIR/scripts/create-task.sh" "<SLUG>"
 
 ## エスカレーション
 
-- **`docs/tasks/` が見つからない**: スクリプトがエラー終了するので、`/a-001-setup-doc-structure` の実行を促す
-- **スラッグ形式違反**: スクリプトがエラー終了するので、英小文字・数字・ハイフンのみで再入力を求める
-- **スクリプトが見つからない**: `.claude/` または `.agents/` 配下に `scripts/create-task.sh` がない場合、`yodogawa` CLI での再インストールを促す
+- **`docs/tasks/` が見つからない**: ディレクトリが無い場合は `/a-001-setup-doc-structure` の実行を促す
+- **スラッグ形式違反**: 英小文字・数字・ハイフンのみ（連続ハイフン禁止）で再入力を求める
 
 ## 参考