spec-runner 1.1.16 → 1.1.17

package/bin/spec-runner-installer.js

@@ -100,6 +100,55 @@ function filesEqual(a, b) {
   return bufA.equals(bufB);
 }
 
+function mergeJsonDeep(base, override) {
+  const result = { ...base };
+  for (const [key, val] of Object.entries(override)) {
+    if (Array.isArray(val) && Array.isArray(result[key])) {
+      // 配列は重複を避けてマージ
+      const existing = result[key].map((item) => JSON.stringify(item));
+      const additions = val.filter((item) => !existing.includes(JSON.stringify(item)));
+      result[key] = [...result[key], ...additions];
+    } else if (val && typeof val === "object" && result[key] && typeof result[key] === "object") {
+      result[key] = mergeJsonDeep(result[key], val);
+    } else {
+      result[key] = val;
+    }
+  }
+  return result;
+}
+
+function copySettingsJsonWithMerge(src, dest, archiveRoot) {
+  if (!exists(dest)) {
+    writeFileText(dest, readFileText(src));
+    return;
+  }
+  let existing, incoming;
+  try {
+    existing = JSON.parse(readFileText(dest));
+    incoming = JSON.parse(readFileText(src));
+  } catch {
+    // JSON パース失敗時は通常の copyFileWithPolicy にフォールバック
+    copyFileWithPolicy(src, dest, archiveRoot);
+    return;
+  }
+  const merged = mergeJsonDeep(existing, incoming);
+  if (JSON.stringify(merged) === JSON.stringify(existing)) return; // 変更なし
+  if (FORCE && archiveRoot) {
+    const ap = archivePathFor(dest, archiveRoot);
+    ensureDir(path.dirname(ap));
+    fs.copyFileSync(dest, ap);
+  }
+  writeFileText(dest, JSON.stringify(merged, null, 2) + "\n");
+}
+
+function appendToGitignore(lines, dest) {
+  let content = exists(dest) ? readFileText(dest) : "";
+  const additions = lines.filter((line) => !content.split("\n").includes(line));
+  if (additions.length === 0) return;
+  const sep = content === "" || content.endsWith("\n") ? "" : "\n";
+  writeFileText(dest, content + sep + additions.join("\n") + "\n");
+}
+
 function normalizeTarget(t) {
   if (!t) return "";
   const x = String(t).trim().toLowerCase();
@@ -247,6 +296,11 @@ function mirrorTreeTo(destRootDir, templateDir, archiveRoot) {
   walkFiles(templateDir, (srcFile) => {
     const rel = path.relative(templateDir, srcFile);
     const destFile = path.join(destRootDir, rel);
+    // settings.json は上書きではなくマージ
+    if (path.basename(srcFile) === "settings.json") {
+      copySettingsJsonWithMerge(srcFile, destFile, archiveRoot);
+      return;
+    }
     copyFileWithPolicy(srcFile, destFile, archiveRoot);
   });
 }
@@ -381,6 +435,15 @@ function main() {
     copyFileWithPolicy(claudeMdSrc, path.join(CWD, "CLAUDE.md"), archiveRoot);
   }
 
+  // .spec-runner/scripts を導入（target によらず常に配置）
+  const specRunnerTemplateDir = path.join(TEMPLATE_ROOT, ".spec-runner");
+  if (exists(specRunnerTemplateDir)) {
+    mirrorTreeTo(path.join(CWD, ".spec-runner"), specRunnerTemplateDir, archiveRoot);
+  }
+
+  // .gitignore に scan キャッシュを追記
+  appendToGitignore([".spec-runner/scan/"], path.join(CWD, ".gitignore"));
+
   console.log("");
   if (target === "claude" || target === "both") {
     mirrorTreeTo(DEST_CLAUDE_DIR, CLAUDE_TEMPLATE_DIR, archiveRoot);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spec-runner",
-  "version": "1.1.16",
+  "version": "1.1.17",
   "description": "docs を正本にした開発運用ハーネスを Claude / Copilot に導入する",
   "license": "MIT",
   "bin": {

package/spec-runner/templates/.claude/rules/design-docs.md

@@ -20,7 +20,7 @@ paths: ["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
@@ -65,7 +65,7 @@ spec_runner:
 
 ## ADR
 
-- **ADR は必ず 3 案を比較してから採用案を決める**
+- **ADR は提案時に必ず 3 案を比較してから採用案を決める。ドキュメントには採用案と採用理由のみ記録する**
 - ADR は `docs/02_概要設計/90_ADR/{対象}/` で管理する（`全体` / `ドメイン` / `UC` / `DB`）
 - ファイル名は `mmdd-{日本語タイトル}.md`。対象はフォルダで表す
 - ADR は理由の記録であり、詳細設計の代わりにしない
@@ -73,8 +73,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/.claude/rules/harness-formats.md

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

package/spec-runner/templates/.claude/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/.claude/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/.claude/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/.claude/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/.claude/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/.claude/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/.claude/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/.claude/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/.claude/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/.claude/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 | {概要} |

package/spec-runner/templates/.claude/skills/docs-driven-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/01_/343/203/211/343/203/241/343/202/244/343/203/263/{/343/203/211/343/203/241/343/202/244/343/203/263/345/220/215}.md

@@ -17,6 +17,23 @@ spec_runner:
 
 ## 集約
 
+```mermaid
+classDiagram
+  class {集約ルート} {
+    +{ID型} id
+    +{値オブジェクト} {フィールド名}
+    +{操作}() {戻り値型}
+  }
+  class {エンティティ} {
+    +{ID型} id
+  }
+  class {値オブジェクト} {
+    +{型} {フィールド名}
+  }
+  {集約ルート} "1" --> "0..*" {エンティティ} : 含む
+  {集約ルート} --> {値オブジェクト} : 持つ
+```
+
 | 集約 | 責務 | ルートエンティティ |
 |------|------|----------------|
 | {集約名} | {責務} | {ルートエンティティ名} |