yodogawa 2.1.3 → 2.2.0

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

@@ -1,68 +1,68 @@
----
-name: b-001-create-task-directory
-description: docs/tasks/ 配下に連番タスク ID 付きディレクトリを作成する。新しい実装タスクに着手する最初の手順として使用。
-disable-model-invocation: true
-argument-hint: "[slug]"
-allowed-tools: Read, Write, Bash, Glob
----
-
-# CreateTaskDirectory (b-001)
-
-## 目的
-
-- 新しいタスク専用のディレクトリを作成する（ID は自動採番）。
-- タスク ID の採番ルール（`taskXXXXXX`）を統一し、管理しやすくする。
-- **注意**: このスキルはディレクトリ作成のみ。タスク定義書などのドキュメント作成は後続のスキル（`/b-002-create-task-definition` など）で実施。
-
-## 前提
-
-- `docs/tasks/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure` を先に実行）
-
-## 手順
-
-### 1. スラッグの決定
-
-`$ARGUMENTS` が指定されている場合はそれをスラッグとして使用する。未指定の場合のみユーザーに質問:
-
-- 「タスクの内容を 3〜5 語の英数字とハイフンで表現してください（例: `user-profile-edit`）。」
-
-命名規則の詳細は [examples/naming-convention.md](examples/naming-convention.md) を参照。
-
-### 2. タスク 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
-# 既存タスクを確認して最大 ID を把握
-ls -d docs/tasks/task* 2>/dev/null
-
-# 採番した ID とスラッグでディレクトリを作成（{ID}/{SLUG} は実値に置換）
-mkdir -p "docs/tasks/task{ID}-{SLUG}"
-```
-
-### 3. 結果の確認
-
-作成パス（`docs/tasks/task{ID}-{SLUG}`）が生成されたことを確認。
-
-### 4. 次のステップの案内
-
-- 「タスクディレクトリ `docs/tasks/task{ID}-{SLUG}` を作成しました。」
-- 「続いてタスク定義書を作成しますか？（`/b-002-create-task-definition`）」
-
-## 完了条件
-
-- `docs/tasks/task{ID}-{SLUG}/` ディレクトリが作成されている
-- ユーザーに作成されたディレクトリパスが報告されている
-
-## エスカレーション
-
-- **`docs/tasks/` が見つからない**: ディレクトリが無い場合は `/a-001-setup-doc-structure` の実行を促す
-- **スラッグ形式違反**: 英小文字・数字・ハイフンのみ（連続ハイフン禁止）で再入力を求める
-
-## 参考
-
-- [examples/naming-convention.md](examples/naming-convention.md) — タスク ID の採番ルールとスラッグ命名規則
+---
+name: b-001-create-task-directory
+description: docs/tasks/ 配下に連番タスク ID 付きディレクトリを作成する。新しい実装タスクに着手する最初の手順として使用。
+disable-model-invocation: true
+argument-hint: "[slug]"
+allowed-tools: Read, Write, Bash, Glob
+---
+
+# CreateTaskDirectory (b-001)
+
+## 目的
+
+- 新しいタスク専用のディレクトリを作成する（ID は自動採番）。
+- タスク ID の採番ルール（`taskXXXXXX`）を統一し、管理しやすくする。
+- **注意**: このスキルはディレクトリ作成のみ。タスク定義書などのドキュメント作成は後続のスキル（`/b-002-create-task-definition` など）で実施。
+
+## 前提
+
+- `docs/tasks/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure` を先に実行）
+
+## 手順
+
+### 1. スラッグの決定
+
+`$ARGUMENTS` が指定されている場合はそれをスラッグとして使用する。未指定の場合のみユーザーに質問:
+
+- 「タスクの内容を 3〜5 語の英数字とハイフンで表現してください（例: `user-profile-edit`）。」
+
+命名規則の詳細は [examples/naming-convention.md](examples/naming-convention.md) を参照。
+
+### 2. タスク 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
+# 既存タスクを確認して最大 ID を把握
+ls -d docs/tasks/task* 2>/dev/null
+
+# 採番した ID とスラッグでディレクトリを作成（{ID}/{SLUG} は実値に置換）
+mkdir -p "docs/tasks/task{ID}-{SLUG}"
+```
+
+### 3. 結果の確認
+
+作成パス（`docs/tasks/task{ID}-{SLUG}`）が生成されたことを確認。
+
+### 4. 次のステップの案内
+
+- 「タスクディレクトリ `docs/tasks/task{ID}-{SLUG}` を作成しました。」
+- 「続いてタスク定義書を作成しますか？（`/b-002-create-task-definition`）」
+
+## 完了条件
+
+- `docs/tasks/task{ID}-{SLUG}/` ディレクトリが作成されている
+- ユーザーに作成されたディレクトリパスが報告されている
+
+## エスカレーション
+
+- **`docs/tasks/` が見つからない**: ディレクトリが無い場合は `/a-001-setup-doc-structure` の実行を促す
+- **スラッグ形式違反**: 英小文字・数字・ハイフンのみ（連続ハイフン禁止）で再入力を求める
+
+## 参考
+
+- [examples/naming-convention.md](examples/naming-convention.md) — タスク ID の採番ルールとスラッグ命名規則

