yodogawa 2.0.0 → 2.1.1

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

package/skills/a-003-create-scenarios/SKILL.md

@@ -1,142 +1,99 @@
----
-name: a-003-create-scenarios
-description: ユーザーストーリーから具体的なGherkinシナリオを作成し、BDD形式で振る舞いを定義するワークフロー
----
-
-# CreateScenarios (a-003)
-
-## 目的
-
-- ユーザーストーリーから具体的なシナリオ（振る舞い）を抽出し、Gherkin形式で記述する。
-- Given-When-Then構造で、開発者・QA・ステークホルダーが共通理解できる実行可能なドキュメントを作成する。
-- ハッピーパス（正常系）からエラーケース、境界値テストまでを網羅的に定義する。
-
-## 前提
-
-- `docs/project/requirements/05-user-stories.md` が作成されていること（先に `InitializeProject` (a-002) を実行）。
-- `docs/project/behavior/` ディレクトリが存在すること（存在しない場合は先に `SetupDocStructure` (a-001) を実行）。
-- ユーザーが各機能の具体的な動作例を説明できること。
-
-## 手順
-
-### 1. ディレクトリと前提条件の確認
-
-- `docs/project/behavior/` ディレクトリの存在を確認：
-
-  ```bash
-  ls -la docs/project/behavior/ 2>/dev/null || echo "ディレクトリが存在しません"
-  ```
-
-- ディレクトリが存在しない場合：
-  - ユーザーに通知：「`docs/project/behavior/` ディレクトリが見つかりません。先に `SetupDocStructure` (a-001) を実行してください。」
-
-- ユーザーストーリーの確認：
-  - `docs/project/requirements/05-user-stories.md` を読み込み、内容を確認する。
-
-### 2. テンプレートの準備
-
-- テンプレートをコピーして作業用ファイルを作成する：
-
-  ```bash
-  SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-  cp "$SCRIPT_DIR/templates/project/02-behavior/01-scenarios.md" "docs/project/behavior/01-scenarios.md"
-  ```
-
-### 3. 分析と提案
-
-- `docs/project/requirements/05-user-stories.md` を分析し、シナリオ作成対象の機能（Feature）をリストアップする。
-- 各機能について、考えられるシナリオ案（ハッピーパスと代表的なエラーケース）をユーザーに提案する：
-  - 「以下のユーザーストーリーに基づいて、シナリオを作成します：」
-  - 「機能: [機能名] (US-XXX)」
-    - 「シナリオ案1: [ハッピーパス]」
-    - 「シナリオ案2: [エラーケース]」
-
-### 4. ヒアリングと記入
-
-各機能について、以下の順序でヒアリングを行い、`docs/project/behavior/01-scenarios.md` を更新する。
-
-#### 4.1 Feature情報の定義
-
-- 機能名、説明、対応するユーザーストーリー（As a/I want/So that）を記入する。
-- **Background**（共通前提条件）がある場合は定義する。
-
-#### 4.2 シナリオの作成（ハッピーパス）
-
-- 「最も基本的な成功シナリオを教えてください。」
-- **Given**（前提）、**When**（アクション）、**Then**（結果）を確認し、Gherkin形式で記述する。
-- UI操作の詳細ではなく、ユーザーの意図を記述するよう注意する。
-
-#### 4.3 エラーケース・境界値の作成
-
-- 「エラーケースや境界値（エッジケース）はありますか？」
-- 必要に応じて **Scenario Outline**（パラメータ化）の使用を提案し、Examplesテーブルを作成する。
-
-#### 4.4 タグ付け
-
-- シナリオID（`@SC-XXX`）を採番する。
-- 適切なタグ（`@smoke`, `@happy-path`, `@error-handling` など）を付与する。
-
-### 5. シナリオ一覧テーブルの更新
-
-- ドキュメント冒頭の「シナリオ一覧」テーブルを更新し、作成した全シナリオのID、機能、シナリオ名、優先度を記載する。
-
-### 6. レビューと確認
-
-- 作成したシナリオをユーザーに提示し、以下を確認：
-  - 「シナリオは実際の動作を正しく表現していますか？」
-  - 「漏れているケースはありませんか？」
-  - 「非技術者でも理解できる表現になっていますか？」
-
-### 7. 完了条件と構造の確認
-
-- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
-
-  1. **構造確認**:
-
-     ```bash
-     # シナリオ一覧テーブルの確認
-     grep "| シナリオID | 機能 |" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Table Header"
-     # Feature定義の確認
-     grep "Feature:" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Feature definition"
-     # Scenario定義の確認
-     grep "Scenario:" docs/project/behavior/01-scenarios.md && echo "OK" || echo "MISSING: Scenario definition"
-     ```
-
-  2. **チェックリスト**:
-     - [ ] `docs/project/behavior/01-scenarios.md` が作成されている
-     - [ ] シナリオ一覧テーブルが更新されている
-     - [ ] 各FeatureがGherkin形式で記述されている
-     - [ ] 正常系と異常系のシナリオが網羅されている
-
-### 8. Git への追加（オプション）
-
-- ユーザーに確認：「作成したシナリオドキュメントを Git に追加しますか？」
-- 「はい」の場合、以下を実行：
-
-  ```bash
-  git add docs/project/behavior/
-  git status
-  ```
-
-- 推奨コミットメッセージ：
-
-  ```
-  docs: 振る舞い仕様（シナリオ）の作成
-
-  - ユーザーストーリーに基づくGherkinシナリオを追加
-  - 正常系・異常系・境界値ケースを定義
-  ```
-
-## 完了条件
-
-- `docs/project/behavior/01-scenarios.md` が作成されている。
-- ユーザーストーリーに対応する具体的なシナリオ（Given-When-Then）が記述されている。
-- シナリオ一覧テーブルがメンテナンスされている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- ユーザーストーリーが不明確でシナリオ化できない場合：
-  - 「ユーザーストーリーの詳細化が必要です。`InitializeProject` ワークフローに戻って要件を明確にしましょう。」と提案する。
-- 実装詳細への依存が強すぎる場合：
-  - 「UI操作（ボタンクリック等）ではなく、ユーザーの意図（登録する等）に焦点を当てた記述に変更しましょう。」とリファクタリングを提案する。
+---
+name: a-003-create-scenarios
+description: ユーザーストーリーから Gherkin 形式のシナリオを生成し、BDD で振る舞いを定義する。要件定義後、ドメインモデル設計前の振る舞い明確化に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# CreateScenarios (a-003)
+
+## 目的
+
+- ユーザーストーリーから具体的なシナリオ（振る舞い）を抽出し、Gherkin 形式で記述する。
+- Given-When-Then 構造で、開発者・QA・ステークホルダーが共通理解できる実行可能なドキュメントを作成する。
+- ハッピーパス（正常系）からエラーケース、境界値テストまでを網羅的に定義する。
+
+## 前提
+
+- `docs/project/01-requirements/05-user-stories.md` が作成されていること（`/a-002-initialize-project` 実行済み）。
+- `docs/project/02-behavior/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
+- ユーザーが各機能の具体的な動作例を説明できること。
+
+## 手順
+
+### 1. ディレクトリと前提条件の確認
+
+```bash
+ls -la docs/project/02-behavior/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+`docs/project/01-requirements/05-user-stories.md` を読み込み、シナリオ化対象を把握する。
+
+### 2. テンプレートの準備
+
+```bash
+SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
+cp "$SCRIPT_DIR/templates/project/02-behavior/01-scenarios.md" "docs/project/02-behavior/01-scenarios.md"
+```
+
+### 3. 分析と提案
+
+ユーザーストーリーを機能（Feature）単位にグルーピングし、ハッピーパスと代表的なエラーケースの案を提示。
+
+- 「機能: [機能名] (US-XXX)」
+- 「シナリオ案1: [ハッピーパス] / シナリオ案2: [エラーケース]」
+
+### 4. ヒアリングと記入
+
+機能ごとに以下を詰めて `docs/project/02-behavior/01-scenarios.md` を更新する。Gherkin 記述例は [examples/gherkin-templates.md](examples/gherkin-templates.md) を参照。
+
+- **Feature 情報**: 機能名、As a/I want/So that、Background（共通前提）
+- **ハッピーパス**: Given-When-Then で最も基本的な成功シナリオ
+- **エラーケース・境界値**: 必要に応じて Scenario Outline（Examples テーブル）を使用
+- **タグ付け**: `@SC-XXX` ID 採番、`@smoke` `@happy-path` `@error-handling` 等
+
+UI 操作の詳細ではなく、ユーザーの意図を記述するよう注意する。
+
+### 5. シナリオ一覧テーブルの更新
+
+ドキュメント冒頭の一覧テーブルに、全シナリオの ID・機能・シナリオ名・優先度を記載する。テーブル例は [examples/gherkin-templates.md](examples/gherkin-templates.md#シナリオ一覧テーブル例) を参照。
+
+### 6. レビューと確認
+
+ユーザーに提示し、実際の動作の正確性、抜け漏れ、非技術者への理解可能性を確認する。質問例は [reference/structure-check.md](reference/structure-check.md#レビュー確認質問) を参照。
+
+### 7. 構造チェック
+
+```bash
+grep "Feature:" docs/project/02-behavior/01-scenarios.md \
+  && grep "Scenario:" docs/project/02-behavior/01-scenarios.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細なチェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 8. Git への追加（任意）
+
+```bash
+git add docs/project/02-behavior/
+git commit -m "docs: 振る舞い仕様（シナリオ）の作成"
+```
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
+
+## 完了条件
+
+- `docs/project/02-behavior/01-scenarios.md` が作成されている。
+- ユーザーストーリーに対応する具体的なシナリオ（Given-When-Then）が記述されている。
+- シナリオ一覧テーブルがメンテナンスされている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **ユーザーストーリーが不明確でシナリオ化できない**: 「`/a-002-initialize-project` に戻って要件を明確にしましょう。」
+- **実装詳細への依存が強すぎる**: 「UI 操作（ボタンクリック等）ではなく、ユーザーの意図（登録する等）に焦点を当てた記述に変更しましょう。」
+
+## 参考
+
+- [examples/gherkin-templates.md](examples/gherkin-templates.md) — Feature / Scenario / Scenario Outline の記述例、タグ付けガイド、一覧テーブル例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー観点、Git 追加例

package/skills/a-003-create-scenarios/examples/gherkin-templates.md

@@ -0,0 +1,71 @@
+# Gherkin シナリオ記述例とタグ
+
+SKILL.md 手順3〜5 で使用する Gherkin 形式のテンプレートとタグ付けのサンプル。
+
+## Feature 定義の形式
+
+```gherkin
+Feature: [機能名]
+  As a [役割]
+  I want [やりたいこと]
+  So that [得られる価値]
+
+  Background:
+    Given [共通の前提条件]
+```
+
+## ハッピーパスのシナリオ例
+
+```gherkin
+@SC-001 @smoke @happy-path
+Scenario: 正常にログインできる
+  Given ユーザーは登録済みである
+  When 正しいメールアドレスとパスワードを入力する
+  And ログインボタンを押下する
+  Then ダッシュボード画面が表示される
+```
+
+- UI 操作（「ボタンをクリック」）ではなく、ユーザーの意図（「ログインする」）を優先する。
+- 複数ステップは `And` / `But` で繋ぐ。
+
+## エラーケース・境界値（Scenario Outline）
+
+```gherkin
+@SC-002 @error-handling
+Scenario Outline: 不正な入力でログインに失敗する
+  Given ユーザーは登録済みである
+  When <email> と <password> を入力する
+  Then <message> が表示される
+
+  Examples:
+    | email             | password   | message              |
+    | invalid@mail      | correctPw1 | メール形式が不正です  |
+    | test@example.com  |            | パスワードが必要です  |
+    | test@example.com  | wrong      | 認証に失敗しました    |
+```
+
+## タグ付けガイド
+
+- `@SC-XXX`: シナリオ ID（必須）
+- `@smoke`: リリース前の最小確認対象
+- `@happy-path`: 正常系
+- `@error-handling`: エラーケース
+- `@regression`: 実装済み機能のリグレッション
+- 優先度別: `@high`, `@medium`, `@low`
+
+## シナリオ一覧テーブル例
+
+| シナリオID | 機能 | シナリオ名 | 優先度 |
+|:--|:--|:--|:--|
+| SC-001 | 認証 | 正常ログイン | High |
+| SC-002 | 認証 | 入力エラー | High |
+| SC-003 | 登録 | メール認証完了 | Medium |
+
+## コミットメッセージ例
+
+```text
+docs: 振る舞い仕様（シナリオ）の作成
+
+- ユーザーストーリーに基づく Gherkin シナリオを追加
+- 正常系・異常系・境界値ケースを定義
+```

package/skills/a-003-create-scenarios/reference/structure-check.md

@@ -0,0 +1,46 @@
+# 構造チェックとレビュー観点
+
+SKILL.md 手順6〜7 で使う構造確認コマンドとレビュー観点。
+
+## セクション存在確認
+
+```bash
+# シナリオ一覧テーブルの確認
+grep "| シナリオID | 機能 |" docs/project/02-behavior/01-scenarios.md && echo "OK" || echo "MISSING: Table Header"
+# Feature 定義の確認
+grep "Feature:" docs/project/02-behavior/01-scenarios.md && echo "OK" || echo "MISSING: Feature definition"
+# Scenario 定義の確認
+grep "Scenario:" docs/project/02-behavior/01-scenarios.md && echo "OK" || echo "MISSING: Scenario definition"
+```
+
+## チェックリスト
+
+- [ ] `docs/project/02-behavior/01-scenarios.md` が作成されている
+- [ ] シナリオ一覧テーブルが更新されている
+- [ ] 各 Feature が Gherkin 形式で記述されている
+- [ ] 正常系と異常系のシナリオが網羅されている
+- [ ] Empty State や境界値も考慮されている
+- [ ] タグ（@SC-XXX, @smoke 等）が付与されている
+
+## レビュー確認質問
+
+- 「シナリオは実際の動作を正しく表現していますか？」
+- 「漏れているケース（エラー、境界値）はありませんか？」
+- 「非技術者でも理解できる表現になっていますか？」
+- 「UI 操作に依存せず、ユーザーの意図を表現できていますか？」
+
+## Git への追加（任意）
+
+```bash
+git add docs/project/02-behavior/
+git status
+```
+
+推奨コミットメッセージ:
+
+```text
+docs: 振る舞い仕様（シナリオ）の作成
+
+- ユーザーストーリーに基づく Gherkin シナリオを追加
+- 正常系・異常系・境界値ケースを定義
+```