yodogawa 2.0.0 → 2.1.0

package/skills/a-006-review-requirements-domain/examples/review-report-template.md

@@ -0,0 +1,58 @@
+# レビュー結果レポートテンプレート
+
+SKILL.md 手順3 で作成する `docs/project/REVIEW-REPORT-*.md` のフォーマット例。
+
+## レポートフォーマット
+
+```markdown
+# ドキュメント一貫性レビュー結果
+
+**実施日**: YYYY-MM-DD
+
+## サマリー
+
+- OK: X 項目
+- Warning: X 項目
+- Error: X 項目
+
+## 詳細
+
+### 1. ユーザーストーリー ↔ シナリオ
+
+- **Error**: US-005 に対応するシナリオが見つかりません。
+- OK: 優先度 High のストーリーはすべてカバーされています。
+
+### 2. 機能要件・非機能要件
+
+- **Warning**: 実装済み機能「決済」のシナリオが不足しています。
+- OK: パフォーマンス要件に対応する Read Model が定義されています。
+
+### 3. シナリオ ↔ ドメインモデル
+
+- **Warning**: シナリオ SC-003 の Command「在庫を引き当てる」がドメインモデルに未定義です。
+
+### 4. ユビキタス言語
+
+- **Error**: 用語「ShippingAddress」がユビキタス言語一覧にありません。
+- **Warning**: 禁止用語「User Data」が `01-domain-model.md` で使用されています。
+
+## 推奨アクション
+
+1. `/a-003-create-scenarios` で US-005 のシナリオを追加する。
+2. `/a-004-define-domain-model` で「在庫を引き当てる」コマンドを定義する。
+3. `01-domain-model.md` の「User Data」を「User Profile」に修正する。
+```
+
+## 重大度記号の使い方
+
+| 記号 | 意味 | 対応 |
+|:--|:--|:--|
+| OK | 問題なし | 記録のみ |
+| Warning | 軽微な不整合 | 計画的に修正 |
+| Error | 重大な不整合 | 実装前に必ず修正 |
+
+## コミットメッセージ例
+
+```text
+docs: 要件・ドメイン整合性レビューレポートの作成
+```

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

@@ -0,0 +1,60 @@
+# 一貫性チェック項目詳細
+
+SKILL.md 手順2 で実施する各チェック項目の詳細。自動検索（grep 等）と手動確認を組み合わせる。
+
+## 2.1 ユーザーストーリー ↔ シナリオ
+
+- **カバレッジ**: すべての US-XXX に対応する SC-XXX が存在するか。
+- **整合性**: ストーリーの「価値」とシナリオの「結果（Then）」が一致しているか。
+
+```bash
+# 全ユーザーストーリーの ID 抽出
+grep -oE "US-[0-9]+" docs/project/requirements/05-user-stories.md | sort -u
+# シナリオ側の参照
+grep -oE "US-[0-9]+" docs/project/behavior/01-scenarios.md | sort -u
+```
+
+## 2.2 実装済み機能・予定機能 ↔ シナリオ
+
+- **実装済み機能**: `02-features-implemented.md` の機能にリグレッション用シナリオが存在するか。
+- **予定機能**: `03-features-planned.md` の優先度 High 機能にシナリオが存在するか。
+
+## 2.3 非機能要件 ↔ ドメインモデル
+
+- **パフォーマンス**: `04-non-functional-requirements.md` の要件（読み込み速度、スループット等）に対し、Read Model や CQRS が検討されているか。
+- **セキュリティ**: 認証・権限要件が Policy や Guard としてドメインモデルに含まれているか。
+
+## 2.4 シナリオ ↔ ドメインモデル
+
+- **Command**: シナリオの When（アクション）がドメインモデルの Command として定義されているか。
+- **Event**: シナリオの Then（結果）が Domain Event として定義されているか。
+- **Actor**: シナリオの Actor がドメインモデルに存在するか。
+
+## 2.5 ユビキタス言語の遵守
+
+- **用語定義**: ドメインモデルの主要要素（Aggregate, Command, Event）がユビキタス言語一覧にあるか。
+- **禁止用語**: 各ドキュメントに禁止用語（Data, Process, Manager 等）が使われていないか。
+
+```bash
+# 禁止用語の簡易検索
+grep -rn "Data" docs/project/domain/ || echo "No 'Data' found"
+grep -rn "Process" docs/project/domain/ || echo "No 'Process' found"
+grep -rn "Manager" docs/project/domain/ || echo "No 'Manager' found"
+```
+
+## 2.6 目的との整合性
+
+- システム概要（`01-system-overview.md`）の「目的」とドメインモデルの「Core Domain」が一致しているか。
+- ビジネス価値の提供元が Core に寄っているか（Generic に偏っていないか）。
+
+## エスカレーションの判断材料
+
+- **多数の Error が検出された場合**: ドキュメント信頼性が低い → 関係者を集めた大規模レビュー会議を推奨。
+- **Core Domain での不整合**: リスクが高い → 実装前に必ず解消。
+
+## Git への追加（任意）
+
+```bash
+git add docs/project/REVIEW-REPORT-*.md
+git commit -m "docs: 要件・ドメイン整合性レビューレポートの作成"
+```

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

