spec-runner 1.1.16 → 1.1.17

package/spec-runner/templates/.claude/skills/simple-seed/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: simple-seed
+description: レイヤードアーキテクチャ / CRUD 中心のプロジェクト向け docs 正本開発フロー。ドメイン層を持たず UC・サービス層で設計する。architecture.yaml の style: layered のときに使う。
+---
+
+# simple-seed
+
+**レイヤードアーキテクチャ / CRUD 中心のプロジェクト向け**の docs 正本開発フロー参照実装（種）。
+`architecture.yaml` の `style: layered` のときに使う。DDD が必要なプロジェクトは `docs-driven-seed` を使う。
+
+**このスキルをそのまま使い続けない。`architecture-skill-development` で自プロジェクト専用スキルに育てることを前提とする。**
+
+## 全体フロー
+
+```
+Phase 1: 要件定義
+Phase 2: 概要設計（ユースケース + システム全体俯瞰）
+Phase 3: ADR（必要時のみ）
+Phase 4: 詳細設計（UC → DB・外部サービス）
+Phase 5: TDD → 実装
+```
+
+## 前提ルール
+
+- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- 詳細設計は `01_ユースケース/` `02_DB・外部サービス/` の 2 層で構成する
+- `maps_to` は必ず設定する。パス推定に頼らない
+- ユーザー承認なしに次フェーズへ進めない
+
+## Phase 1: 要件定義
+
+`architecture-definition` で完了済み。`docs/01_要件定義/` が存在することを確認して次へ進む。
+
+## Phase 2: 概要設計
+
+テンプレート: `../docs-driven-seed/templates/02_概要設計/`（ユースケース一覧・システム全体俯瞰のみ）
+
+1. 要件定義からユースケースを洗い出す（Query / Command を意識）
+2. テンプレートをコピーして `docs/02_概要設計/ユースケース一覧.md` を作る
+3. コンポーネント全体図・外部 IF を整理し `docs/02_概要設計/システム全体俯瞰.md` を作る
+4. ユーザーに確認・承認を得る
+
+### 出力
+
+```
+docs/02_概要設計/
+  ユースケース一覧.md
+  システム全体俯瞰.md
+  90_ADR/
+    全体/
+    UC/
+    DB/
+```
+
+## Phase 3: ADR（必要時のみ）
+
+1. 設計判断が必要な場合だけ ADR を作る
+2. **提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する**
+3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
+
+| 対象 | 配置先 |
+|------|--------|
+| システム横断の決定 | `90_ADR/全体/` |
+| UC フローの決定 | `90_ADR/UC/` |
+| DB・外部サービスの決定 | `90_ADR/DB/` |
+
+4. 採用案を概要設計へ反映してから次へ進む
+
+## Phase 4: 詳細設計
+
+**UC → DB・外部サービス の順に設計する。**
+
+### 4-1. ユースケース
+
+テンプレート: `templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md`
+
+```
+docs/03_詳細設計/01_ユースケース/
+  UC-{日本語名}.md
+```
+
+### 4-2. DB・外部サービス（必要時のみ）
+
+```
+docs/03_詳細設計/02_DB・外部サービス/
+  スキーマ定義.dbml
+  外部サービス.md
+```
+
+3. ユーザーに確認・承認を得る
+
+## Phase 5: TDD → 実装
+
+`test-driven-development` スキルへ移行する。
+
+### 実装完了後
+
+- `@design-reviewer` — 設計書⇔実装の整合性チェック
+- `@code-reviewer` — コーディング規約への適合チェック
+
+## 原則
+
+- **このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てることを前提とする**
+- **ドメイン層は持たない。ビジネスロジックは UC / サービス層で表現する**
+- **`maps_to` は必ず設定する。パス推定に頼らない**

package/spec-runner/templates/.claude/skills/simple-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/01_/343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/UC-{/346/227/245/346/234/254/350/252/236/345/220/215}.md

