spec-runner 1.1.16 → 1.1.18

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.18",
   "description": "docs を正本にした開発運用ハーネスを Claude / Copilot に導入する",
   "license": "MIT",
   "bin": {

package/spec-runner/templates/.claude/agents/code-reviewer.md

@@ -5,9 +5,9 @@ tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
 
-# コーディング規約チェックエージェント
+# コーディング規約チェックエージェント（読み取り専用）
 
-変更されたコードをコーディング規約と照合し、違反を報告する。
+変更されたコードをコーディング規約と照合し、違反を報告する。変更ファイルのみが対象。
 
 ## 手順
 
@@ -31,9 +31,3 @@ model: sonnet
 ### 問題なし
 - [チェック済みファイル一覧]
 ```
-
-## 注意事項
-
-- 読み取り専用（コードの変更は行わない）
-- 日本語で報告する
-- 変更されたファイルのみをチェック対象とする（既存コードの規約違反は指摘しない）

package/spec-runner/templates/.claude/agents/design-reviewer.md

@@ -5,17 +5,16 @@ tools: Read, Grep, Glob
 model: sonnet
 ---
 
-# 設計書⇔実装 整合性チェックエージェント
+# 設計書⇔実装 整合性チェックエージェント（読み取り専用）
 
-docs/ 配下の設計書と src/ 配下の実装コードを突合し、乖離を報告する。
+`docs/` の設計書と `src/` の実装コードを突合し、乖離を報告する。`maps_to` を唯一の参照先とする（パス推定は行わない）。
 
 ## 手順
 
 1. `docs/` 配下の設計書ファイルを一覧取得する
 2. 各設計書の frontmatter を読み、`spec_runner.node_id` / `kind` / `depends_on` / `maps_to` を確認する
-3. `docs/02_概要設計/**` の各ファイルを読む。ユースケース・責務・外部 IF が実装に反映されているか確認するために、`maps_to` から対応する `src/` ファイルを特定して実際に読んで比較する
-4. `docs/03_詳細設計/**` の各ファイルを読む。`maps_to` に列挙された `src/` / `tests/` ファイルを**実際に読み**、責務・入出力・判断条件・テスト観点を設計書と行レベルで比較する
-   - `maps_to` が空または未設定の場合はフロントマターの問題として報告する（パス推定は行わない）
+3. `docs/02_概要設計/**` の各ファイルを読む。`maps_to` から対応する `src/` ファイルを特定して読み、ユースケース・責務・外部 IF が実装に反映されているか比較する
+4. `docs/03_詳細設計/**` の各ファイルを読む。`maps_to` に列挙された `src/` / `tests/` ファイルを実際に読み、責務・入出力・判断条件・テスト観点を設計書と行レベルで比較する（`maps_to` が空または未設定の場合は frontmatter の問題として報告する）
 5. 乖離を報告する
 
 ## チェック項目
@@ -44,7 +43,7 @@ docs/ 配下の設計書と src/ 配下の実装コードを突合し、乖離
 ```
 ## 整合性チェック結果
 
-### frontmatterの問題
+### frontmatter の問題
 - [ファイル]: [問題内容]
 
 ### 一致（問題なし）
@@ -57,9 +56,4 @@ docs/ 配下の設計書と src/ 配下の実装コードを突合し、乖離
 - 推奨対応: 設計書を更新 / 実装を修正
 ```
 
-## 注意事項
-
-- 読み取り専用（コードや設計書の変更は行わない）
-- 日本語で報告する
-- ADR はコードと 1 対 1 の突合対象ではないが、配置先と反映有無は確認する
-- `maps_to` を唯一の参照先とする。パス推定は行わない
+ADR はコードと 1 対 1 の突合対象ではないが、配置先と反映有無は確認する。

package/spec-runner/templates/.claude/agents/impact-analyzer.md

@@ -1,13 +1,13 @@
 ---
 name: impact-analyzer
-description: design-change で影響範囲を調査するときに呼ぶ。変更対象の node_id またはファイルパスを受け取り、.spec-runner/scan/graph.json のキャッシュを参照して影響ファイルを一覧化し、maps_to の参照整合性も報告する。
+description: design-change で影響範囲を調査するときに呼ぶ。node_id から連鎖する影響ファイルを一覧化し、maps_to の整合性を報告する。
 tools: Bash
 model: sonnet
 ---
 
-# 影響範囲分析エージェント
+# 影響範囲分析エージェント（読み取り専用）
 
-`.spec-runner/scan/graph.json`（`scan.js` が生成するキャッシュ）を読み、変更対象の node_id から連鎖する影響ファイルを一覧化する。
+`graph.json`（`scan.js` が生成するキャッシュ）を読み、変更対象の node_id から連鎖する影響ファイルを一覧化する。
 
 ## 入力
 
@@ -67,9 +67,4 @@ console.log(JSON.stringify({ node, direct: direct.map(n => ({id: n, ...g.nodes[n
 - [ファイルパス] — 理由: {理由}
 ```
 
-## 注意事項
-
-- 読み取り専用（ファイルの変更は行わない）
-- 日本語で報告する
-- graph.json が存在しない場合は scan.js を実行してから進む
-- 影響ファイルが多い場合は kind 別にグループ化する
+影響ファイルが多い場合は kind 別にグループ化する。

package/spec-runner/templates/.claude/agents/test-runner.md

@@ -5,17 +5,19 @@ tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
 
-# テスト実行エージェント
+# テスト実行エージェント（読み取り専用）
 
-テストをDocker環境で実行し、結果を分析する。
+> このファイルはテンプレートです。`architecture-skill-development` でプロジェクトのテスト実行コマンドに書き換えてください。
+
+テストを実行し、結果を分析する。コードは修正しない。
 
 ## 手順
 
 1. `git diff --name-only` で変更ファイルを確認する
 2. 変更ファイルに対応するテストファイルを特定する（`tests/` 配下の同構造）
 3. テストを実行する:
-   - 対象テストが明確な場合: `docker compose run --rm test pytest tests/path/to/test_file.py -v`
-   - 全体実行が必要な場合: `docker compose run --rm test pytest -v`
+   - 対象テストが明確な場合: `<your-test-command> <test-file> -v`
+   - 全体実行が必要な場合: `<your-test-command> -v`
 4. 結果を分析する
 
 ## 失敗時の分析
@@ -26,9 +28,3 @@ model: sonnet
 - **エラー内容**: アサーションエラーやスタックトレースの要約
 - **原因の推定**: 変更内容との関連性を分析
 - **修正案**: 具体的なコード修正の提案（コード例を含める）
-
-## 注意事項
-
-- テスト実行は必ず `docker compose run --rm test pytest` で行う
-- コードの修正は行わない（分析と提案のみ）
-- 日本語で報告する

package/spec-runner/templates/.claude/rules/coding.md

@@ -1,93 +1,48 @@
 ---
-description: コーディング規約（命名規則・型・コメント・テスト構成）
+description: コーディング規約（命名規則・コメント・テスト構成）
 paths: ["src/**", "tests/**"]
 ---
 
 # コーディング規約
 
+> このファイルはテンプレートです。`architecture-skill-development` で言語・フレームワーク・プロジェクト構造に合わせて書き換えてください。
+
 ## 命名規則
 
+> 以下の表をプロジェクトの言語・規約に合わせて書き換える。
+
 | 対象 | 規則 | 例 |
 |------|------|-----|
-| ファイル名 | snake_case | `domain.py`, `journal_search.py` |
-| クラス名 | PascalCase | `CheckExecution`, `AccountBalance` |
-| 関数・メソッド | snake_case | `aggregate_by_account()`, `determine_severity()` |
-| 変数 | snake_case | `journal_entries`, `diff_amount` |
-| 定数 | UPPER_SNAKE_CASE | `THRESHOLD_ERROR`, `_VALID_SEVERITIES` |
-| モジュール内部定数 | _UPPER_SNAKE_CASE（先頭アンダースコア） | `_THRESHOLD_WARNING` |
-| テストクラス | Test + PascalCase | `TestDetermineSeverity` |
-| テストメソッド | test_ + snake_case（日本語不可） | `test_empty_entries_raises` |
-| ディレクトリ | snake_case | `agents/reconciliation/`, `plugins/tools/` |
-
-## コメント・docstring
+| ファイル名 | `<規則>` | `<例>` |
+| クラス名 | `<規則>` | `<例>` |
+| 関数・メソッド | `<規則>` | `<例>` |
+| 変数 | `<規則>` | `<例>` |
+| 定数 | `<規則>` | `<例>` |
+| テストクラス | `<規則>` | `<例>` |
+| テストメソッド | `<規則>` | `<例>` |
+| ディレクトリ | `<規則>` | `<例>` |
+
+## コメント
 
 - **言語**: 日本語
-- **docstring**: モジュール先頭に1行で概要を書く。関数・クラスには原則不要（名前で意図が伝わる場合）
 - **インラインコメント**: ビジネスロジックの「なぜ」を説明する場合のみ。処理内容の「何」は書かない
-- **変更履歴コメント禁止**: `# 新機能追加`, `# ここを修正`, `# v2 で変更` のような変更経緯はコードに書かない。git の commit message で管理する
+- **変更履歴コメント禁止**: 変更経緯はコードに書かない。git の commit message で管理する
 
-```python
-# 良い例
-# 貸方は負の値として扱う（借方 - 貸方 = 残高）
-balances[credit_key] = balances.get(credit_key, 0) - entry.credit_amount
-```
+## 言語・型固有ルール
 
-## 型
+> このセクションを言語・フレームワークに合わせて書き換える。
 
-- Python 3.12+ のビルトイン型を使用（`list[str]`, `dict[str, int]`, `str | None`）
-- `typing` モジュールのインポートは不要（`List`, `Dict`, `Optional` は使わない）
-- dataclass の `frozen=True` を値オブジェクトに使用
+`<your-language-and-type-rules>`
 
 ## テスト
 
-- テストファイルは実装と同じディレクトリ構造: `tests/agents/reconciliation/test_domain.py`
-- TDDサイクル: RED → GREEN → REFACTOR
+- テストファイルは実装と同じディレクトリ構造を維持する（`tests/` 配下に `src/` と同じ構造）
+- TDD サイクル: RED → GREEN → REFACTOR
 
 ### テストコメント規約
 
-- **docstring**: 全テストメソッドにテスト意図を日本語1行で書く（メソッド名の言い換えではなく「なぜそのテストが必要か」を書く）
-- **セクション区切り**: テストクラスが3つ以上あるファイルでは、クラス間に区切りコメントを入れる
-
-```python
-# ============================================================
-# 重要度判定
-# ============================================================
-class TestDetermineSeverity:
-```
-
-- **準備・実行・検証**: セットアップが5行以上のテストでは `# 準備` / `# 実行` / `# 検証` で構造を明示する。`—` で簡潔な意図を添える（推奨）
-
-```python
-def test_full_flow(self):
-    """集計→比較→分析の全フローが動作する"""
-    # 準備 — 仕訳と調書に50K円の差異を作る
-    agent = self._make_agent()
-    entries = [_make_entry("売掛金", "売上高", 1_000_000)]
-    worksheet = [_make_balance("worksheet", "売掛金", 950_000)]
-
-    # 実行
-    results = agent.run_check(entries, worksheet, [])
-
-    # 検証 — 差異がある科目のみ返る
-    assert len(results) == 1
-    assert results[0].severity.value == "error"
-```
-
-- **インラインコメント**: データ構造やモック応答の意図が分かりにくい箇所には積極的にコメントを付ける。特にリスト要素やside_effectの各要素には `# 計画`、`# 1パス目分析` のように役割を明示する
-
-```python
-llm.chat.side_effect = [
-    plan_json,                    # 計画
-    _make_analysis_response(),    # 1パス目分析
-    investigation_needs,          # 調査判断1: 追加調査必要
-    _make_analysis_response(),    # 再分析1
-    # ここで上限到達 → ループ終了
-]
-
-# 1回目: 途中で切れたJSON、2回目: リトライで正しいJSON
-truncated_json = '[{"account_name": "売掛金", ...'
-```
-
+- **意図の記述**: 全テストにテスト意図を日本語 1 行で書く（メソッド名の言い換えではなく「なぜそのテストが必要か」を書く）
+- **準備・実行・検証**: セットアップが 5 行以上のテストでは `# 準備` / `# 実行` / `# 検証` で構造を明示する
 - **英語コメント禁止**: `Arrange` / `Act` / `Assert` 等の英語は使わない
 
 ## 後方互換ハックの禁止
@@ -95,23 +50,17 @@ truncated_json = '[{"account_name": "売掛金", ...'
 使われなくなったコードは完全に削除する。互換性維持のための温存は行わない。
 
 禁止パターン:
-- 未使用の引数・変数を `_` プレフィックスで残す（`_old_param`）
-- 削除した型・関数を `from x import Y` で再公開する
+- 使われない引数・変数を残す
+- 削除した型・関数を再公開する
 - `# removed`, `# deprecated`, `# 旧実装` コメントとともにコードを残す
 - 後方互換用のラッパー関数・エイリアスを追加する
 
 ## 検索ルール
 
 - コードの検索・置換は `src/` と `tests/` の両方を対象にする
-- 日本語のキーワード（後方互換、レガシー等）も検索対象に含める
 
 ## プロジェクト構造
 
-```
-src/
-  agents/{agent_name}/     # agent.py, domain.py, prompts.py, config.py
-  plugins/tools/{tool}/    # tool.py
-  plugins/skills/{skill}/  # skill.py
-  web/                     # FastAPI + HTMX
-tests/                     # src/ と同じ構造
-```
+> `architecture.yaml` の `folder_structure` に合わせて書き換える。
+
+`<your-project-structure>`

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

@@ -7,20 +7,21 @@ paths: ["docs/**"]
 
 ## フェーズ管理
 
-- **ユーザー承認なしにフェーズを進めない**
+- ユーザー承認なしにフェーズを進めない
 - フェーズは必ず `要件定義 -> 概要設計 -> 詳細設計 -> TDD -> 実装` の順に進める
 
 ## テンプレート
 
-- **設計書は必ずテンプレートをコピーして生成する。独自にゼロから作成しない**
+- 設計書は必ずテンプレートをコピーして生成する。独自にゼロから作成しない
 - 手順: テンプレートを読む → 出力先へコピーする → プレースホルダーを埋める
 
 ## frontmatter
 
-- **`docs/**` の全設計書に frontmatter を付ける**
+- `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 は `node_id` と `kind` のみ。`depends_on` / `maps_to` は不要（決定の記録であり実装トレーサビリティに乗らない）
 - `modules` / `source_files` などの拡張項目を足す場合でも、`maps_to` と矛盾させない
 
 ```yaml
@@ -65,7 +66,7 @@ spec_runner:
 
 ## ADR
 
-- **ADR は必ず 3 案を比較してから採用案を決める**
+- ADR は提案時に必ず 3 案を比較してから採用案を決める。ドキュメントには採用案と採用理由のみ記録する
 - ADR は `docs/02_概要設計/90_ADR/{対象}/` で管理する（`全体` / `ドメイン` / `UC` / `DB`）
 - ファイル名は `mmdd-{日本語タイトル}.md`。対象はフォルダで表す
 - ADR は理由の記録であり、詳細設計の代わりにしない
@@ -73,8 +74,25 @@ spec_runner:
 
 ## 文書品質
 
-- **概要設計では「何をするか」を書き、コード片・DDL・クラス定義は持ち込まない**
-- **詳細設計ではドメインルール・UC の責務・入出力・判断条件・テスト観点を書く。コード・プロンプト本文は書かない**
-- **`maps_to` を唯一の src 対応として使う。パス推定に頼らない**
-- **Markdown に HTML タグ（details, summary, br など）を使わない**
-- **`概要.md` のような汎用的な名前のファイルは作らない。内容を具体的に示す名前（`要件定義.md`、`ユースケース一覧.md`、`システム全体俯瞰.md` など）を使う**
+- docs にコードを書かない（コード片・DDL・クラス定義・プロンプト本文）。コードは `src/` / `tests/` に書く
+- 概要設計では「何をするか」を書く。実装の詳細は持ち込まない
+- 詳細設計ではドメインルール・UC の責務・入出力・判断条件・テスト観点を書く
+- `maps_to` を唯一の src 対応として使う。パス推定に頼らない
+- Markdown に HTML タグ（details, summary, br など）を使わない
+- 設計書に絵文字を使わない
+- `概要.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,11 +58,11 @@ description: このスキルの目的と使うタイミング（1〜2行）
 ```
 
 - `description` は Claude がスキルを選択するときに使う。「いつ使うか」を含める
-- 対応する `.github/skills/{name}/SKILL.md` も同時に作成・更新する
+- `integrations` に `github` が含まれる場合、対応する `.github/skills/{name}/SKILL.md` も作成・更新する
 
 ## CLAUDE.md
 
-CLAUDE.md は**全会話で常にコンテキストに読み込まれる**。書くほどコストが増えるため、最小に保つ。
+CLAUDE.md は全会話で常にコンテキストに読み込まれる。書くほどコストが増えるため、最小に保つ。
 
 ### 書いてよいもの
 
@@ -80,11 +80,14 @@ CLAUDE.md は**全会話で常にコンテキストに読み込まれる**。書
 
 ### 目安
 
-- 20行を超えたら見直しを検討する
+- 20 行を超えたら見直しを検討する
 - 新しい内容を追加する前に「rules / skills に移せないか」を先に考える
 
 ## 共通原則
 
-- `.claude/` と `.github/` は常に対で更新する（片系だけ更新しない）
-- `description` は「何をするか」より「**いつ・なぜ使うか**」を優先して書く
+- 更新する連携先は `architecture.yaml` の `integrations` に従う
+  - `claude` のみ → `.claude/` だけ更新する。`.github/` を作成しない
+  - `github` のみ → `.github/` だけ更新する。`.claude/` を作成しない
+  - 両方 → `.claude/` と `.github/` を対で更新する
+- `description` は「何をするか」より「いつ・なぜ使うか」を優先して書く
 - 新規作成時は既存ファイルを参考にフォーマットを確認してから作る

package/spec-runner/templates/.claude/rules/sub-agent-delegation.md

@@ -4,7 +4,7 @@ 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 で決定した構造（`src/` / `tests/` / `docs/` など）
+   - domain_structure（style: ddd のときのみ）
    - runtime_units
    - design_policy
    - testing_policy
@@ -50,14 +76,16 @@ Phase 5: 次の skill へ引き渡し
 
 ## Phase 5: architecture-skill-development へ自動移行
 
-Phase 4 が承認されたら、**ユーザーにコマンドを打たせずに `architecture-skill-development` を続けて開始する**。
+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 を作る前にアーキテクチャを固める