spec-runner 1.4.0 → 1.5.0

package/package.json

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

package/spec-runner/templates/{.github/agents/impact-analyzer.agent.md → .claude/agents/analyze-impact.md}

@@ -1,13 +1,11 @@
 ---
-name: impact-analyzer
+name: analyze-impact
 description: design-change で影響範囲を調査するときに呼ぶ。node_id から連鎖する影響ファイルを一覧化し、maps_to の整合性を報告する。
 tools: Bash
 model: sonnet
 ---
 
-# 影響範囲分析エージェント（読み取り専用）
-
-`graph.json`（`scan.js` が生成するキャッシュ）を読み、変更対象の node_id から連鎖する影響ファイルを一覧化する。
+# 影響範囲分析
 
 ## 入力
 
@@ -15,14 +13,14 @@ model: sonnet
 
 ## 手順
 
-### 1. グラフキャッシュの確認・更新
+### 1. graph.json の確認
+
+`graph.json` は Edit / Write のたびに hooks で自動更新される。`.spec-runner/scan/graph.json` が存在しない場合のみ以下を実行する。
 
 ```bash
 node .spec-runner/scripts/scan.js
 ```
 
-キャッシュが古い場合や存在しない場合は再生成する。
-
 ### 2. 影響範囲をグラフから取得
 
 ```bash

package/spec-runner/templates/.claude/agents/{code-reviewer.md → review-code.md}

@@ -1,18 +1,16 @@
 ---
-name: code-reviewer
+name: review-code
 description: 実装・修正が完了したときに自動で呼ぶ。変更ファイルをコーディング規約と照合し違反を報告する。修正はしない。
 tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
 
-# コーディング規約チェックエージェント（読み取り専用）
-
-変更されたコードをコーディング規約と照合し、違反を報告する。変更ファイルのみが対象。
+# コーディング規約チェック
 
 ## 手順
 
 1. `git diff --name-only` で変更ファイルを確認する（引数でファイルが指定された場合はそちらを使用）
-2. `.claude/rules/coding.md` を読み、チェック項目を把握する
+2. `.claude/rules/code-style.md` を読み、チェック項目を把握する
 3. 変更されたソースファイルを読み込む
 4. チェック項目に照らして違反を検出する
 5. 違反を報告する

package/spec-runner/templates/{.github/agents/design-reviewer.agent.md → .claude/agents/review-design.md}

@@ -1,26 +1,26 @@
 ---
-name: design-reviewer
+name: review-design
 description: 設計書を変更したとき、またはフェーズレビュー時に自動で呼ぶ。docs⇔src の乖離を報告する。修正はしない。
 tools: Read, Grep, Glob
 model: sonnet
 ---
 
-# 設計書⇔実装 整合性チェックエージェント（読み取り専用）
-
-`docs/` の設計書と `src/` の実装コードを突合し、乖離を報告する。`maps_to` を唯一の参照先とする（パス推定は行わない）。
+# 設計書⇔実装 整合性チェック
 
 ## 手順
 
-1. `docs/` 配下の設計書ファイルを一覧取得する
-2. 各設計書の frontmatter を読み、`spec_runner.node_id` / `kind` / `depends_on` / `maps_to` を確認する
-3. `docs/02_概要設計/**` の各ファイルを読む。`maps_to` から対応する `src/` ファイルを特定して読み、ユースケース・責務・外部 IF が実装に反映されているか比較する
-4. `docs/03_詳細設計/**` の各ファイルを読む。`maps_to` に列挙された `src/` / `tests/` ファイルを実際に読み、責務・入出力・判断条件・テスト観点を設計書と行レベルで比較する（`maps_to` が空または未設定の場合は frontmatter の問題として報告する）
-5. 乖離を報告する
+1. `.spec-runner/scan/graph.json` を読み、`missing_maps_to` を取得する。以降のヘッダーチェックではこの結果を使う（`graph.json` は Edit / Write のたびに hooks で自動更新済み）
+2. `docs/` 配下の設計書ファイルを一覧取得する
+3. 各設計書のヘッダーを読み、`spec_runner.node_id` / `kind` / `depends_on` / `maps_to` を確認する
+4. `docs/02_概要設計/**` の各ファイルを読む。`maps_to` から対応する `src/` ファイルを特定して読み、ユースケース・責務・外部 IF が実装に反映されているか比較する
+5. `docs/03_詳細設計/**` の各ファイルを読む。`maps_to` に列挙された `src/` / `tests/` ファイルを実際に読み、責務・入出力・判断条件・テスト観点を設計書と行レベルで比較する（`maps_to` が空または未設定の場合はヘッダーの問題として報告する）
+6. 乖離を報告する
 
 ## チェック項目
 
-### frontmatter
+### ヘッダー
 
+- **参照原則**: `maps_to` を唯一の src 対応とする。パス推定は行わない
 - **必須項目**: `node_id` / `kind` / `depends_on` / `maps_to` が存在するか
 - **依存整合**: `depends_on` の参照先が実在するか。依存の向きが明らかに逆転していないか
 - **対応整合**: `maps_to` の実ファイルが存在するか。変更対象が漏れていないか
@@ -43,7 +43,7 @@ model: sonnet
 ```
 ## 整合性チェック結果
 
-### frontmatter の問題
+### ヘッダーの問題
 - [ファイル]: [問題内容]
 
 ### 一致（問題なし）

package/spec-runner/templates/.claude/agents/{test-runner.md → run-tests.md}

@@ -1,25 +1,21 @@
 ---
-name: test-runner
+name: run-tests
 description: 実装・修正が完了したときに自動で呼ぶ。テストを実行し、失敗時は原因と修正案を報告する。コードは修正しない。
 tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
 
-# テスト実行エージェント（読み取り専用）
-
-> このファイルはテンプレートです。`architecture-skill-development` でプロジェクトのテスト実行コマンドに書き換えてください。
-
-テストを実行し、結果を分析する。コードは修正しない。
+# テスト実行
 
 ## 手順
 
 1. `git diff --name-only` で変更ファイルを確認する
 2. 変更ファイルに対応するテストファイルを特定する（`tests/` 配下の同構造）
-3. `.claude/rules/testing.md` を読んでテスト実行コマンドを確認する
+3. `.claude/rules/test-config.md` を読んでテスト実行コマンドを確認する
 4. テストを実行する:
    - 対象テストが明確な場合: テストコマンド + `<test-file> -v`
    - 全体実行が必要な場合: 全テストコマンド + `-v`
-4. 結果を分析する
+5. 結果を分析する
 
 ## 失敗時の分析
 

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

@@ -0,0 +1,31 @@
+---
+description: メインエージェントがサブエージェントへ委任すべきタスクの指針
+---
+
+# サブエージェント委任ルール
+
+メインエージェントは判断・対話・ファイル編集に集中する。検証・調査・実行・ファイル検索はすべてサブエージェントへ委任する（メインのコンテキスト節約）。
+
+## 委任する場面と委任先
+
+| 場面 | 委任先 | タイミング |
+|------|--------|-----------|
+| 設計書⇔実装の整合性確認 | `@review-design` | 設計書を変更したとき、フェーズレビュー時 |
+| コーディング規約チェック | `@review-code` | 実装・修正が完了したとき |
+| テスト実行＋失敗分析 | `@run-tests` | 実装・修正が完了したとき |
+| 変更の影響範囲調査 | `@analyze-impact` | design-change で影響範囲を洗うとき |
+
+## 並行起動
+
+独立して動けるエージェントは同時に起動する。
+
+例: 実装完了後 → `@run-tests` と `@review-code` を**同時に**起動し、両方の結果を待ってからユーザーへ報告する。
+
+## メインエージェントが自分でやること
+
+サブエージェントは会話の文脈を持たない。以下はメインエージェントが担う:
+
+- ユーザーとの対話・意思決定・承認の受け取り
+- フェーズの進行管理・次のアクションの判断
+- ファイルの作成・編集
+- サブエージェントの結果をポイントを絞ってユーザーへ伝える（生の出力をそのまま貼らない）

package/spec-runner/templates/.claude/rules/{coding.md → code-style.md}

@@ -48,15 +48,26 @@ paths: ["src/**", "tests/**"]
 
 ## テスト
 
-- テストファイルは実装と同じディレクトリ構造を維持する（`tests/` 配下に `src/` と同じ構造）
-- TDD サイクル: RED → GREEN → REFACTOR
-
 ### テストコメント規約
 
 - **意図の記述**: 全テストにテスト意図を日本語 1 行で書く（メソッド名の言い換えではなく「なぜそのテストが必要か」を書く）
-- **準備・実行・検証**: セットアップが 5 行以上のテストでは `# 準備` / `# 実行` / `# 検証` で構造を明示する
+- **準備・実行・検証**: セットアップが 5 行以上のテストでは `# 準備 - ...` / `# 実行 - ...` / `# 検証 - ...` で構造を明示する。サフィックスには具体的に何をしているかを書く
 - **英語コメント禁止**: `Arrange` / `Act` / `Assert` 等の英語は使わない
 
+```
+# なぜそのテストが必要かを1行で書く
+test("ある入力に対して期待する出力を返す", () => {
+  # 準備 - テスト対象の入力データを用意する
+  const input = ...
+
+  # 実行 - テスト対象の関数を呼び出す
+  const result = targetFunction(input)
+
+  # 検証 - 期待する出力と一致するか確認する
+  expect(result).toBe(expectedOutput)
+})
+```
+
 ## 後方互換ハックの禁止
 
 使われなくなったコードは完全に削除する。互換性維持のための温存は行わない。

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

@@ -1,5 +1,5 @@
 ---
-description: 設計書共通ルール（frontmatter・命名規則・ADR・文書品質）
+description: 設計書共通ルール（ヘッダー・命名規則・ADR・文書品質）
 paths: ["docs/**"]
 ---
 
@@ -15,9 +15,9 @@ paths: ["docs/**"]
 - 設計書は必ずテンプレートをコピーして生成する。独自にゼロから作成しない
 - 手順: テンプレートを読む → 出力先へコピーする → プレースホルダーを埋める
 
-## frontmatter
+## ヘッダー
 
-- `docs/**` の全設計書に frontmatter を付ける
+- `docs/**` の全設計書にヘッダーを付ける
 - 正本の必須項目は `spec_runner.node_id` / `spec_runner.kind` / `spec_runner.depends_on` / `spec_runner.maps_to`
 - `depends_on` はまず文字列配列でよい。依存理由が必要な場合のみオブジェクト形式を使う
 - `maps_to` には `src/` / `tests/` / IaC / 設定ファイルを列挙する。必ず設定する（空にしない）
@@ -80,9 +80,9 @@ spec_runner:
 - 詳細設計ではドメインルール・UC の責務・入出力・判断条件・テスト観点を書く
 - `maps_to` を唯一の src 対応として使う。パス推定に頼らない
 - Markdown に HTML タグ（details, summary, br など）を使わない
-- 設計書に絵文字を使わない
+- 設計書に絵文字・記号（✓ ✅ ☑ ◯ × △ など）を使わない。状態・判定は文字で表現する
 - `概要.md` のような汎用的な名前は使わない（`要件定義.md`、`ユースケース一覧.md` のように内容を示す名前にする）
-- 「関連ドキュメント」セクションを設計書に作らない。依存関係は frontmatter の `depends_on` で管理する
+- 「関連ドキュメント」セクションを設計書に作らない。依存関係はヘッダーの `depends_on` で管理する
 - 「スケジュール」セクションを設計書に作らない。進捗管理は設計書の責務ではない
 
 ## ドメインモデルとデータモデルの分離（style: ddd のみ）

package/spec-runner/templates/.claude/rules/{testing.md → test-config.md}

@@ -1,5 +1,5 @@
 ---
-description: テスト実行コマンドと種別構成。test-driven-development スキルと test-runner エージェントの両方がここを参照する。
+description: テスト実行コマンドと種別構成。test-driven-development スキルと run-tests エージェントの両方がここを参照する。
 paths: ["src/**", "tests/**"]
 ---
 

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

@@ -5,9 +5,6 @@ description: 新規プロジェクトで docs と `.spec-runner/architecture/arc
 
 # architecture-definition
 
-新規プロジェクト向けの初期化フロー。
-要件定義・フォルダ構造の決定・architecture contract の作成までを先に固め、スキル整備を経てから概要設計へ進む。
-
 ## 全体フロー
 
 ```
@@ -21,19 +18,20 @@ Phase 5: architecture-skill-development へ自動移行
 
 ## Phase 1: 要件整理
 
-テンプレート: `.claude/skills/docs-driven-seed/templates/01_要件定義/`
+テンプレート: `.claude/skills/ddd-seed/templates/01_要件定義/`
 
-1. ユーザーから背景、提供価値、制約、スコープ外を確認する
-2. テンプレートをコピーして `docs/01_要件定義/要件定義.md` を作る
-3. ドメイン用語が出てきたら `docs/01_要件定義/ユビキタス言語辞書.md` に随時追記する
-4. アーキテクチャスタイルを選択する
+1. 曖昧な前提があれば `spec-probe` スキルで先に整理する
+2. ユーザーから背景、提供価値、制約、スコープ外を確認する
+3. テンプレートをコピーして `docs/01_要件定義/要件定義.md` を作る
+4. ドメイン用語が出てきたら `docs/01_要件定義/ユビキタス言語辞書.md` に随時追記する
+5. アーキテクチャスタイルを選択する
 
    | スタイル | 選ぶ基準 |
    |---------|---------|
    | `ddd` | 複雑なビジネスドメインがある。集約・境界コンテキストで設計する必要がある |
    | `layered` | CRUD 中心またはビジネスロジックがシンプル。UC・サービス層で設計すれば十分 |
 
-5. 使用する AI 連携を確認する
+6. 使用する AI 連携を確認する
 
    | 連携 | フォルダ |
    |------|---------|
@@ -41,11 +39,11 @@ Phase 5: architecture-skill-development へ自動移行
    | `github` | `.github/`（GitHub Copilot） |
    | 両方 | `.claude/` と `.github/` |
 
-6. ユーザーに確認・承認を得る
+7. ユーザーに確認・承認を得る
 
 ## Phase 2: フォルダ構造の決定
 
-対話でプロジェクトのフォルダ構造を決める。この段階で決めた構造がテンプレートの `maps_to` パスに焼き込まれるため、概要設計より前に確定させる。
+この段階で決めた構造がテンプレートの `maps_to` パスに焼き込まれるため、概要設計より前に確定させる。
 
 1. 以下をユーザーと対話しながら決める
    - `src/` 配下のパッケージ・モジュール構成
@@ -63,7 +61,7 @@ Phase 5: architecture-skill-development へ自動移行
 
 ## Phase 4: architecture contract 作成
 
-1. `.spec-runner/architecture/architecture.yaml` を作る
+1. `.spec-runner/architecture/architecture.yaml` を作る（`.spec-runner/` は補助情報として扱う）
 2. 最低限、以下を構造化する
    - **integrations**: Phase 1 で確認した連携（`[claude]` / `[github]` / `[claude, github]`）
    - **style**: Phase 1 で選択したスタイル（`ddd` / `layered`）
@@ -82,10 +80,3 @@ Phase 4 が承認されたら、ユーザーにコマンドを打たせずに `a
 2. project 専用 skill に切り出すべき反復フローを列挙する
 3. 確認なしに `architecture-skill-development` Phase 1 へ進む
 4. スキル整備完了後、プロジェクト専用スキルを使って概要設計へ進む
-
-## 原則
-
-- フォルダ構造を概要設計より前に確定する
-- スキル整備が完了してから概要設計へ進む（テンプレートの `maps_to` を確定済み構造で焼き込むため）
-- `.spec-runner/` は補助情報として扱う
-- project 専用 skill を作る前にアーキテクチャを固める

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

@@ -5,9 +5,6 @@ description: architecture contract と docs を読み、プロジェクト専用
 
 # architecture-skill-development
 
-`architecture-definition` または `existing-project-to-docs` の後に使う。
-決まったアーキテクチャから、そのプロジェクト専用の skill / rule / template を作る。
-
 ## 全体フロー
 
 ```
@@ -34,7 +31,7 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 ## Phase 3: skill / rule / template へ分解
 
-ファイルを作成する前に `.claude/rules/harness-formats.md` を読み、フォーマットを確認する。
+ファイルを作成する前に `.claude/skills/harness-engineering/references/harness-format.md` を読み、フォーマットを確認する。
 
 1. 会話フローは skill にする
 2. 常時守る約束は rule にする
@@ -46,56 +43,31 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 | style | 使う seed | 説明 |
 |-------|----------|------|
-| `ddd` | `docs-driven-seed` | ドメイン層（集約・値オブジェクト）を持つ DDD 向けフロー |
+| `ddd` | `ddd-seed` | ドメイン層（集約・値オブジェクト）を持つ DDD 向けフロー |
 | `layered` | `simple-seed` | ドメイン層を持たない UC・サービス層中心のフロー |
 
-選んだ seed の SKILL.md をコピーして、このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作ることを目的とする。
-
-具体的には:
-- 選んだ seed の SKILL.md をコピーして、project 専用の開発 skill の土台にする
-- フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換える
-- Phase 1（要件定義）は architecture-definition で完了済みのため削除する
-- 元の seed は書き換え完了後にアーカイブ候補とする（Phase 6 で提案する）
+選んだ seed の SKILL.md をコピーし、フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換えたプロジェクト専用 skill を作る（Phase 1 は完了済みのため削除する。元の seed はアーカイブ候補とする）。
 
 4. ユーザーに確認・承認を得る
 
 ## Phase 4: 基盤 skill のプロジェクト固有化
 
 インストール時に配布された基盤 skill のプレースホルダーを、このプロジェクトの実態に書き換える。
+以降の書き換えはすべて `architecture.yaml` の `integrations` に従う（`claude` のみなら `.claude/` だけ、`github` のみなら `.github/` だけ、両方なら対で更新する）。
 
-> 以降の書き換えはすべて `architecture.yaml` の `integrations` に従う。`claude` のみなら `.claude/` だけ、`github` のみなら `.github/` だけ、両方なら対で更新する。
-
-### testing.md の書き換え
+### test-config.md の書き換え
 
-`rules/testing.md`（GitHub Copilot は `instructions/testing.instructions.md`）はテスト実行コマンドの単一ソースとして `test-driven-development` スキルと `test-runner` エージェントの両方から参照される。`architecture.yaml` の `testing_policy` を参照して書き換える。
+`rules/test-config.md`（GitHub Copilot は `instructions/test-config.instructions.md`）はテスト実行コマンドの単一ソースとして `test-driven-development` スキルと `run-tests` エージェントの両方から参照される。`architecture.yaml` の `testing_policy` を参照して書き換える。
 
 1. **テスト実行コマンド**: `<your-unit-test-command>` / `<your-integration-test-command>` 等を実際のコマンドに書き換える
-
-   例:
-   ```bash
-   # 全テスト
-   docker compose run --rm test pytest
-
-   # 特定ファイル
-   docker compose run --rm test pytest tests/path/to/test_file.py
-
-   # カバレッジ計測
-   docker compose run --rm test pytest --cov=. --cov-report=term-missing
-   ```
-
 2. **テスト構成**: `tests/` のディレクトリ構成が実態と異なる場合は書き換える
 
-上記の `integrations` ルールに従って反映する。
-
-### test-driven-development の書き換え（テストコマンド以外）
+### test-driven-development の書き換え
 
 `architecture.yaml` の `language` を参照して、以下を実際の値に置き換える。
 
-1. **コード例**: 言語・フレームワークに合わせて RED / GREEN の例を書き直す
-2. **fixture / テストデータ**: このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
-3. **モックのルール**: 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
-
-上記の `integrations` ルールに従って反映する。
+1. **fixture / テストデータ**: このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
+2. **モックのルール**: 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
 
 ### 影響範囲チェックリストの書き換え
 
@@ -104,7 +76,7 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 1. 変更カテゴリをプロジェクトの構成要素（モジュール・サービス・ドメインなど）に合わせて追加・削除する
 2. 詳細設計のパスを `architecture.yaml` の `folder_structure` に合わせて書き換える
 
-### coding.md の書き換え
+### code-style.md の書き換え
 
 `architecture.yaml` の `language` と `folder_structure` を参照して、以下を実際の値に置き換える。
 
@@ -114,8 +86,6 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 3. **言語・型固有ルール**: `<your-language-and-type-rules>` を言語・フレームワークに合わせた具体的なルールに書き換える
 4. **プロジェクト構造**: `<your-project-structure>` を `folder_structure` の実際のディレクトリ構成に書き換える
 
-上記の `integrations` ルールに従って反映する。
-
 ### その他の基盤 skill
 
 同様のプレースホルダーや汎用記述が他の skill にあれば、同じ要領で書き換える。
@@ -137,9 +107,9 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 |---|---|
 | `architecture-definition` | 新規プロジェクト初期化専用。アーキテクチャ確定後は不要 |
 | `existing-project-to-docs` | 既存プロジェクト取り込み専用。docs 生成後は不要 |
-| `docs-driven-seed` | Phase 3 で project 専用 skill の種として使い終えたら不要（`style: ddd` のとき）。ただし `templates/01_要件定義/` は `architecture-definition` が参照するため、`architecture-definition` も同時にアーカイブする場合のみ削除する |
-| `simple-seed` | Phase 3 で project 専用 skill の種として使い終えたら不要（`style: layered` のとき） |
-| `architecture-skill-development`（このファイル自身） | project 専用 skill が安定したら不要。ただしアーキテクチャが大きく変わる場合は再利用する可能性があるため、削除ではなくアーカイブを推奨 |
+| `ddd-seed` | style: ddd で seed 使用後は不要。ただし `architecture-definition` も同時アーカイブする場合のみ `templates/01_要件定義/` を削除可 |
+| `simple-seed` | style: layered で seed 使用後は不要 |
+| `architecture-skill-development`（このファイル自身） | project 専用 skill が安定したら不要。アーキテクチャ大変更時は再利用可 |
 
 ### 手順
 
@@ -149,7 +119,7 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 4. `.spec-runner/` の不要ファイルも整理する
    - `intake/current-system-inventory.md` — docs に昇格済みなら削除してよい
    - `architecture/architecture.yaml` — project 専用 skill が完成し、参照不要になったら削除してよい
-   - `scripts/scan.js` — **削除しない**。`@impact-analyzer` が常時依存しているため
+   - `scripts/scan.js` — **削除しない**。`@analyze-impact` が常時依存しているため
 5. `CLAUDE.md` を更新する
    - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
    - 作成した project 専用 skill の名前と使いどころを記載する
@@ -161,10 +131,3 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
      テストを書くときは `/test-driven-development` を使う。
      ```
    - `.claude/` と `.github/` 両系で内容が変わる場合は、それぞれに反映する
-
-## 原則
-
-- 固定の architecture pack を増やしすぎない
-- project 専用 skill を先に考える
-- docs と architecture contract の両方を入力にする
-- skill の削除・移動はユーザー承認なしに行わない

package/spec-runner/templates/.claude/skills/{docs-driven-seed → ddd-seed}/SKILL.md

@@ -1,12 +1,9 @@
 ---
-name: docs-driven-seed
+name: ddd-seed
 description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジェクトの初期テンプレートとして使い、architecture-skill-development でプロジェクト専用スキルに育てる。
 ---
 
-# docs-driven-seed
-
-> DDD を採用するプロジェクト向けの docs 正本開発フロー（種）。`architecture.yaml` の `style: ddd` で使う。レイヤード / CRUD 中心は `simple-seed` を使う。
-> このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てる。
+# ddd-seed
 
 ## 全体フロー
 
@@ -20,9 +17,9 @@ Phase 5: TDD → 実装
 
 ## 前提ルール
 
-- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- docs は正本とし、各ドキュメントに `spec_runner`ヘッダーを付ける
 - 詳細設計は `01_ドメイン/` `02_ユースケース/` `03_DB・外部サービス/` の 3 層で構成する
-- UC がドメインを使う。ドメインの中に UC は入れない
+- ドメインを先に設計し、UC はドメインを参照する形で書く。ドメインの中に UC は入れない
 - `maps_to` は必ず設定する。パス推定に頼らない
 - ユーザー承認なしに次フェーズへ進めない
 
@@ -112,13 +109,3 @@ docs/03_詳細設計/03_DB・外部サービス/
 ## Phase 5: TDD → 実装
 
 `test-driven-development` スキルへ移行する。
-
-### 実装完了後
-
-- `@design-reviewer` — 設計書⇔実装の整合性チェック
-- `@code-reviewer` — コーディング規約への適合チェック
-
-## 原則
-
-- ドメインを先に設計し、UC はドメインを参照する形で書く
-- `maps_to` は必ず設定する。パス推定に頼らない

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

@@ -5,7 +5,7 @@ description: 既存機能の変更を docs 正本で進めるフローガイド
 
 # design-change
 
-既存機能の変更・修正を設計書駆動で進めるフローガイド。フェーズは順番通りに進める。ユーザーの承認なしに先へ進めない。
+フェーズは順番通りに進める。ユーザーの承認なしに先へ進めない。
 
 影響範囲のチェックリストは `references/影響範囲チェックリスト.md` を参照する。
 ADR テンプレートは `templates/90_ADR/ADRテンプレート.md` を使用する。
@@ -23,15 +23,16 @@ Phase 6: TDD → 実装 → 検証
 
 ## Phase 1: 変更要求の整理と軽い影響調査
 
-1. 以下をユーザーにヒアリングする
+1. 曖昧な前提があれば `spec-probe` スキルで先に整理する
+2. 以下をユーザーにヒアリングする
    - 変更の背景・課題
    - 変更の目的・期待する結果
    - 影響を受ける機能カテゴリ
    - 技術的・ビジネス的制約
-2. 変更起点となる docs を特定する
-3. `@impact-analyzer` に委任して `depends_on` / `maps_to` を辿る影響ファイルを洗い出す
-4. 変更が影響するドメインと成果物を一覧化する
-5. ユーザーに確認・承認を得る
+3. 変更起点となる docs を特定する
+4. `@analyze-impact` に委任して `depends_on` / `maps_to` を辿る影響ファイルを洗い出す
+5. 変更が影響するドメインと成果物を一覧化する
+6. ユーザーに確認・承認を得る
 
 ## Phase 2: ADR 作成（必要時）
 
@@ -55,23 +56,20 @@ Phase 6: TDD → 実装 → 検証
 ## Phase 3: 影響ドキュメントの確定
 
 1. `references/影響範囲チェックリスト.md` を読み、変更に応じた影響ドキュメントを網羅的に洗い出す
-2. frontmatter の `depends_on` / `maps_to` を使って候補を絞る
+2.ヘッダーの `depends_on` / `maps_to` を使って候補を絞る
 3. 修正が必要なファイルをチェックリスト形式で提示する
-4. `@design-reviewer` エージェントに委任して、現時点の設計書⇔実装の乖離も合わせて確認する
+4. `@review-design` エージェントに委任して、現時点の設計書⇔実装の乖離も合わせて確認する
 5. ユーザーに確認・承認を得る
 
 ## Phase 4: 概要設計の修正
 
+概要設計では「何をするか」に留める。変更理由は ADR または本文で追えるようにする。
+
 1. `ユースケース一覧.md` / `システム全体俯瞰.md` / ADR を必要順に修正する
 2. `style: ddd` の場合: `ドメインモデル.md` も必要に応じて修正する
 3. 修正完了ごとにチェックリストを更新する
 4. 全概要設計の修正完了後、ユーザーに確認・承認を得る
 
-### 修正時の注意
-
-- 変更理由は ADR または本文で追えるようにする
-- 概要設計では「何をするか」に留める
-
 ## Phase 5: 詳細設計の修正
 
 `style: ddd` の場合:
@@ -85,19 +83,8 @@ Phase 6: TDD → 実装 → 検証
 1. `docs/03_詳細設計/01_ユースケース/**` の UC 設計を修正する
 2. DB・外部サービスの変更がある場合は `docs/03_詳細設計/02_DB・外部サービス/**` を修正する
 
-frontmatter の `depends_on` / `maps_to` を更新する。ユーザーに最終確認を得る。
+ヘッダー の `depends_on` / `maps_to` を更新する。ユーザーに最終確認を得る。
 
 ## Phase 6: TDD → 実装 → 検証
 
 設計書修正が承認されたら `test-driven-development` スキルへ移行する。
-
-### 実装完了後のレビュー
-
-- `@design-reviewer` — frontmatter と `maps_to` を起点に設計書⇔実装の整合性チェック
-- `@code-reviewer` — コーディング規約への適合チェック
-
-## 原則
-
-- 影響候補の洗い出しを ADR より先に行う
-- 概要設計を先に直し、そのあと詳細設計を直す
-- frontmatter の更新を後回しにしない

package/spec-runner/templates/.claude/skills/design-change/references//345/275/261/351/237/277/347/257/204/345/233/262/343/203/201/343/202/247/343/203/203/343/202/257/343/203/252/343/202/271/343/203/210.md

@@ -56,4 +56,4 @@ design-change の Phase 3（影響ドキュメントの確定）で参照する
 - **ユースケース一覧 ↔ 詳細設計**: 一覧に記載の UC が詳細設計でカバーされているか
 - **システム全体俯瞰 ↔ 詳細設計**: 責務分割が詳細設計に落ちているか
 - **ドメイン設計 ↔ DB スキーマ**: ドメインのフィールドが DB カラムと対応しているか（style: ddd のみ）
-- **frontmatter ↔ 実ファイル**: `depends_on` と `maps_to` が現状に追随しているか
+- **ヘッダー ↔ 実ファイル**: `depends_on` と `maps_to` が現状に追随しているか