@@ -0,0 +1,53 @@
+---
+spec_runner:
+  node_id: detail.usecase.{UC名}
+  kind: detailed_design
+  depends_on:
+    - overview.use_case_list
+  maps_to:
+    - src/application/{uc_name}/
+    - tests/application/{uc_name}/
+---
+
+# UC-{UC名} 詳細設計
+
+## 概要
+
+- トリガー: {何がこのUCを呼び出すか}
+- 事前条件: {UCが成立するために必要な状態}
+- 事後条件: {UC完了後の状態}
+
+## 入出力
+
+| 種別 | 名前 | 型 | 説明 |
+|------|------|----|------|
+| 入力 | {入力名} | {型} | {説明} |
+| 出力 | {出力名} | {型} | {説明} |
+
+## 主要フロー
+
+```mermaid
+sequenceDiagram
+  {シーケンス図}
+```
+
+1. {ステップ1}
+2. {ステップ2}
+
+## 判断条件
+
+| 判断ポイント | 条件 | アクション |
+|------------|------|----------|
+| {判断ポイント} | {条件} | {アクション} |
+
+## エラーポリシー
+
+| エラーケース | 発生条件 | 対応 |
+|------------|---------|------|
+| {エラーケース} | {発生条件} | {対応} |
+
+## テスト観点
+
+- {正常系の観点}
+- {異常系の観点}
+- {境界条件の観点}

package/spec-runner/templates/.github/instructions/design-docs.instructions.md

@@ -19,7 +19,7 @@ applyTo: "docs/**"
 - **`docs/**` の全設計書に frontmatter を付ける**
 - 正本の必須項目は `spec_runner.node_id` / `spec_runner.kind` / `spec_runner.depends_on` / `spec_runner.maps_to`
 - `depends_on` はまず文字列配列でよい。依存理由が必要な場合のみオブジェクト形式を使う
-- `maps_to` には見直し対象となる `src/` / `tests/` / IaC / 設定ファイルを列挙する。**必ず設定する（空にしない）**
+- `maps_to` には見直し対象となる `src/` / `tests/` / IaC / 設定ファイルを列挙する。**必ず設定する（空にしない）**。ただし ADR は決定の記録であり実装トレーサビリティの連鎖に乗らないため `depends_on` / `maps_to` は不要。ADR の frontmatter は `node_id` と `kind` のみ
 - `modules` / `source_files` などの拡張項目を足す場合でも、`maps_to` と矛盾させない
 
 ```yaml
@@ -64,7 +64,7 @@ spec_runner:
 
 ## ADR
 
-- **ADR は必ず 3 案を比較してから採用案を決める**
+- **ADR は提案時に必ず 3 案を比較してから採用案を決める。ドキュメントには採用案と採用理由のみ記録する**
 - ADR は `docs/02_概要設計/90_ADR/{対象}/` で管理する（`全体` / `ドメイン` / `UC` / `DB`）
 - ファイル名は `mmdd-{日本語タイトル}.md`。対象はフォルダで表す
 - ADR は理由の記録であり、詳細設計の代わりにしない
@@ -72,8 +72,25 @@ spec_runner:
 
 ## 文書品質
 
-- **概要設計では「何をするか」を書き、コード片・DDL・クラス定義は持ち込まない**
-- **詳細設計ではドメインルール・UC の責務・入出力・判断条件・テスト観点を書く。コード・プロンプト本文は書かない**
+- **docs にコードを書かない。コード片・DDL・クラス定義・プロンプト本文はすべて禁止。コードは `src/` / `tests/` に書く**
+- **概要設計では「何をするか」を書き、実装の詳細は持ち込まない**
+- **詳細設計ではドメインルール・UC の責務・入出力・判断条件・テスト観点を書く**
 - **`maps_to` を唯一の src 対応として使う。パス推定に頼らない**
 - **Markdown に HTML タグ（details, summary, br など）を使わない**
+- **設計書に絵文字を使わない**
 - **`概要.md` のような汎用的な名前のファイルは作らない。内容を具体的に示す名前（`要件定義.md`、`ユースケース一覧.md`、`システム全体俯瞰.md` など）を使う**
+- **「関連ドキュメント」セクションを設計書に作らない。依存関係は frontmatter の `depends_on` で管理する**
+- **「スケジュール」セクションを設計書に作らない。進捗管理は設計書の責務ではない**
+
+## ドメインモデルとデータモデルの分離
+
+ドメインモデルとデータモデルは**別物**であり、置き場所も内容も分ける。
+
+| 種別 | 内容 | 置き場所 |
+|------|------|---------|
+| ドメインモデル | ビジネスルール・集約・値オブジェクト・不変条件 | `docs/03_詳細設計/01_ドメイン/` |
+| データモデル | DBスキーマ・テーブル定義・カラム定義・インデックス | `docs/03_詳細設計/03_DB・外部サービス/` |
+
+- **`01_ドメイン/` にDBスキーマ・テーブル定義・カラム定義を書かない**
+- **`03_DB・外部サービス/` にビジネスルール・ドメインロジックを書かない**
+- 概要設計の `ドメインモデル.md` も同様。集約と境界コンテキストの概念図であり、永続化の構造ではない

package/spec-runner/templates/.github/instructions/harness-formats.instructions.md

@@ -18,7 +18,7 @@ applyTo: "対象パス/**"   # 省略すると "**"（全ファイルに適用
 本文...
 ```
 