@@ -1,130 +1,102 @@
----
-name: a-007-define-tech-stack
-description: 要件を分析して推奨技術スタックを提案し、ユーザーとの詳細なインタビューを通じて最適な技術選定を行うワークフロー
----
-
-# DefineTechStack (a-007)
-
-## 目的
-
-- 既存の要件ドキュメント（システム概要、非機能要件、ドメインモデル）を分析し、適合する技術スタックを推奨する。
-- 推奨案を提示した上で、ユーザーと詳細なインタビューを行い、すべての技術選定を明確化する。
-- 技術選定の理由、バージョン、選定タイミング（初期/中期/後期/随時）を明確に記録する。
-
-## 前提
-
-- `docs/project/requirements/` 配下のドキュメントが作成されていること。
-- `docs/project/domain/` 配下のドキュメントが作成されていること。
-- `docs/project/design/` ディレクトリが存在すること（存在しない場合は先に `SetupDocStructure` (a-001) を実行）。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-- `docs/project/design/` ディレクトリの存在を確認
-
-  ```bash
-  ls -la docs/project/design/ 2>/dev/null || echo "ディレクトリが存在しません"
-  ```
-
-- 存在しない場合：ユーザーに通知し、`SetupDocStructure` (a-001) を実行するよう促す。
-
-- 必要な要件ドキュメントを読み込む：
-  - `docs/project/requirements/01-system-overview.md`
-  - `docs/project/requirements/03-features-planned.md`
-  - `docs/project/requirements/04-non-functional-requirements.md`
-  - `docs/project/domain/01-domain-model.md`
-
-### 2. テンプレートの準備
-
-- テンプレートをコピーして作業用ファイルを作成する：
-
-  ```bash
-  SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-  cp "$SCRIPT_DIR/templates/project/04-design/01-tech-stack.md" "docs/project/design/01-tech-stack.md"
-  ```
-
-### 3. 要件分析と推奨技術スタックの生成
-
-- **システム特性の分析**: アプリケーションタイプ（SPA/SSR等）、非機能要件（パフォーマンス/セキュリティ）、ドメイン複雑度を分析する。
-- **推奨案の作成**: 以下のレイヤーごとに推奨技術を選定する。
-  1. フロントエンド
-  2. バックエンド
-  3. データベース
-  4. インフラ・CI/CD
-  5. 監視・テスト
-
-- **推奨案の提示**:
-  - 「要件分析の結果、以下の技術スタックを推奨します：」
-  - 各技術について「推奨理由」と「代替案」を提示する。
-
-### 4. 詳細インタビューと選定
-
-ユーザーからのフィードバックを受け、各レイヤーについて詳細を確認する。
-
-- **フロントエンド**: フレームワーク（React/Vue等）、TypeScript利用、状態管理、スタイリング。
-- **バックエンド**: 言語、フレームワーク、APIスタイル（REST/GraphQL）。
-- **データベース**: RDBMS/NoSQL、ORM、マイグレーション戦略。
-- **インフラ**: クラウド/PaaS、コンテナ化（Docker）、IaC。
-- **開発ツール**: リンター/フォーマッター、テストツール、CI/CD。
-
-### 5. ドキュメント作成
-
-- ヒアリング結果を `docs/project/design/01-tech-stack.md` に記入する。
-- **必須項目**:
-  - 技術名、バージョン
-  - 選定理由（要件とのマッピング）
-  - 選定タイミング（初期/中期/後期）
-
-### 6. 完了条件と構造の確認
-
-- 以下の完了条件を満たしているか、コマンドとチェックリストで確認してください：
-
-  1. **構造確認**:
-
-     ```bash
-     # フロントエンドセクションの確認
-     grep "### フロントエンド" docs/project/design/01-tech-stack.md && echo "OK" || echo "MISSING: Frontend section"
-     # バックエンドセクションの確認
-     grep "### バックエンド" docs/project/design/01-tech-stack.md && echo "OK" || echo "MISSING: Backend section"
-     # 技術選定理由の確認（メモ欄など）
-     grep "|" docs/project/design/01-tech-stack.md | head -n 5
-     ```
-
-  2. **チェックリスト**:
-     - [ ] `docs/project/design/01-tech-stack.md` が作成されている
-     - [ ] 主要なレイヤー（FE, BE, DB, Infra）の技術が選定されている
-     - [ ] 選定理由が明確に記載されている
-
-### 7. Git への追加（オプション）
-
-- ユーザーに確認：「作成した技術スタックドキュメントを Git に追加しますか？」
-- 「はい」の場合、以下を実行：
-
-  ```bash
-  git add docs/project/design/01-tech-stack.md
-  git status
-  ```
-
-- 推奨コミットメッセージ：
-
-  ```
-  docs: 技術スタック選定ドキュメントの作成
-
-  - フロントエンド、バックエンド、インフラ等の技術選定を定義
-  - 選定理由と導入フェーズを明記
-  ```
-
-## 完了条件
-
-- `docs/project/design/01-tech-stack.md` が作成されている。
-- すべてのレイヤーについて技術選定が完了している（または「保留」として記録されている）。
-- 選定理由とバージョンが明確になっている。
-- ユーザーが内容を承認している。
-
-## エスカレーション
-
-- ユーザーが決められない場合：
-  - 「要件に基づき、最も標準的でリスクの少ない[技術名]を仮採用とし、実装フェーズで再評価しませんか？」と提案する。
-- コストや学習コストの懸念がある場合：
-  - 「初期フェーズは慣れた技術（[技術名]）を採用し、複雑な要件が出てきた段階で移行を検討しましょう。」と提案する。
+---
+name: a-007-define-tech-stack
+description: 要件とドメインモデルを踏まえて推奨技術スタックを提案し、対話で最終確定する。ドメイン設計完了後、実装技術を選定する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineTechStack (a-007)
+
+## 目的
+
+- 既存の要件ドキュメント（システム概要、非機能要件、ドメインモデル）を分析し、適合する技術スタックを推奨する。
+- 推奨案を提示した上で、ユーザーと詳細なインタビューを行い、すべての技術選定を明確化する。
+- 技術選定の理由、バージョン、選定タイミング（初期/中期/後期/随時）を明確に記録する。
+
+## 前提
+
+- `docs/project/requirements/` 配下のドキュメントが作成されていること。
+- `docs/project/domain/` 配下のドキュメントが作成されていること。
+- `docs/project/design/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+```bash
+ls -la docs/project/design/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+要件ドキュメント（`01-system-overview.md`, `03-features-planned.md`, `04-non-functional-requirements.md`）とドメインモデル（`01-domain-model.md`）を読み込む。
+
+### 2. テンプレートの準備
+
+```bash
+SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
+cp "$SCRIPT_DIR/templates/project/04-design/01-tech-stack.md" "docs/project/design/01-tech-stack.md"
+```
+
+### 3. 要件分析と推奨技術スタックの生成
+
+- **システム特性の分析**: アプリケーションタイプ（SPA/SSR 等）、非機能要件、ドメイン複雑度
+- **レイヤー別推奨**: フロントエンド / バックエンド / データベース / インフラ・CI/CD / 監視・テスト
+- **提示形式**: 各技術に「推奨理由」と「代替案」を付ける
+
+提案フォーマットと各層の候補一覧は [examples/stack-interview.md](examples/stack-interview.md#推奨案提示フォーマット) を参照。
+
+### 4. 詳細インタビューと選定
+
+フィードバックを受けてレイヤーごとに詳細確認する。各レイヤーの具体的な質問項目は [examples/stack-interview.md](examples/stack-interview.md#レイヤー別インタビュー項目) を参照。
+
+- フロントエンド: フレームワーク、TypeScript、状態管理、スタイリング
+- バックエンド: 言語、フレームワーク、API スタイル
+- データベース: RDBMS/NoSQL、ORM、マイグレーション
+- インフラ: クラウド、コンテナ、IaC
+- 開発ツール: リンター、テスト、CI/CD
+
+### 5. ドキュメント作成
+
+ヒアリング結果を `docs/project/design/01-tech-stack.md` に記入する。必須項目:
+
+- 技術名、バージョン
+- 選定理由（要件とのマッピング）
+- 選定タイミング（初期/中期/後期/随時）
+
+記入例は [examples/stack-interview.md](examples/stack-interview.md#記入例表形式) を参照。
+
+### 6. 構造チェック
+
+```bash
+grep "### フロントエンド" docs/project/design/01-tech-stack.md \
+  && grep "### バックエンド" docs/project/design/01-tech-stack.md \
+  && echo "OK" || echo "MISSING SECTION"
+```
+
+詳細チェックリストは [reference/structure-check.md](reference/structure-check.md#チェックリスト) を参照。
+
+### 7. Git への追加（任意）
+
+```bash
+git add docs/project/design/01-tech-stack.md
+git commit -m "docs: 技術スタック選定ドキュメントの作成"
+```
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
+
+## 完了条件
+
+- `docs/project/design/01-tech-stack.md` が作成されている。
+- すべてのレイヤーについて技術選定が完了している（または「保留」として記録されている）。
+- 選定理由とバージョンが明確になっている。
+- ユーザーが内容を承認している。
+
+## エスカレーション
+
+- **ユーザーが決められない**: 「要件に基づき、最も標準的でリスクの少ない [技術名] を仮採用とし、実装フェーズで再評価しませんか？」
+- **コスト・学習コストの懸念**: 「初期フェーズは慣れた技術（[技術名]）を採用し、複雑要件が出てから移行検討しましょう。」
+- 詳細応答例は [reference/structure-check.md](reference/structure-check.md#エスカレーション時の推奨応答) を参照。
+
+## 参考
+
+- [examples/stack-interview.md](examples/stack-interview.md) — 推奨案フォーマット、レイヤー別インタビュー項目、選定タイミング区分、記入例
+- [reference/structure-check.md](reference/structure-check.md) — 構造確認コマンド、チェックリスト、レビュー質問、Git 追加例

package/skills/a-007-define-tech-stack/examples/stack-interview.md

@@ -0,0 +1,83 @@
+# 推奨スタックとインタビュー項目
+
+SKILL.md 手順3〜4 で使用する提案テンプレートと詳細ヒアリング項目。
+
+## 推奨案提示フォーマット
+
+```markdown
+### 推奨技術スタック
+
+**フロントエンド**: React 18 + TypeScript 5 + Vite
+- 推奨理由: SPA 要件、エコシステム、TypeScript による型安全性
+- 代替案: Vue 3 + Nuxt（SSR が必要な場合）
+
+**バックエンド**: Node.js 20 + NestJS + TypeScript
+- 推奨理由: FE と言語統一、DDD 志向のモジュール構成が標準装備
+- 代替案: Go + Gin（高スループットが必要な場合）
+
+**データベース**: PostgreSQL 16 + Prisma
+- 推奨理由: リレーショナルデータ、JSON 型、強い整合性
+- 代替案: MySQL 8（既存資産がある場合）
+```
+
+## レイヤー別インタビュー項目
+
+### フロントエンド
+
+- フレームワーク: React / Vue / Svelte / SolidJS
+- レンダリング: SPA / SSR / SSG / Islands
+- TypeScript 利用の有無
+- 状態管理: React Query / Zustand / Redux Toolkit / Pinia
+- スタイリング: Tailwind / CSS Modules / styled-components
+
+### バックエンド
+
+- 言語: TypeScript / Go / Python / Rust / Kotlin
+- フレームワーク: NestJS / Fastify / Gin / FastAPI / Spring Boot
+- API スタイル: REST / GraphQL / gRPC / tRPC
+- バリデーション: Zod / class-validator / Pydantic
+
+### データベース
+
+- 種別: RDBMS（PostgreSQL / MySQL）/ NoSQL（MongoDB / DynamoDB）
+- ORM / クエリビルダー: Prisma / TypeORM / Drizzle / sqlc
+- マイグレーション戦略: 自動生成 / 手書き
+
+### インフラ・CI/CD
+
+- クラウド: AWS / GCP / Azure / Cloudflare / Vercel
+- コンテナ: Docker / Kubernetes / ECS / Cloud Run
+- IaC: Terraform / Pulumi / CDK
+- CI/CD: GitHub Actions / GitLab CI / CircleCI
+
+### 監視・テスト
+
+- ログ/メトリクス: Datadog / New Relic / Grafana + Prometheus
+- エラートラッキング: Sentry
+- テスト: Vitest / Jest / Playwright / Cypress
+- リンター: ESLint + Prettier / Biome
+
+## 選定タイミング区分
+
+- **初期**: MVP 構築時点から導入
+- **中期**: ユーザー増加に合わせて導入
+- **後期**: スケール・運用安定化で導入
+- **随時**: 必要に応じて導入
+
+## 記入例（表形式）
+
+| 層 | 技術 | バージョン | 選定理由 | タイミング |
+|:--|:--|:--|:--|:--|
+| FE | React | 18.x | SPA・エコシステム | 初期 |
+| BE | NestJS | 10.x | DDD 構成 | 初期 |
+| DB | PostgreSQL | 16.x | 整合性 | 初期 |
+| 監視 | Datadog | - | 統合監視 | 中期 |
+
+## コミットメッセージ例
+
+```text
+docs: 技術スタック選定ドキュメントの作成
+
+- フロントエンド、バックエンド、インフラ等の技術選定を定義
+- 選定理由と導入フェーズを明記
+```

package/skills/a-007-define-tech-stack/reference/structure-check.md

@@ -0,0 +1,51 @@
+# 構造チェックとレビュー観点
+
+SKILL.md 手順6〜7 で使う確認コマンドとレビュー観点。
+
+## セクション存在確認
+
+```bash
+# フロントエンドセクションの確認
+grep "### フロントエンド" docs/project/design/01-tech-stack.md && echo "OK" || echo "MISSING: Frontend section"
+# バックエンドセクションの確認
+grep "### バックエンド" docs/project/design/01-tech-stack.md && echo "OK" || echo "MISSING: Backend section"
+# 技術選定理由の確認（表形式）
+grep "|" docs/project/design/01-tech-stack.md | head -n 5
+```
+
+## チェックリスト
+
+- [ ] `docs/project/design/01-tech-stack.md` が作成されている
+- [ ] 主要レイヤー（FE, BE, DB, Infra, 監視/テスト）の技術が選定されている
+- [ ] 各技術にバージョンが記載されている
+- [ ] 選定理由が要件とマッピングされている
+- [ ] 選定タイミング（初期/中期/後期/随時）が明記されている
+- [ ] 保留項目は「保留」として記録されている
+
+## レビュー確認質問
+
+- 「各技術の選定理由は要件に基づいていますか？」
+- 「チームの習熟度に対して無理のない選定ですか？」
+- 「バージョンは LTS や安定版が選ばれていますか？」
+- 「監視・テスト戦略も含まれていますか？」
+
+## エスカレーション時の推奨応答
+
+- **ユーザーが決められない**: 「最も標準的でリスクの少ない [技術名] を仮採用とし、実装フェーズで再評価しませんか？」
+- **コスト・学習コストの懸念**: 「初期フェーズは慣れた技術（[技術名]）を採用し、複雑要件が出てから移行検討しましょう。」
+
+## Git への追加（任意）
+
+```bash
+git add docs/project/design/01-tech-stack.md
+git status
+```
+
+推奨コミットメッセージ:
+
+```text
+docs: 技術スタック選定ドキュメントの作成
+
+- フロントエンド、バックエンド、インフラ等の技術選定を定義
+- 選定理由と導入フェーズを明記
+```