yodogawa 2.0.0 → 2.1.0

package/skills/a-002-initialize-project/SKILL.md

@@ -1,289 +1,124 @@
----
-name: a-002-initialize-project
-description: プロジェクトのシステム概要・機能要件・非機能要件・ユーザーストーリーを体系的にヒアリングし、詳細なドキュメントを作成するワークフロー
-auto_execution_mode: 1
----
-
-# InitializeProject (a-002)
-
-## 目的
-
-- プロジェクトの目的・背景・機能要件を詳細にヒアリングし、具体的で実装可能なドキュメントを作成する。
-- システム概要・実装済み機能・予定機能・非機能要件・ユーザーストーリーを網羅する。
-- 抽象的・曖昧な表現を避け、ユーザーとの対話を通じて具体的な数値・期限・制約・優先度を明確化する。
-- 後続の設計・実装フェーズで参照できる、チーム全体が理解できる要件定義書を整備する。
-
-## 前提
-
-- `docs/project/requirements/` ディレクトリが存在すること（存在しない場合は先に `SetupDocStructure` (a-001) ワークフローを実行）。
-- プロジェクトリポジトリの `docs/` ディレクトリに書き込み権限があること。
-- ユーザーがプロジェクトの概要と主要な機能について基本的な情報を提供できること。
-
-## 手順
-
-### 1. ドキュメントディレクトリの確認
-
-- `docs/project/requirements/` ディレクトリの存在を確認：
-
-  ```bash
-  ls -la docs/project/requirements/ 2>/dev/null || echo "ディレクトリが存在しません"
-  ```
-
-- ディレクトリが存在しない場合：
-  - ユーザーに通知：「`docs/project/requirements/` ディレクトリが見つかりません。先に `SetupDocStructure` (a-001) を実行してディレクトリ構造を作成してください。」
-
-### 2. コードベースの自動分析と提案
-
-1. **コードベースの規模確認**:
-
-   - プロジェクトのルートにあるファイルやディレクトリを確認する。
-
-     ```bash
-     ls -F
-     ```
-
-   - **スキップ判断**:
-     - ファイルがほとんど存在しない（例: `.git` ディレクトリのみ、あるいは `README.md` だけなど）、または有意なソースコードが見当たらない場合は、このステップをスキップする。
-     - スキップする場合、ユーザーに「コードベースが空、または十分な情報がないため、自動分析をスキップします。」と通知し、次のステップへ進む。
-
-2. **詳細調査と分析（コードが存在する場合）**:
-   - `README.md`, `package.json`, および主要なソースコードを読み込む。
-
-     ```bash
-     cat package.json 2>/dev/null
-     cat README.md 2>/dev/null
-     find src app lib -maxdepth 2 2>/dev/null
-     ```
-
-   - 読み込んだ情報を基に、以下の内容を分析・推測し、ユーザーに提示する。
-     - **システム概要**: プロジェクトの目的、主要な技術スタック。
-     - **実装済み機能**: ファイル構造やコードから推測される機能。
-     - **ユーザーストーリー**: 想定されるユーザー像と利用シーン。
-   - この分析結果は、後続のステップ（システム概要の作成、機能一覧の作成など）の基礎情報として活用する。
-
-### 3. システム概要の作成
-
-1. **テンプレートの準備**:
-
-   ```bash
-   SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-   cp "$SCRIPT_DIR/templates/project/01-requirements/01-system-overview.md" "docs/project/requirements/01-system-overview.md"
-   ```
-
-2. **ヒアリングと記入**:
-   以下の質問を行い、その回答で `docs/project/requirements/01-system-overview.md` を更新する。
-
-   #### 背景
-
-   - 「このシステムで解決しようとしている**具体的な問題や課題**は何ですか？」
-   - 「その問題はなぜ重要ですか？放置した場合のリスクは？」
-   - 「問題の影響を受けるステークホルダー（ユーザー、組織、チームなど）は誰ですか？」
-   - 「具体的な数値やデータ（例：作業時間、コスト、離脱率など）があれば教えてください。」
-
-   #### 目的
-
-   - 「このシステムが提供する**具体的な価値や解決策**は何ですか？」
-   - 「期待される成果や変化を、測定可能な形で表現できますか？（例：作業時間 50%削減）」
-   - 「どのように問題を解決するか、具体的なメカニズムや仕組みを教えてください。」
-
-### 4. 実装済み機能一覧の作成
-
-1. **テンプレートの準備**:
-
-   ```bash
-   SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-   cp "$SCRIPT_DIR/templates/project/01-requirements/02-features-implemented.md" "docs/project/requirements/02-features-implemented.md"
-   ```
-
-2. **コードベースの調査と提案**:
-
-   - プロジェクト内のソースコードを簡易検索し、実装済みの兆候を探す。
-
-     ```bash
-     # 主要なソースディレクトリの構造を確認（例）
-     find src app lib -maxdepth 2 -type d 2>/dev/null
-     # 特徴的なファイル名を検索
-     find . -type f -name "*Controller*" -o -name "*Service*" -o -name "*Component*" | head -n 20
-     ```
-
-   - 検出されたディレクトリ名やファイル名から機能を推測し、ユーザーに提案する。
-     - 「`src/auth` ディレクトリが見つかりました。認証機能（ログイン、登録など）は実装済みですか？」
-     - 「`PaymentController` があります。決済機能は稼働していますか？」
-
-3. **ヒアリングと記入**:
-   提案内容へのフィードバックを含め、以下の質問を行う。回答をテーブル形式で `docs/project/requirements/02-features-implemented.md` に記入する（該当なしの場合は「なし」と記載）。
-
-   - 「既に実装済みの機能はありますか？（提案した機能含む）ある場合、以下の情報を教えてください：」
-     - **Category 1**（大分類：ユーザー管理、コンテンツなど）
-     - **Category 2**（中分類：認証、プロフィールなど）
-     - **機能名**（ユーザー視点の名称）
-     - **説明**（何ができるか）
-     - **機能 ID**（FN-XXX 形式、連番）
-
-### 5. 予定機能一覧の作成
-
-1. **テンプレートの準備**:
-
-   ```bash
-   SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-   cp "$SCRIPT_DIR/templates/project/01-requirements/03-features-planned.md" "docs/project/requirements/03-features-planned.md"
-   ```
-
-2. **要件ギャップ分析と提案**:
-
-   - 「システム概要」で確認した目的・スコープと、「実装済み機能」の差分を分析する。
-   - 未実装と思われる主要機能をリストアップし、ユーザーに提案する。
-     - 「システム概要で『〇〇機能』への言及がありましたが、まだ実装されていないようです。これを予定機能に追加しますか？」
-     - 「現在の実装には『××』が含まれていますが、これに関連する『△△ 機能』は将来的に必要になりますか？」
-
-3. **ヒアリングと記入**:
-   提案内容へのフィードバックを含め、以下の質問を行う。回答をテーブル形式で `docs/project/requirements/03-features-planned.md` に記入する。
-
-   - 「今後実装予定の機能をリストアップしてください（提案した機能含む）。各機能について以下を明確にします：」
-
-     - **Category 1**（大分類）
-     - **Category 2**（中分類）
-     - **機能名**（アイデア段階でも可）
-     - **説明**（目的や価値を中心に）
-
-     ※テンプレートの方針に従い、**機能 ID**や**優先度**はこの段階では確定させず、柔軟性を重視して記載しない。
-
-### 6. 非機能要件一覧の作成
-
-1. **テンプレートの準備**:
-
-   ```bash
-   SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-   cp "$SCRIPT_DIR/templates/project/01-requirements/04-non-functional-requirements.md" "docs/project/requirements/04-non-functional-requirements.md"
-   ```
-
-2. **必要性の確認と標準提案**:
-
-   - ユーザーに定義の必要性を確認する：
-
-     - 「現段階で非機能要件（パフォーマンス、セキュリティなど）を詳細に定義する必要がありますか？『標準的な設定』で仮置きして後で調整することも可能です。」
-
-   - 必要または仮置きの場合、一般的なベストプラクティスを提案する：
-     - 「Web アプリケーションの標準的な目標値として、以下を提案します。これで問題ないか確認してください：」
-       - **パフォーマンス**: ページ読み込み 3 秒以内、API 応答 500ms 以内
-       - **セキュリティ**: HTTPS 必須、パスワードはハッシュ化、基本認証/OAuth
-       - **可用性**: 日次バックアップ、稼働率 99.5%（平日日中）
-
-3. **ヒアリングと記入**:
-   提案内容への合意、または独自の要件がある場合、以下の観点で**定量的な目標**を確認し、回答で `docs/project/requirements/04-non-functional-requirements.md` の各テーブルを更新する。
-
-   #### パフォーマンス
-
-   - 「ページ読み込み時間の目標は？」
-   - 「API レスポンス時間の目標は？」
-   - 「想定される同時接続ユーザー数、データ量は？」
-
-   #### セキュリティ
-
-   - 「認証方式、機密データの扱い、コンプライアンス要件は？」
-
-   #### 可用性・信頼性
-
-   - 「稼働率目標、許容ダウンタイム、バックアップ要件は？」
-
-   #### スケーラビリティ
-
-   - 「ユーザー数の成長予測、ピーク時のトラフィック想定は？」
-
-   #### ユーザビリティ・保守性
-
-   - 「アクセシビリティ、対応言語、デバイス、ブラウザは？」
-   - 「ログ・監視要件、デプロイ頻度は？」
-
-### 7. ユーザーストーリーの作成
-
-1. **テンプレートの準備**:
-
-   ```bash
-   SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-   cp "$SCRIPT_DIR/templates/project/01-requirements/05-user-stories.md" "docs/project/requirements/05-user-stories.md"
-   ```
-
-2. **分析と提案**:
-
-   - ここまで作成した「システム概要」「機能一覧（実装済み/予定）」を分析し、主要なユーザージャーニーを抽出する。
-   - ユーザーに代表的なストーリーを提案する：
-     - 「『〇〇機能』に基づき、以下のストーリーが考えられますが、いかがでしょうか？」
-       - 「[役割]として、[〇〇機能]を使いたい、なぜなら[価値]だから」
-
-3. **ヒアリングと記入**:
-   提案内容へのフィードバックを含め、以下の質問を行う。回答をテーブル形式で `docs/project/requirements/05-user-stories.md` に記入する。
-
-   - 「他に主要なユーザージャーニーがあれば教えてください（[役割]として、[目的]がしたい、なぜなら[理由]）。」
-   - 各ストーリーの優先度、受け入れ基準を確認する。
-
-### 8. 全体レビュー
-
-- 作成した全てのドキュメントをユーザーに提示し、内容の正確性を確認する。
-  - 「記載内容に誤りや漏れはありませんか？」
-  - 「抽象的すぎる記述や、後で解釈が分かれそうな表現はありますか？」
-  - 「テンプレートのコメントや不要な例示は適切に処理（残す/削除）されていますか？」
-
-### 9. 完了条件と構造の確認
-
-- 以下の完了条件を満たしていて、且つドキュメントの構造が適切であることを確認します。
-
-  1. **ファイルの存在と構造確認**:
-     各ファイルが存在し、テンプレートの主要な構造（見出しやテーブル）が維持されているか検証する。
-
-     ```bash
-     # 01-system-overview.md: 主要セクションの確認
-     grep "## 背景" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 背景"
-     grep "## 目的" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 目的"
-
-     # 02-features-implemented.md: テーブルヘッダーの確認
-     grep "| 機能ID | Category 1 |" docs/project/requirements/02-features-implemented.md && echo "OK" || echo "MISSING: Table Header"
-
-     # 03-features-planned.md: テーブルヘッダーの確認
-     grep "| Category 1 | Category 2 |" docs/project/requirements/03-features-planned.md && echo "OK" || echo "MISSING: Table Header"
-
-     # 04-non-functional-requirements.md: テーブルヘッダーの確認
-     grep "| カテゴリ | 要件 |" docs/project/requirements/04-non-functional-requirements.md && echo "OK" || echo "MISSING: Table Header"
-
-     # 05-user-stories.md: テーブルヘッダーの確認
-     grep "| ストーリーID | ストーリー |" docs/project/requirements/05-user-stories.md && echo "OK" || echo "MISSING: Table Header"
-     ```
-
-  2. **チェックリスト**:
-     - [ ] すべてのファイルが存在する
-     - [ ] 各ファイルがテンプレートの基本構造を維持していて、主要なセクションやテーブルが適切に記載されている
-     - [ ] プレースホルダーが適切な内容に置き換わっていいる
-
-### 10. Git への追加（オプション）
-
-- ユーザーに確認：「作成した要件定義ドキュメントを Git に追加しますか？」
-- 「はい」の場合、以下を実行：
-
-  ```bash
-  git add docs/project/requirements/
-  git status
-  ```
-
-- Git status の結果を表示し、コミットメッセージの提案をする：
-
-  ```
-  推奨コミットメッセージ:
-  docs: 要件定義ドキュメントの作成
-
-  - システム概要、機能要件、非機能要件、ユーザーストーリーを追加
-  ```
-
-## 完了条件
-
-- `docs/project/requirements/` 配下に一連の要件定義ドキュメントが作成されている。
-- すべてのドキュメントで抽象的な表現が最小化され、具体的な数値・期限・制約が記載されている。
-- ユーザーがドキュメント内容を確認し、承認またはフィードバックを提供している。
-
-## エスカレーション
-
-- ユーザーが重要な情報を提供できない場合：
-  - 「この情報は後続の設計・実装で必須です。確認できる担当者や資料はありますか？」と確認し、TODO として記録する。
-- 競合する要件や矛盾が発見された場合：
-  - 「以下の要件が競合しています：[詳細]。優先順位や調整方針を確認させてください。」と報告する。
-- 想定工数が非現実的に大きい場合：
-  - 「現在の計画では実現が困難です。スコープ縮小や優先度調整を検討しませんか？」と提案する。
+---
+name: a-002-initialize-project
+description: プロジェクトの要件を対話形式で収集し、システム概要・機能要件・非機能要件・ユーザーストーリーのドキュメントを生成する。新規プロジェクト開始時、または要件が未整備の場合に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# InitializeProject (a-002)
+
+## 目的
+
+- プロジェクトの目的・背景・機能要件を詳細にヒアリングし、具体的で実装可能なドキュメントを作成する。
+- システム概要・実装済み機能・予定機能・非機能要件・ユーザーストーリーを網羅する。
+- 抽象的・曖昧な表現を避け、対話を通じて具体的な数値・期限・制約・優先度を明確化する。
+
+## 前提
+
+- `docs/project/requirements/` ディレクトリが存在すること（なければ先に `/a-001-setup-doc-structure` を実行）
+- `docs/` に書き込み権限があること
+- ユーザーがプロジェクト概要と主要機能の基本情報を提供できること
+
+## 手順
+
+### 1. ドキュメントディレクトリの確認
+
+```bash
+ls -la docs/project/requirements/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+存在しない場合: 「`docs/project/requirements/` がありません。先に `/a-001-setup-doc-structure` を実行してください。」
+
+### 2. コードベースの自動分析と提案
+
+**規模確認**:
+
+```bash
+ls -F
+```
+
+ファイルがほとんど無い／ソースコードが無い場合はスキップし、ユーザーへ通知。
+
+**詳細調査**（コードがある場合）:
+
+```bash
+cat package.json 2>/dev/null
+cat README.md 2>/dev/null
+find src app lib -maxdepth 2 2>/dev/null
+```
+
+結果から以下を推測・提示: システム概要（目的・技術スタック）、実装済み機能（ファイル構造からの推測）、想定ユーザー像。
+
+### 3. システム概要の作成
+
+1. テンプレートをコピー:
+
+   ```bash
+   SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
+   cp "$SCRIPT_DIR/templates/project/01-requirements/01-system-overview.md" \
+      "docs/project/requirements/01-system-overview.md"
+   ```
+
+2. 「背景」「目的」をヒアリングして記入。質問例は [reference/hearing-questions.md](reference/hearing-questions.md) を参照。
+
+### 4. 実装済み機能一覧
+
+1. `02-features-implemented.md` をテンプレートからコピー。
+2. コードベースを調査し、検出したディレクトリ/ファイル名から機能を提案。
+3. ヒアリング結果をテーブルに記入（Category 1/2、機能名、説明、機能 ID）。
+
+コード調査コマンドとヒアリング項目は [reference/hearing-questions.md](reference/hearing-questions.md#手順4-実装済み機能一覧) を参照。
+
+### 5. 予定機能一覧
+
+1. `03-features-planned.md` をテンプレートからコピー。
+2. システム概要と実装済み機能のギャップを分析し、未実装機能を提案。
+3. ヒアリング結果をテーブルに記入（機能 ID・優先度は未確定のまま）。
+
+### 6. 非機能要件一覧
+
+1. `04-non-functional-requirements.md` をテンプレートからコピー。
+2. 詳細定義が必要か確認。不要なら標準ベースラインで仮置き（[examples/nfr-baseline.md](examples/nfr-baseline.md)）。
+3. パフォーマンス/セキュリティ/可用性/スケーラビリティ/ユーザビリティ・保守性の観点で**定量的な目標**をヒアリング。
+
+### 7. ユーザーストーリー
+
+1. `05-user-stories.md` をテンプレートからコピー。
+2. 作成済みドキュメントから主要ユーザージャーニーを抽出し、ストーリー案を提示。
+3. ヒアリング結果をテーブルに記入（優先度・受け入れ基準含む）。
+
+ストーリーテンプレート: 「[役割]として、[〇〇機能]を使いたい、なぜなら[価値]だから」
+
+### 8. 全体レビュー
+
+- 作成した全ドキュメントをユーザーに提示し、以下を確認:
+  - 「記載内容に誤りや漏れはありませんか？」
+  - 「抽象的すぎる記述や、解釈が分かれそうな表現はありますか？」
+  - 「テンプレートのコメントや不要な例示は適切に処理されていますか？」
+
+### 9. 完了条件と構造の確認
+
+- ファイルの存在と主要セクション/テーブル構造を検証。
+- 検証コマンド・チェックリスト・Git コミット手順は [reference/structure-check.md](reference/structure-check.md) を参照。
+
+### 10. Git への追加（オプション）
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加オプション) を参照。
+
+## 完了条件
+
+- `docs/project/requirements/` に 5 つの要件定義ドキュメントが作成されている
+- すべてのドキュメントで抽象的表現が最小化され、具体的な数値・期限・制約が記載されている
+- ユーザーがドキュメント内容を確認し、承認またはフィードバックを提供している
+
+## エスカレーション
+
+- **ユーザーが重要な情報を提供できない**: 「この情報は後続の設計・実装で必須です。確認できる担当者や資料はありますか？」と確認し、TODO として記録。
+- **競合する要件や矛盾**: 「以下の要件が競合しています: [詳細]。優先順位や調整方針を確認させてください。」と報告。
+- **想定工数が非現実的に大きい**: 「現在の計画では実現が困難です。スコープ縮小や優先度調整を検討しませんか？」と提案。
+
+## 参考
+
+- [reference/hearing-questions.md](reference/hearing-questions.md) — 手順3〜7のヒアリング質問集
+- [reference/structure-check.md](reference/structure-check.md) — 手順9の構造チェックコマンドと Git コミット手順
+- [examples/nfr-baseline.md](examples/nfr-baseline.md) — 非機能要件の標準ベースライン提案値

package/skills/a-002-initialize-project/examples/nfr-baseline.md

@@ -0,0 +1,38 @@
+# 非機能要件の標準ベースライン
+
+SKILL.md 手順6で「標準的な設定で仮置き」する際の提案値。
+
+## Web アプリケーションの一般的な目標値
+
+### パフォーマンス
+
+- ページ読み込み: 3 秒以内
+- API 応答: 500ms 以内
+
+### セキュリティ
+
+- HTTPS 必須
+- パスワードはハッシュ化（bcrypt 推奨）
+- 認証方式: 基本認証 / OAuth
+
+### 可用性
+
+- 稼働率: 99.5%（平日日中）
+- 日次バックアップ
+
+### スケーラビリティ
+
+- 想定同時接続数の 2 倍のバースト耐性
+- 水平スケーリング可能なアーキテクチャ
+
+### ユーザビリティ
+
+- WCAG 2.1 レベル AA 準拠（アクセシビリティ）
+- 対応ブラウザ: 最新 2 バージョン（Chrome / Safari / Edge / Firefox）
+- レスポンシブデザイン（PC / タブレット / モバイル）
+
+### 保守性
+
+- 構造化ログ（JSON 形式）
+- 監視: APM + アラート通知
+- デプロイ: 日次 or オンデマンド

package/skills/a-002-initialize-project/reference/hearing-questions.md

@@ -0,0 +1,92 @@
+# ヒアリング質問集
+
+SKILL.md 手順3〜7で各テンプレートに記入する際のヒアリング質問一覧。
+
+## 手順3: システム概要
+
+### 背景
+
+- 「このシステムで解決しようとしている**具体的な問題や課題**は何ですか？」
+- 「その問題はなぜ重要ですか？放置した場合のリスクは？」
+- 「問題の影響を受けるステークホルダー（ユーザー、組織、チームなど）は誰ですか？」
+- 「具体的な数値やデータ（作業時間、コスト、離脱率など）があれば教えてください。」
+
+### 目的
+
+- 「このシステムが提供する**具体的な価値や解決策**は何ですか？」
+- 「期待される成果や変化を、測定可能な形で表現できますか？（例: 作業時間 50%削減）」
+- 「どのように問題を解決するか、具体的なメカニズムや仕組みを教えてください。」
+
+## 手順4: 実装済み機能一覧
+
+### コード調査のヒントと提案
+
+```bash
+find src app lib -maxdepth 2 -type d 2>/dev/null
+find . -type f -name "*Controller*" -o -name "*Service*" -o -name "*Component*" | head -n 20
+```
+
+提案例:
+
+- 「`src/auth` ディレクトリが見つかりました。認証機能（ログイン、登録など）は実装済みですか？」
+- 「`PaymentController` があります。決済機能は稼働していますか？」
+
+### ヒアリング項目
+
+- 「既に実装済みの機能はありますか？（提案した機能含む）」
+  - **Category 1**（大分類: ユーザー管理、コンテンツなど）
+  - **Category 2**（中分類: 認証、プロフィールなど）
+  - **機能名**（ユーザー視点の名称）
+  - **説明**（何ができるか）
+  - **機能 ID**（FN-XXX 形式、連番）
+
+## 手順5: 予定機能一覧
+
+### 差分分析からの提案例
+
+- 「システム概要で『〇〇機能』への言及がありましたが、まだ実装されていないようです。予定機能に追加しますか？」
+- 「現在の実装に『××』が含まれていますが、関連する『△△機能』は将来的に必要ですか？」
+
+### ヒアリング項目
+
+- **Category 1** / **Category 2**
+- **機能名**（アイデア段階でも可）
+- **説明**（目的や価値を中心に）
+
+※ 機能 ID・優先度はこの段階では確定させず、柔軟性を重視して記載しない。
+
+## 手順6: 非機能要件
+
+### パフォーマンス
+
+- 「ページ読み込み時間の目標は？」
+- 「API レスポンス時間の目標は？」
+- 「想定される同時接続ユーザー数、データ量は？」
+
+### セキュリティ
+
+- 「認証方式、機密データの扱い、コンプライアンス要件は？」
+
+### 可用性・信頼性
+
+- 「稼働率目標、許容ダウンタイム、バックアップ要件は？」
+
+### スケーラビリティ
+
+- 「ユーザー数の成長予測、ピーク時のトラフィック想定は？」
+
+### ユーザビリティ・保守性
+
+- 「アクセシビリティ、対応言語、デバイス、ブラウザは？」
+- 「ログ・監視要件、デプロイ頻度は？」
+
+## 手順7: ユーザーストーリー
+
+### 提案テンプレート
+
+「[役割]として、[〇〇機能]を使いたい、なぜなら[価値]だから」
+
+### ヒアリング項目
+
+- 「他に主要なユーザージャーニーがあれば教えてください（[役割]として、[目的]がしたい、なぜなら[理由]）」
+- 各ストーリーの優先度、受け入れ基準

package/skills/a-002-initialize-project/reference/structure-check.md

@@ -0,0 +1,48 @@
+# 構造チェックコマンド集
+
+SKILL.md 手順9で使う、生成済みドキュメントの構造確認用コマンド。
+
+## 5ドキュメントの必須セクション/テーブル検証
+
+```bash
+# 01-system-overview.md: 主要セクションの確認
+grep "## 背景" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 背景"
+grep "## 目的" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 目的"
+
+# 02-features-implemented.md: テーブルヘッダー
+grep "| 機能ID | Category 1 |" docs/project/requirements/02-features-implemented.md \
+  && echo "OK" || echo "MISSING: Table Header"
+
+# 03-features-planned.md: テーブルヘッダー
+grep "| Category 1 | Category 2 |" docs/project/requirements/03-features-planned.md \
+  && echo "OK" || echo "MISSING: Table Header"
+
+# 04-non-functional-requirements.md: テーブルヘッダー
+grep "| カテゴリ | 要件 |" docs/project/requirements/04-non-functional-requirements.md \
+  && echo "OK" || echo "MISSING: Table Header"
+
+# 05-user-stories.md: テーブルヘッダー
+grep "| ストーリーID | ストーリー |" docs/project/requirements/05-user-stories.md \
+  && echo "OK" || echo "MISSING: Table Header"
+```
+
+## チェックリスト
+
+- [ ] すべてのファイルが存在する
+- [ ] 各ファイルがテンプレートの基本構造を維持している（主要セクション・テーブル）
+- [ ] プレースホルダーが適切な内容に置き換わっている
+
+## Git への追加（オプション）
+
+```bash
+git add docs/project/requirements/
+git status
+```
+
+推奨コミットメッセージ:
+
+```
+docs: 要件定義ドキュメントの作成
+
+- システム概要、機能要件、非機能要件、ユーザーストーリーを追加
+```