-- 対応する `.claude/rules/{name}.md` も同時に作成・更新する
+- `integrations` に `claude` が含まれる場合、対応する `.claude/rules/{name}.md` も作成・更新する
 
 ## agent ファイル（`.github/agents/*.agent.md`）
 
@@ -37,7 +37,7 @@ model: sonnet
 
 - `description` はトリガー型で書く（「〇〇のときに自動で呼ぶ」形式）
 - `tools` は最小権限原則。読み取りのみなら `Read, Grep, Glob`
-- 対応する `.claude/agents/{name}.md` も同時に作成・更新する
+- `integrations` に `claude` が含まれる場合、対応する `.claude/agents/{name}.md` も作成・更新する
 
 ## skill ファイル（`.github/skills/{name}/SKILL.md`）
 
@@ -52,7 +52,7 @@ description: このスキルの目的と使うタイミング（1〜2行）
 本文...
 ```
 
-- 対応する `.claude/skills/{name}/SKILL.md` も同時に作成・更新する
+- `integrations` に `claude` が含まれる場合、対応する `.claude/skills/{name}/SKILL.md` も作成・更新する
 
 ## CLAUDE.md
 
@@ -79,6 +79,9 @@ CLAUDE.md は**全会話で常にコンテキストに読み込まれる**。書
 
 ## 共通原則
 
-- `.claude/` と `.github/` は常に対で更新する（片系だけ更新しない）
+- **更新する連携先は `architecture.yaml` の `integrations` に従う**
+  - `claude` のみ → `.claude/` だけ更新する。`.github/` を作成しない
+  - `github` のみ → `.github/` だけ更新する。`.claude/` を作成しない
+  - 両方 → `.claude/` と `.github/` を対で更新する
 - `description` は「何をするか」より「**いつ・なぜ使うか**」を優先して書く
 - 新規作成時は既存ファイルを参考にフォーマットを確認してから作る

package/spec-runner/templates/.github/skills/architecture-definition/SKILL.md

@@ -6,31 +6,54 @@ description: 新規プロジェクトで docs と `.spec-runner/architecture/arc
 # architecture-definition
 
 新規プロジェクト向けの初期化フロー。
-要件定義から概要設計、architecture contract の作成までを先に固め、その後に project 専用 skill の開発へ渡す。
+要件定義・フォルダ構造の決定・architecture contract の作成までを先に固め、スキル整備を経てから概要設計へ進む。
 
 ## 全体フロー
 
 ```
 Phase 1: 要件整理
-Phase 2: 概要設計の骨格作成
+Phase 2: フォルダ構造の決定（対話）
 Phase 3: アーキテクチャ判断の明文化
 Phase 4: architecture contract 作成
-Phase 5: 次の skill へ引き渡し
+Phase 5: architecture-skill-development へ自動移行
+  └→ スキル整備完了後、プロジェクト専用スキルで概要設計へ進む
 ```
 
 ## Phase 1: 要件整理
 
