yodogawa 2.1.1 → 2.1.3

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

@@ -1,99 +1,96 @@
----
-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 追加例
+---
+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. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-003-create-scenarios/`）を起点に、相対パス `../../templates/project/02-behavior/01-scenarios.md` を Read で読み込み、その内容を `docs/project/02-behavior/01-scenarios.md` へ Write する。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/02-behavior/`）が無ければ作成する。
+
+### 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-004-define-domain-model/SKILL.md

@@ -1,99 +1,98 @@
----
-name: a-004-define-domain-model
-description: Event Storming 形式でドメインモデル（イベント・コマンド・集約）を定義し、ユビキタス言語を整備する。シナリオ作成後、ドメイン設計を開始する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineDomainModel (a-004)
-
-## 目的
-
-- Event Storming 形式でドメインモデルを体系的に定義する。
-- ドメインモデルを作成しながら、ユビキタス言語（共通用語）を並行して洗練させる。
-- Bounded Context を特定し、Actors / Commands / Events / Policies / Aggregates を明確化する。
-
-## 前提
-
-- `docs/project/02-behavior/01-scenarios.md` が作成されている（`/a-003-create-scenarios` 実行済み）
-- `docs/project/03-domain/` ディレクトリが存在（なければ `/a-001-setup-doc-structure`）
-- ドメインエキスパートと協力できる
-
-## 手順
-
-### 1. ディレクトリと前提条件の確認
-
-```bash
-ls -la docs/project/03-domain/ 2>/dev/null || echo "ディレクトリが存在しません"
-```
-
-存在しなければ `/a-001-setup-doc-structure` を促す。`docs/project/02-behavior/01-scenarios.md` を読み込み内容確認。
-
-### 2. テンプレートの準備
-
-```bash
-SCRIPT_DIR=$(for d in .claude .agents; do [ -d "$d" ] && echo "$d" && break; done)
-cp "$SCRIPT_DIR/templates/project/03-domain/01-domain-model.md" "docs/project/03-domain/01-domain-model.md"
-cp "$SCRIPT_DIR/templates/project/03-domain/02-ubiquitous-language.md" "docs/project/03-domain/02-ubiquitous-language.md"
-```
-
-### 3. Bounded Context の特定
-
-シナリオとユーザーストーリーから Bounded Context を提案し、戦略的分類（Core / Supporting / Generic）を確認。詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#bounded-context-の特定) を参照。
-
-### 4. 各 Bounded Context のドメインモデル定義
-
-各 Context について以下を定義し、`01-domain-model.md` を更新。新しい用語が登場するたびに `02-ubiquitous-language.md` にも追記。
-
-- 概要とアクター
-- コマンド / イベント / ポリシー（Event Storming）
-- 集約 / Read Models / External Systems
-
-各要素の詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#各-context-の定義項目) を参照。
-
-### 5. ユビキタス言語の洗練
-
-`02-ubiquitous-language.md` を見直し、重複・曖昧さ・禁止用語を排除。観点は [reference/event-storming-guide.md](reference/event-storming-guide.md#ユビキタス言語の洗練観点) を参照。
-
-### 6. Context Map の定義
-
-Context 間の関係性（Customer-Supplier, Shared Kernel 等）を Mermaid 図で定義。関係パターン: [reference/event-storming-guide.md](reference/event-storming-guide.md#context-map-の関係性)
-
-### 7. レビューと確認
-
-作成したドキュメントを提示し、ビジネス用語の正確性 / Aggregate 境界 / ユビキタス言語定義を確認。
-
-### 8. 完了条件と構造の確認
-
-構造確認コマンドは [reference/event-storming-guide.md](reference/event-storming-guide.md#構造確認コマンド) を参照。
-
-チェックリスト:
-
-- [ ] `01-domain-model.md` に主要な Event Storming 要素が含まれている
-- [ ] `02-ubiquitous-language.md` の用語が定義されている
-- [ ] ドメインモデルとユビキタス言語の整合性が取れている
-
-### 9. Git への追加（オプション）
-
-```bash
-git add docs/project/03-domain/
-git status
-```
-
-コミットメッセージ: [reference/event-storming-guide.md](reference/event-storming-guide.md#git-コミットメッセージ)
-
-## 完了条件
-
-- `docs/project/03-domain/01-domain-model.md` と `02-ubiquitous-language.md` が作成されている
-- 各 Bounded Context の主要ドメイン要素（Aggregates, Commands, Events）が定義されている
-- ドメインモデルで使用される用語がユビキタス言語として定義されている
-- ユーザーが内容を承認している
-
-## エスカレーション
-
-- **シナリオが不足**: 「`/a-003-create-scenarios` に戻ってシナリオを充実させましょう。」
-- **Bounded Context の境界が不明確**: 「暫定的な境界を設定し、実装を進めながら見直す方針で進めませんか？」
-
-## 参考
-
-- [reference/event-storming-guide.md](reference/event-storming-guide.md) — Event Storming の観点、Context Map パターン、構造確認コマンド
+---
+name: a-004-define-domain-model
+description: Event Storming 形式でドメインモデル（イベント・コマンド・集約）を定義し、ユビキタス言語を整備する。シナリオ作成後、ドメイン設計を開始する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineDomainModel (a-004)
+
+## 目的
+
+- Event Storming 形式でドメインモデルを体系的に定義する。
+- ドメインモデルを作成しながら、ユビキタス言語（共通用語）を並行して洗練させる。
+- Bounded Context を特定し、Actors / Commands / Events / Policies / Aggregates を明確化する。
+
+## 前提
+
+- `docs/project/02-behavior/01-scenarios.md` が作成されている（`/a-003-create-scenarios` 実行済み）
+- `docs/project/03-domain/` ディレクトリが存在（なければ `/a-001-setup-doc-structure`）
+- ドメインエキスパートと協力できる
+
+## 手順
+
+### 1. ディレクトリと前提条件の確認
+
+```bash
+ls -la docs/project/03-domain/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+存在しなければ `/a-001-setup-doc-structure` を促す。`docs/project/02-behavior/01-scenarios.md` を読み込み内容確認。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`skills/a-004-define-domain-model/`）を起点に、`docs/project/03-domain/` へ次の 2 ファイルを Read→Write する（FOR EACH）。出力先が既に存在する場合は上書きせずスキップして報告する（冪等）。出力先ディレクトリ（`docs/project/03-domain/`）が無ければ作成する。
+
+- `../../templates/project/03-domain/01-domain-model.md` → `docs/project/03-domain/01-domain-model.md`
+- `../../templates/project/03-domain/02-ubiquitous-language.md` → `docs/project/03-domain/02-ubiquitous-language.md`
+
+### 3. Bounded Context の特定
+
+シナリオとユーザーストーリーから Bounded Context を提案し、戦略的分類（Core / Supporting / Generic）を確認。詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#bounded-context-の特定) を参照。
+
+### 4. 各 Bounded Context のドメインモデル定義
+
+各 Context について以下を定義し、`01-domain-model.md` を更新。新しい用語が登場するたびに `02-ubiquitous-language.md` にも追記。
+
+- 概要とアクター
+- コマンド / イベント / ポリシー（Event Storming）
+- 集約 / Read Models / External Systems
+
+各要素の詳細は [reference/event-storming-guide.md](reference/event-storming-guide.md#各-context-の定義項目) を参照。
+
+### 5. ユビキタス言語の洗練
+
+`02-ubiquitous-language.md` を見直し、重複・曖昧さ・禁止用語を排除。観点は [reference/event-storming-guide.md](reference/event-storming-guide.md#ユビキタス言語の洗練観点) を参照。
+
+### 6. Context Map の定義
+
+Context 間の関係性（Customer-Supplier, Shared Kernel 等）を Mermaid 図で定義。関係パターン: [reference/event-storming-guide.md](reference/event-storming-guide.md#context-map-の関係性)
+
+### 7. レビューと確認
+
+作成したドキュメントを提示し、ビジネス用語の正確性 / Aggregate 境界 / ユビキタス言語定義を確認。
+
+### 8. 完了条件と構造の確認
+
+構造確認コマンドは [reference/event-storming-guide.md](reference/event-storming-guide.md#構造確認コマンド) を参照。
+
+チェックリスト:
+
+- [ ] `01-domain-model.md` に主要な Event Storming 要素が含まれている
+- [ ] `02-ubiquitous-language.md` の用語が定義されている
+- [ ] ドメインモデルとユビキタス言語の整合性が取れている
+
+### 9. Git への追加（オプション）
+
+```bash
+git add docs/project/03-domain/
+git status
+```
+
+コミットメッセージ: [reference/event-storming-guide.md](reference/event-storming-guide.md#git-コミットメッセージ)
+
+## 完了条件
+
+- `docs/project/03-domain/01-domain-model.md` と `02-ubiquitous-language.md` が作成されている
+- 各 Bounded Context の主要ドメイン要素（Aggregates, Commands, Events）が定義されている
+- ドメインモデルで使用される用語がユビキタス言語として定義されている
+- ユーザーが内容を承認している
+
+## エスカレーション
+
+- **シナリオが不足**: 「`/a-003-create-scenarios` に戻ってシナリオを充実させましょう。」
+- **Bounded Context の境界が不明確**: 「暫定的な境界を設定し、実装を進めながら見直す方針で進めませんか？」
+
+## 参考
+
+- [reference/event-storming-guide.md](reference/event-storming-guide.md) — Event Storming の観点、Context Map パターン、構造確認コマンド

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

@@ -1,102 +1,99 @@
----
-name: a-007-define-tech-stack
-description: 要件とドメインモデルを踏まえて推奨技術スタックを提案し、対話で最終確定する。ドメイン設計完了後、実装技術を選定する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# DefineTechStack (a-007)
-
-## 目的
-
-- 既存の要件ドキュメント（システム概要、非機能要件、ドメインモデル）を分析し、適合する技術スタックを推奨する。
-- 推奨案を提示した上で、ユーザーと詳細なインタビューを行い、すべての技術選定を明確化する。
-- 技術選定の理由、バージョン、選定タイミング（初期/中期/後期/随時）を明確に記録する。
-
-## 前提
-
-- `docs/project/01-requirements/` 配下のドキュメントが作成されていること。
-- `docs/project/03-domain/` 配下のドキュメントが作成されていること。
-- `docs/project/04-design/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
-
-## 手順
-
-### 1. ドキュメントと前提条件の確認
-
-```bash
-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`）を読み込む。
-
-### 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"
-```
-
-### 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/04-design/01-tech-stack.md` に記入する。必須項目:
-
-- 技術名、バージョン
-- 選定理由（要件とのマッピング）
-- 選定タイミング（初期/中期/後期/随時）
-
-記入例は [examples/stack-interview.md](examples/stack-interview.md#記入例表形式) を参照。
-
-### 6. 構造チェック
-
-```bash
-grep "### フロントエンド" docs/project/04-design/01-tech-stack.md \
-  && grep "### バックエンド" docs/project/04-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/04-design/01-tech-stack.md
-git commit -m "docs: 技術スタック選定ドキュメントの作成"
-```
-
-詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
-
-## 完了条件
-
-- `docs/project/04-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 追加例
+---
+name: a-007-define-tech-stack
+description: 要件とドメインモデルを踏まえて推奨技術スタックを提案し、対話で最終確定する。ドメイン設計完了後、実装技術を選定する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# DefineTechStack (a-007)
+
+## 目的
+
+- 既存の要件ドキュメント（システム概要、非機能要件、ドメインモデル）を分析し、適合する技術スタックを推奨する。
+- 推奨案を提示した上で、ユーザーと詳細なインタビューを行い、すべての技術選定を明確化する。
+- 技術選定の理由、バージョン、選定タイミング（初期/中期/後期/随時）を明確に記録する。
+
+## 前提
+
+- `docs/project/01-requirements/` 配下のドキュメントが作成されていること。
+- `docs/project/03-domain/` 配下のドキュメントが作成されていること。
+- `docs/project/04-design/` ディレクトリが存在すること（未作成なら `/a-001-setup-doc-structure`）。
+
+## 手順
+
+### 1. ドキュメントと前提条件の確認
+
+```bash
+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`）を読み込む。
+
+### 2. テンプレートの準備
+
+このスキルの配置ディレクトリ（`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 等）、非機能要件、ドメイン複雑度
+- **レイヤー別推奨**: フロントエンド / バックエンド / データベース / インフラ・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/04-design/01-tech-stack.md` に記入する。必須項目:
+
+- 技術名、バージョン
+- 選定理由（要件とのマッピング）
+- 選定タイミング（初期/中期/後期/随時）
+
+記入例は [examples/stack-interview.md](examples/stack-interview.md#記入例表形式) を参照。
+
+### 6. 構造チェック
+
+```bash
+grep "### フロントエンド" docs/project/04-design/01-tech-stack.md \
+  && grep "### バックエンド" docs/project/04-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/04-design/01-tech-stack.md
+git commit -m "docs: 技術スタック選定ドキュメントの作成"
+```
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加任意) を参照。
+
+## 完了条件
+
+- `docs/project/04-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 追加例