package/skills/b-002-create-task-definition/SKILL.md

@@ -1,114 +1,114 @@
----
-name: b-002-create-task-definition
-description: 対話を通じてタスク定義（目的・変更内容・受け入れ基準）を a-definition.md に記録する。タスクディレクトリ作成後、仕様を確定する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
-argument-hint: "[task-id]"
----
-
-# CreateTaskDefinition (b-002)
-
-## 目的
-
-- 新しいタスクの背景・目的・スコープを明確化する。
-- ユーザーストーリーと変更内容を整理し、後続のリサーチ・実装計画に渡す。
-- 測定可能な受け入れ基準を定義し、完了条件を共有する。
-
-## 前提
-
-- `docs/tasks/task{ID}-{SLUG}/` が `/b-001-create-task-directory` で作成済み
-- テンプレート: `../../templates/tasks/task-template/a-definition.md`（スキル配置ディレクトリ起点の相対参照）
-- タスクの概要が関係者と共有済み
-
-## 手順
-
-`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
-
-### 1. タスクディレクトリとテンプレートの確認
-
-対象タスクディレクトリを確認する。
-
-```bash
-ls -d docs/tasks/task*
-```
-
-このスキルの配置ディレクトリ（`skills/b-002-create-task-definition/`）を起点に、相対パス `../../templates/tasks/task-template/a-definition.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/a-definition.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
-
-### 2. 目的・背景のヒアリング
-
-現状の課題、困っている人、完了後の価値/KPI を具体的に確認。質問例は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#目的背景のヒアリング) を参照。
-
-### 3. ユーザーストーリーの整理
-
-形式「[役割]として、[目的]がしたい。なぜなら[理由]だから」で作成。優先度と関連 ID（US-001 等）を付与。詳細は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#ユーザーストーリー) を参照。
-
-### 4. 変更内容の洗い出し
-
-カテゴリ別（画面/UI、API/サービス、データモデル/DB、その他）に列挙。ファイル名・エンドポイント・テーブル名を具体的に記載。カテゴリ詳細: [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#変更内容のカテゴリ)
-
-### 5. 受け入れ基準の策定
-
-観点: 正常系、異常系・エラー表示、性能・セキュリティ、テスト要件。具体例は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#受け入れ基準の観点) を参照。
-
-### 6. ドキュメントへの反映
-
-`docs/tasks/task{ID}-{SLUG}/a-definition.md` に以下を順に埋める:
-
-- 目的・背景
-- ユーザーストーリー一覧
-- 変更内容一覧
-- 受け入れ基準
-- メモ/補足情報（関連 Issue・制約等）
-
-HTML コメントは削除せず、テンプレートのガイドとして残す。
-
-### 7. 構造チェック
-
-```bash
-grep "## 目的" docs/tasks/task{ID}-{SLUG}/a-definition.md \
-  && grep "## ユーザーストーリー" docs/tasks/task{ID}-{SLUG}/a-definition.md \
-  && grep "## 変更内容" docs/tasks/task{ID}-{SLUG}/a-definition.md \
-  && grep "## 受け入れ基準" docs/tasks/task{ID}-{SLUG}/a-definition.md \
-  && echo "OK" || echo "MISSING SECTION"
-```
-
-詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
-
-### 8. レビューと確認
-
-完成したドキュメントをユーザーに提示し、目的の明確さ・変更内容の網羅性・受け入れ基準の測定可能性を確認。質問例は [reference/structure-check.md](reference/structure-check.md#レビュー確認質問) を参照。
-
-### 9. Git への追加（任意）と次のステップ
-
-```bash
-git add docs/tasks/task{ID}-{SLUG}/a-definition.md
-git commit -m "docs(task): タスク定義書の作成 task{ID}"
-```
-
-次は `/b-003-create-task-research` でリサーチドキュメント作成を提案。
-
-## 完了条件
-
-- `docs/tasks/task{ID}-{SLUG}/a-definition.md` が作成されている
-- 以下のセクションがすべて記載:
-  - 目的（解決する問題、提供する価値）
-  - ユーザーストーリー一覧（最低1個以上）
-  - 変更内容一覧（該当カテゴリがすべて含まれる）
-  - 受け入れ基準（正常系、異常系、テスト要件）
-- 目的が具体的で測定可能、ストーリーは役割/目的/理由形式
-- 変更内容が具体的なファイル名・コンポーネント名を含む
-- ユーザーが内容を確認し承認している
-
-## エスカレーション
-
-- **タスクの目的が曖昧**: 「具体的な問題と解決後の状態を明確にしてください。」
-- **変更内容が不明確**: 「具体的なファイル名・コンポーネント名・カラム名を含めてください。」
-- **受け入れ基準が曖昧**: 「テスト可能な基準を定義してください。」（例: 「使いやすい」→「登録完了まで3クリック以内」）
-- **ユーザーストーリーが技術的すぎる**: ユーザー視点の価値を記載（例: 「React Hook Form を使用したい」→「入力エラーを即座に確認したい」）
-- **スコープが大きすぎる**: 複数タスクへの分割を推奨（1タスクは1〜5日で完了できる粒度が理想）
-- **セキュリティ要件が欠けている**: [reference/structure-check.md](reference/structure-check.md#セキュリティ要件の確認観点) の観点を提示
-
-## 参考
-
-- [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md) — ヒアリング質問、ユーザーストーリー形式、変更内容カテゴリ、受け入れ基準例
-- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点、セキュリティ観点
+---
+name: b-002-create-task-definition
+description: 対話を通じてタスク定義（目的・変更内容・受け入れ基準）を a-definition.md に記録する。タスクディレクトリ作成後、仕様を確定する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+argument-hint: "[task-id]"
+---
+
+# CreateTaskDefinition (b-002)
+
+## 目的
+
+- 新しいタスクの背景・目的・スコープを明確化する。
+- ユーザーストーリーと変更内容を整理し、後続のリサーチ・実装計画に渡す。
+- 測定可能な受け入れ基準を定義し、完了条件を共有する。
+
+## 前提
+
+- `docs/tasks/task{ID}-{SLUG}/` が `/b-001-create-task-directory` で作成済み
+- テンプレート: `../../templates/tasks/task-template/a-definition.md`（スキル配置ディレクトリ起点の相対参照）
+- タスクの概要が関係者と共有済み
+
+## 手順
+
+`$ARGUMENTS` が指定されている場合は `task{ID}-{SLUG}`（例: `task000003-auth-login`）として使用する。未指定の場合はユーザーに対象タスクを確認する。
+
+### 1. タスクディレクトリとテンプレートの確認
+
+対象タスクディレクトリを確認する。
+
+```bash
+ls -d docs/tasks/task*
+```
+
+このスキルの配置ディレクトリ（`skills/b-002-create-task-definition/`）を起点に、相対パス `../../templates/tasks/task-template/a-definition.md` を Read で読み込み、`docs/tasks/task{ID}-{SLUG}/a-definition.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。
+
+### 2. 目的・背景のヒアリング
+
+現状の課題、困っている人、完了後の価値/KPI を具体的に確認。質問例は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#目的背景のヒアリング) を参照。
+
+### 3. ユーザーストーリーの整理
+
+形式「[役割]として、[目的]がしたい。なぜなら[理由]だから」で作成。優先度と関連 ID（US-001 等）を付与。詳細は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#ユーザーストーリー) を参照。
+
+### 4. 変更内容の洗い出し
+
+カテゴリ別（画面/UI、API/サービス、データモデル/DB、その他）に列挙。ファイル名・エンドポイント・テーブル名を具体的に記載。カテゴリ詳細: [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#変更内容のカテゴリ)
+
+### 5. 受け入れ基準の策定
+
+観点: 正常系、異常系・エラー表示、性能・セキュリティ、テスト要件。具体例は [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md#受け入れ基準の観点) を参照。
+
+### 6. ドキュメントへの反映
+
+`docs/tasks/task{ID}-{SLUG}/a-definition.md` に以下を順に埋める:
+
+- 目的・背景
+- ユーザーストーリー一覧
+- 変更内容一覧
+- 受け入れ基準
+- メモ/補足情報（関連 Issue・制約等）
+
+HTML コメントは削除せず、テンプレートのガイドとして残す。
+
+### 7. 構造チェック
+
+```bash
+grep "## 目的" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && grep "## ユーザーストーリー" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && grep "## 変更内容" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && grep "## 受け入れ基準" docs/tasks/task{ID}-{SLUG}/a-definition.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 8. レビューと確認
+
+完成したドキュメントをユーザーに提示し、目的の明確さ・変更内容の網羅性・受け入れ基準の測定可能性を確認。質問例は [reference/structure-check.md](reference/structure-check.md#レビュー確認質問) を参照。
+
+### 9. Git への追加（任意）と次のステップ
+
+```bash
+git add docs/tasks/task{ID}-{SLUG}/a-definition.md
+git commit -m "docs(task): タスク定義書の作成 task{ID}"
+```
+
+次は `/b-003-create-task-research` でリサーチドキュメント作成を提案。
+
+## 完了条件
+
+- `docs/tasks/task{ID}-{SLUG}/a-definition.md` が作成されている
+- 以下のセクションがすべて記載:
+  - 目的（解決する問題、提供する価値）
+  - ユーザーストーリー一覧（最低1個以上）
+  - 変更内容一覧（該当カテゴリがすべて含まれる）
+  - 受け入れ基準（正常系、異常系、テスト要件）
+- 目的が具体的で測定可能、ストーリーは役割/目的/理由形式
+- 変更内容が具体的なファイル名・コンポーネント名を含む
+- ユーザーが内容を確認し承認している
+
+## エスカレーション
+
+- **タスクの目的が曖昧**: 「具体的な問題と解決後の状態を明確にしてください。」
+- **変更内容が不明確**: 「具体的なファイル名・コンポーネント名・カラム名を含めてください。」
+- **受け入れ基準が曖昧**: 「テスト可能な基準を定義してください。」（例: 「使いやすい」→「登録完了まで3クリック以内」）
+- **ユーザーストーリーが技術的すぎる**: ユーザー視点の価値を記載（例: 「React Hook Form を使用したい」→「入力エラーを即座に確認したい」）
+- **スコープが大きすぎる**: 複数タスクへの分割を推奨（1タスクは1〜5日で完了できる粒度が理想）
+- **セキュリティ要件が欠けている**: [reference/structure-check.md](reference/structure-check.md#セキュリティ要件の確認観点) の観点を提示
+
+## 参考
+
+- [examples/hearing-and-criteria.md](examples/hearing-and-criteria.md) — ヒアリング質問、ユーザーストーリー形式、変更内容カテゴリ、受け入れ基準例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点、セキュリティ観点