+テンプレート: `.claude/skills/docs-driven-seed/templates/01_要件定義/`
+
 1. ユーザーから背景、提供価値、制約、スコープ外を確認する
-2. `docs/01_要件定義/要件定義.md` を作る
-3. frontmatter を付ける
-4. ユーザーに確認・承認を得る
+2. テンプレートをコピーして `docs/01_要件定義/要件定義.md` を作る
+3. ドメイン用語が出てきたら `docs/01_要件定義/ユビキタス言語辞書.md` に随時追記する
+4. アーキテクチャスタイルを選択する
+
+   | スタイル | 選ぶ基準 |
+   |---------|---------|
+   | `ddd` | 複雑なビジネスドメインがある。集約・境界コンテキストで設計する必要がある |
+   | `layered` | CRUD 中心またはビジネスロジックがシンプル。UC・サービス層で設計すれば十分 |
+
+5. 使用する AI 連携を確認する
+
+   | 連携 | フォルダ |
+   |------|---------|
+   | `claude` | `.claude/`（Claude Code） |
+   | `github` | `.github/`（GitHub Copilot） |
+   | 両方 | `.claude/` と `.github/` |
 
-## Phase 2: 概要設計の骨格作成
+6. ユーザーに確認・承認を得る
 
-1. `docs/02_概要設計/ユースケース一覧.md` を作る
-2. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を作る
-3. `docs/02_概要設計/システム全体俯瞰.md` を作る
-4. ユーザーに確認・承認を得る
+## Phase 2: フォルダ構造の決定
+
+対話でプロジェクトのフォルダ構造を決める。この段階で決めた構造がテンプレートの `maps_to` パスに焼き込まれるため、概要設計より前に確定させる。
+
+1. 以下をユーザーと対話しながら決める
+   - `src/` 配下のパッケージ・モジュール構成
+   - `tests/` の種別ディレクトリ構成（`unit/` / `integration/` / `e2e/` など）
+   - `docs/` の構成（デフォルトから変える場合）
+   - その他プロジェクト固有のディレクトリ（IaC、設定ファイルなど）
+2. 決定した構造を箇条書きでまとめてユーザーに提示する
+3. ユーザーに確認・承認を得る
 
 ## Phase 3: アーキテクチャ判断の明文化
 
@@ -42,7 +65,10 @@ Phase 5: 次の skill へ引き渡し
 
 1. `.spec-runner/architecture/architecture.yaml` を作る
 2. 最低限、以下を構造化する
-   - domain_structure
+   - **integrations**: Phase 1 で確認した連携（`[claude]` / `[github]` / `[claude, github]`）
+   - **style**: Phase 1 で選択したスタイル（`ddd` / `layered`）
+   - **folder_structure**: Phase 2 で決定した構造
+   - domain_structure（style: ddd のときのみ）
    - runtime_units
    - design_policy
    - testing_policy
@@ -52,12 +78,14 @@ Phase 5: 次の skill へ引き渡し
 
 Phase 4 が承認されたら、**ユーザーにコマンドを打たせずに `architecture-skill-development` を続けて開始する**。
 
-1. `architecture-skill-development` に渡す前提（docs と architecture.yaml の所在）を要約する
+1. `architecture-skill-development` に渡す前提（docs・architecture.yaml・確定済みフォルダ構造）を要約する
 2. project 専用 skill に切り出すべき反復フローを列挙する
 3. 確認なしに `architecture-skill-development` Phase 1 へ進む
+4. **スキル整備完了後、プロジェクト専用スキルを使って概要設計へ進む**
 
 ## 原則
 
-- docs を先に作る
+- フォルダ構造を概要設計より前に確定する
+- スキル整備が完了してから概要設計へ進む（テンプレートの `maps_to` を確定済み構造で焼き込むため）
 - `.spec-runner/` は補助情報として扱う
 - project 専用 skill を作る前にアーキテクチャを固める

package/spec-runner/templates/.github/skills/architecture-skill-development/SKILL.md

@@ -15,14 +15,13 @@ Phase 1: 入力の確認
 Phase 2: 反復フローの抽出
 Phase 3: skill / rule / template へ分解
 Phase 4: 基盤 skill のプロジェクト固有化
-Phase 5: Claude / Copilot テンプレートへ反映
-Phase 6: 一貫性の検証
-Phase 7: セットアップ専用 skill のアーカイブ提案
+Phase 5: 一貫性の検証
+Phase 6: セットアップ専用 skill のアーカイブ提案
 ```
 
 ## Phase 1: 入力の確認
 
-1. `docs/01_要件定義/**`, `docs/02_概要設計/**`, `docs/03_詳細設計/**` を読む
+1. `docs/01_要件定義/**` を読む
 2. `.spec-runner/architecture/architecture.yaml` を読む
 3. 固定化すべき判断と project 固有判断を切り分ける
 
@@ -41,18 +40,24 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 2. 常時守る約束は rule にする
 3. 毎回コピーする設計書は template にする
 
-### docs-driven-seed を種として使う
+### seed の選択
 
-新規開発フローの skill を作る場合は、`docs-driven-seed` を種として使う。
-`docs-driven-seed` は UC/DDD 駆動の docs 正本開発フローの参照実装であり、
-そのまま使うのではなく、**このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作る**ことを目的とする。
+`architecture.yaml` の `style` を読み、使う seed を決める。
+
+| style | 使う seed | 説明 |
+|-------|----------|------|
+| `ddd` | `docs-driven-seed` | ドメイン層（集約・値オブジェクト）を持つ DDD 向けフロー |
+| `layered` | `simple-seed` | ドメイン層を持たない UC・サービス層中心のフロー |
+
+選んだ seed の SKILL.md をコピーして、**このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作る**ことを目的とする。
 
 具体的には:
-- `.claude/skills/docs-driven-seed/SKILL.md` をコピーして、project 専用の開発 skill の土台にする
+- 選んだ seed の SKILL.md をコピーして、project 専用の開発 skill の土台にする
 - フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換える
-- 元の `docs-driven-seed` は書き換え完了後にアーカイブ候補とする（Phase 7 で提案する）
+- **Phase 1（要件定義）は architecture-definition で完了済みのため削除する**
+- 元の seed は書き換え完了後にアーカイブ候補とする（Phase 6 で提案する）
 
-ユーザーに確認・承認を得る
+4. ユーザーに確認・承認を得る
 
 ## Phase 4: 基盤 skill のプロジェクト固有化
 
@@ -88,19 +93,14 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 
 同様のプレースホルダーや汎用記述が他の skill にあれば、同じ要領で書き換える。
 
-ユーザーに確認・承認を得る
-
-## Phase 5: Claude / Copilot テンプレートへ反映
-
-1. `.claude/` と `.github/` の両方へ反映する
-2. path や naming がずれないよう対応ファイルを揃える
+5. ユーザーに確認・承認を得る
 
-## Phase 6: 一貫性の検証
+## Phase 5: 一貫性の検証
 
 1. 既存 skill / rule / agent と矛盾しないか確認する
 2. `harness-engineering` が必要な改善点を洗い出す
 
-## Phase 7: セットアップ専用 skill のアーカイブ提案
+## Phase 6: セットアップ専用 skill のアーカイブ提案
 
 セットアップ時にしか使わない skill は、開発ループに入ると不要になる。
 **ユーザーの承認を得てから** 整理する。絶対に自動で削除・移動しない。

package/spec-runner/templates/.github/skills/design-change/SKILL.md

@@ -42,6 +42,7 @@ Phase 6: TDD → 実装 → 検証
 4. ユーザーが案を決定する
 5. テンプレート `templates/90_ADR/ADRテンプレート.md` をコピーして生成する
 6. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
+7. ユーザーに確認・承認を得る
 
 ### ADR 配置ルール
 

package/spec-runner/templates/.github/skills/design-change/templates/90_ADR/ADR/343/203/206/343/203/263/343/203/227/343/203/254/343/203/274/343/203/210.md

@@ -2,9 +2,6 @@
 spec_runner:
   node_id: adr.{decision_slug}
   kind: adr
-  depends_on:
-    - overview.system_context
-  maps_to: []
 ---
 
 # {決定内容のタイトル}
@@ -21,35 +18,6 @@ spec_runner:
 | 要件 | {実現する必要があること} |
 | 制約 | {技術的・ビジネス的制約} |
 
-## 選択肢
-
-### 案1: {案1の名前}
-
-- 概要: {何をするか}
-- メリット:
-  - {メリット}
-- デメリット:
-  - {デメリット}
-- 適合性: {このプロジェクトにどう合うか}
-
-### 案2: {案2の名前}
-
-- 概要: {何をするか}
-- メリット:
-  - {メリット}
-- デメリット:
-  - {デメリット}
-- 適合性: {このプロジェクトにどう合うか}
-
-### 案3: {案3の名前}
-
-- 概要: {何をするか}
-- メリット:
-  - {メリット}
-- デメリット:
-  - {デメリット}
-- 適合性: {このプロジェクトにどう合うか}
-
 ## 決定
 
 **採用案**: {案名}

package/spec-runner/templates/.github/skills/docs-driven-seed/SKILL.md

@@ -5,8 +5,8 @@ description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジ
 
 # docs-driven-seed
 
-UC/DDD 駆動の docs 正本開発フローの**参照実装（種）**。
-プロジェクト固有のスキルに育てる前の出発点として使う。
+**DDD（ドメイン駆動設計）を採用するプロジェクト向け**の docs 正本開発フロー参照実装（種）。
+`architecture.yaml` の `style: ddd` のときに使う。レイヤード / CRUD 中心のプロジェクトは `simple-seed` を使う。
 
 **このスキルをそのまま使い続けない。`architecture-skill-development` で自プロジェクト専用スキルに育てることを前提とする。**
 
@@ -30,22 +30,7 @@ Phase 5: TDD → 実装
 
 ## Phase 1: 要件定義
 
-1. 以下をユーザーにヒアリングする
-   - 解決すべき課題・提供価値
-   - 対象ユーザー
-   - 非機能要件・スコープ外
-   - 技術・ビジネス制約
-2. `docs/01_要件定義/要件定義.md` を作る
-3. ドメイン用語が出てきたら `docs/01_要件定義/ユビキタス言語辞書.md` に随時追記する
-4. ユーザーに確認・承認を得る
-
-### 出力
-
-```
-docs/01_要件定義/
-  要件定義.md
-  ユビキタス言語辞書.md
-```
+`architecture-definition` で完了済み。`docs/01_要件定義/` が存在することを確認して次へ進む。
 
 ## Phase 2: 概要設計
 
@@ -63,6 +48,8 @@ docs/01_要件定義/
 
 ### 出力
 
+テンプレート: `templates/02_概要設計/ユースケース一覧.md` / `templates/02_概要設計/ドメインモデル.md` / `templates/02_概要設計/システム全体俯瞰.md`
+
 ```
 docs/02_概要設計/
   ユースケース一覧.md
@@ -78,7 +65,7 @@ docs/02_概要設計/
 ## Phase 3: ADR（必要時のみ）
 
 1. 設計判断が必要な場合だけ ADR を作る
-2. **必ず 3 案を比較する**
+2. **提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する**
 3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
 
 | 対象 | 配置先 |
@@ -122,7 +109,7 @@ docs/03_詳細設計/03_DB・外部サービス/
   外部サービス.md
 ```
 
-ユーザーに確認・承認を得る
+4. ユーザーに確認・承認を得る
 
 ## Phase 5: TDD → 実装
 

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/01_/350/246/201/344/273/266/345/256/232/347/276/251//343/203/246/343/203/223/343/202/255/343/202/277/343/202/271/350/250/200/350/252/236/350/276/236/346/233/270.md

@@ -0,0 +1,15 @@
+---
+spec_runner:
+  node_id: requirement.ユビキタス言語辞書
+  kind: requirement
+  depends_on:
+    - requirement.要件定義
+  maps_to:
+    - docs/03_詳細設計/01_ドメイン/
+---
+
+# ユビキタス言語辞書
+
+| 用語 | 定義 | 補足 |
+|------|------|------|
+| {用語} | {定義} | {補足} |

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/01_/350/246/201/344/273/266/345/256/232/347/276/251//350/246/201/344/273/266/345/256/232/347/276/251.md

@@ -0,0 +1,34 @@
+---
+spec_runner:
+  node_id: requirement.要件定義
+  kind: requirement
+  depends_on: []
+  maps_to:
+    - docs/02_概要設計/
+---
+
+# 要件定義
+
+## 解決すべき課題・提供価値
+
+- {課題}
+- {提供価値}
+
+## 対象ユーザー
+
+- {ユーザー種別}: {説明}
+
+## 非機能要件
+
+| 項目 | 内容 |
+|------|------|
+| {パフォーマンス} | {要件} |
+| {セキュリティ} | {要件} |
+
+## スコープ外
+
+- {スコープ外の機能・要件}
+
+## 技術・ビジネス制約
+
+- {制約}

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/202/267/343/202/271/343/203/206/343/203/240/345/205/250/344/275/223/344/277/257/347/236/260.md

@@ -0,0 +1,33 @@
+---
+spec_runner:
+  node_id: overview.system_context
+  kind: overview_design
+  depends_on:
+    - overview.domain_model
+  maps_to:
+    - src/
+---
+
+# システム全体俯瞰
+
+## コンポーネント全体図
+
+```mermaid
+graph LR
+  User([ユーザー])
+  subgraph システム
+    {フロントエンド}
+    {バックエンド}
+  end
+  Ext([{外部サービス}])
+
+  User --> {フロントエンド}
+  {フロントエンド} --> {バックエンド}
+  {バックエンド} --> Ext
+```
+
+## 外部インターフェース
+
+| 外部システム | 方向 | プロトコル | 概要 |
+|------------|------|----------|------|
+| {外部システム名} | 受信 / 送信 | {HTTP / gRPC など} | {概要} |

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/203/211/343/203/241/343/202/244/343/203/263/343/203/242/343/203/207/343/203/253.md

@@ -0,0 +1,32 @@
+---
+spec_runner:
+  node_id: overview.domain_model
+  kind: overview_design
+  depends_on:
+    - overview.use_case_list
+  maps_to:
+    - docs/03_詳細設計/01_ドメイン/
+---
+
+# ドメインモデル
+
+集約と境界コンテキストの概念モデル。DBスキーマ・永続化の詳細はここに書かない。
+
+## 境界コンテキスト
+
+```mermaid
+graph LR
+  subgraph {コンテキストA}
+    {集約A}
+  end
+  subgraph {コンテキストB}
+    {集約B}
+  end
+  {コンテキストA} -->|下流| {コンテキストB}
+```
+
+## 集約一覧
+
+| 境界コンテキスト | 集約 | 責務 |
+|----------------|------|------|
+| {コンテキスト名} | {集約名} | {責務} |

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/344/270/200/350/246/247.md

@@ -0,0 +1,15 @@
+---
+spec_runner:
+  node_id: overview.use_case_list
+  kind: overview_design
+  depends_on:
+    - requirement.要件定義
+  maps_to:
+    - docs/03_詳細設計/02_ユースケース/
+---
+
+# ユースケース一覧
+
+| UC ID | UC名 | 種別 | 概要 |
+|-------|------|------|------|
+| UC-{番号} | {UC名} | Command / Query | {概要} |