spec-runner 1.1.17 → 1.1.18

package/spec-runner/templates/.github/instructions/coding.instructions.md

@@ -4,89 +4,44 @@ applyTo: "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` 等の英語は使わない
 
 ## 後方互換ハックの禁止
@@ -94,23 +49,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/.github/instructions/design-docs.instructions.md

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

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

@@ -56,7 +56,7 @@ description: このスキルの目的と使うタイミング（1〜2行）
 
 ## CLAUDE.md
 
-CLAUDE.md は**全会話で常にコンテキストに読み込まれる**。書くほどコストが増えるため、最小に保つ。
+CLAUDE.md は全会話で常にコンテキストに読み込まれる。書くほどコストが増えるため、最小に保つ。
 
 ### 書いてよいもの
 
@@ -74,14 +74,14 @@ CLAUDE.md は**全会話で常にコンテキストに読み込まれる**。書
 
 ### 目安
 
-- 20行を超えたら見直しを検討する
+- 20 行を超えたら見直しを検討する
 - 新しい内容を追加する前に「instructions / skills に移せないか」を先に考える
 
 ## 共通原則
 
-- **更新する連携先は `architecture.yaml` の `integrations` に従う**
+- 更新する連携先は `architecture.yaml` の `integrations` に従う
   - `claude` のみ → `.claude/` だけ更新する。`.github/` を作成しない
   - `github` のみ → `.github/` だけ更新する。`.claude/` を作成しない
   - 両方 → `.claude/` と `.github/` を対で更新する
-- `description` は「何をするか」より「**いつ・なぜ使うか**」を優先して書く
+- `description` は「何をするか」より「いつ・なぜ使うか」を優先して書く
 - 新規作成時は既存ファイルを参考にフォーマットを確認してから作る

package/spec-runner/templates/.github/instructions/sub-agent-delegation.instructions.md

@@ -4,7 +4,7 @@ applyTo: "**"
 
 # サブエージェント委任ルール
 
-**メインエージェントは判断・対話・ファイル編集に集中する。検証・調査・実行は積極的にサブエージェントへ委任する。**
+メインエージェントは判断・対話・ファイル編集に集中する。検証・調査・実行は積極的にサブエージェントへ委任する。
 
 ## 委任する場面と委任先
 

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

@@ -67,7 +67,7 @@ Phase 5: architecture-skill-development へ自動移行
 2. 最低限、以下を構造化する
    - **integrations**: Phase 1 で確認した連携（`[claude]` / `[github]` / `[claude, github]`）
    - **style**: Phase 1 で選択したスタイル（`ddd` / `layered`）
-   - **folder_structure**: Phase 2 で決定した構造
+   - **folder_structure**: Phase 2 で決定した構造（`src/` / `tests/` / `docs/` など）
    - domain_structure（style: ddd のときのみ）
    - runtime_units
    - design_policy
@@ -76,12 +76,12 @@ Phase 5: architecture-skill-development へ自動移行
 
 ## Phase 5: architecture-skill-development へ自動移行
 
-Phase 4 が承認されたら、**ユーザーにコマンドを打たせずに `architecture-skill-development` を続けて開始する**。
+Phase 4 が承認されたら、ユーザーにコマンドを打たせずに `architecture-skill-development` を続けて開始する。
 
 1. `architecture-skill-development` に渡す前提（docs・architecture.yaml・確定済みフォルダ構造）を要約する
 2. project 専用 skill に切り出すべき反復フローを列挙する
 3. 確認なしに `architecture-skill-development` Phase 1 へ進む
-4. **スキル整備完了後、プロジェクト専用スキルを使って概要設計へ進む**
+4. スキル整備完了後、プロジェクト専用スキルを使って概要設計へ進む
 
 ## 原則
 

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

@@ -34,7 +34,7 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 ## Phase 3: skill / rule / template へ分解
 
-ファイルを作成する前に **`.github/instructions/harness-formats.instructions.md`** を読み、フォーマットを確認する。
+ファイルを作成する前に `.github/instructions/harness-formats.instructions.md` を読み、フォーマットを確認する。
 
 1. 会話フローは skill にする
 2. 常時守る約束は rule にする
@@ -49,12 +49,12 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 | `ddd` | `docs-driven-seed` | ドメイン層（集約・値オブジェクト）を持つ DDD 向けフロー |
 | `layered` | `simple-seed` | ドメイン層を持たない UC・サービス層中心のフロー |
 
-選んだ seed の SKILL.md をコピーして、**このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作る**ことを目的とする。
+選んだ seed の SKILL.md をコピーして、このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作ることを目的とする。
 
 具体的には:
 - 選んだ seed の SKILL.md をコピーして、project 専用の開発 skill の土台にする
 - フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換える
-- **Phase 1（要件定義）は architecture-definition で完了済みのため削除する**
+- Phase 1（要件定義）は architecture-definition で完了済みのため削除する
 - 元の seed は書き換え完了後にアーカイブ候補とする（Phase 6 で提案する）
 
 4. ユーザーに確認・承認を得る
@@ -63,11 +63,13 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 インストール時に配布された基盤 skill のプレースホルダーを、このプロジェクトの実態に書き換える。
 
+> 以降の書き換えはすべて `architecture.yaml` の `integrations` に従う。`claude` のみなら `.claude/` だけ、`github` のみなら `.github/` だけ、両方なら対で更新する。
+
 ### test-driven-development の書き換え
 
 `architecture.yaml` の `testing_policy` と `language` を参照して、以下を実際の値に置き換える。
 
-1. **テスト実行コマンド** — `<your-test-command>` を実際のコマンドに書き換える
+1. **テスト実行コマンド**: `<your-test-command>` を実際のコマンドに書き換える
 
    例:
    ```bash
@@ -81,14 +83,38 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
    docker compose run --rm test pytest --cov=. --cov-report=term-missing
    ```
 
-2. **コード例** — 言語・フレームワークに合わせて RED / GREEN の例を書き直す
+2. **コード例**: 言語・フレームワークに合わせて RED / GREEN の例を書き直す
 
-3. **fixture / テストデータ** — このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
+3. **fixture / テストデータ**: このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
 
-4. **モックのルール** — 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
+4. **モックのルール**: 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
 
 書き換えは `.claude/skills/test-driven-development/SKILL.md` と `.github/skills/test-driven-development/SKILL.md` の両方に反映する。
 
+### test-runner エージェントの書き換え
+
+`architecture.yaml` の `testing_policy` を参照して、以下を実際の値に置き換える。
+
+1. **テスト実行コマンド**: `<your-test-command>` を実際のコマンドに書き換える
+2. **説明文**: 実行環境（Docker / ローカル など）が分かるよう補足する
+
+### 影響範囲チェックリストの書き換え
+
+`.claude/skills/design-change/references/影響範囲チェックリスト.md` をプロジェクト固有の変更カテゴリとパスに合わせて書き換える。
+
+1. 変更カテゴリをプロジェクトの構成要素（モジュール・サービス・ドメインなど）に合わせて追加・削除する
+2. 詳細設計のパスを `architecture.yaml` の `folder_structure` に合わせて書き換える
+
+### coding.md の書き換え
+
+`architecture.yaml` の `language` と `folder_structure` を参照して、以下を実際の値に置き換える。
+
+1. **命名規則**: 言語の慣習に合わせてテーブルの規則・例を書き換える
+2. **言語・型固有ルール**: `<your-language-and-type-rules>` を言語・フレームワークに合わせた具体的なルールに書き換える
+3. **プロジェクト構造**: `<your-project-structure>` を `folder_structure` の実際のディレクトリ構成に書き換える
+
+書き換えは `.claude/rules/coding.md` と `.github/instructions/coding.instructions.md` の両方に反映する。
+
 ### その他の基盤 skill
 
 同様のプレースホルダーや汎用記述が他の skill にあれば、同じ要領で書き換える。
@@ -102,8 +128,7 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 ## Phase 6: セットアップ専用 skill のアーカイブ提案
 
-セットアップ時にしか使わない skill は、開発ループに入ると不要になる。
-**ユーザーの承認を得てから** 整理する。絶対に自動で削除・移動しない。
+セットアップ時にしか使わない skill は、開発ループに入ると不要になる。ユーザーの承認を得てから整理する。絶対に自動で削除・移動しない。
 
 ### アーカイブ候補
 
@@ -111,7 +136,8 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 |---|---|
 | `architecture-definition` | 新規プロジェクト初期化専用。アーキテクチャ確定後は不要 |
 | `existing-project-to-docs` | 既存プロジェクト取り込み専用。docs 生成後は不要 |
-| `docs-driven-seed` | Phase 3 で project 専用 skill の種として使い終えたら不要 |
+| `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 が安定したら不要。ただしアーキテクチャが大きく変わる場合は再利用する可能性があるため、削除ではなくアーカイブを推奨 |
 
 ### 手順
@@ -139,4 +165,4 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 - 固定の architecture pack を増やしすぎない
 - project 専用 skill を先に考える
 - docs と architecture contract の両方を入力にする
-- **skill の削除・移動はユーザー承認なしに行わない**
+- skill の削除・移動はユーザー承認なしに行わない

package/spec-runner/templates/.github/skills/commit/SKILL.md

@@ -13,7 +13,7 @@ description: 変更を Conventional Commits 形式でコミットする。
 2. `git log --oneline -10` で直近のコミット履歴を確認する
 3. 変更内容に基づいてコミットメッセージを生成する
 4. 未ステージの場合は適切なファイルを `git add` する
-5. **機密情報チェック**: `git diff --cached` の内容を確認し、以下のパターンが含まれていないか検査する
+5. 機密情報チェック: `git diff --cached` の内容を確認し、以下のパターンが含まれていないか検査する
    - API キー、シークレットキー、パスワード、トークン、秘密鍵、接続文字列
    - `.env` ファイルの内容、認証情報ファイル（`credentials.json` 等）
    - 検出した場合はコミットを中止し、ユーザーに報告する

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

@@ -5,8 +5,7 @@ description: 既存機能の変更を docs 正本で進めるフローガイド
 
 # design-change
 
-既存機能の変更・修正を設計書駆動で進めるフローガイド。
-**フェーズを必ず順番通りに進める。ユーザーの承認なしにフェーズを先に進めない。**
+既存機能の変更・修正を設計書駆動で進めるフローガイド。フェーズは順番通りに進める。ユーザーの承認なしに先へ進めない。
 
 影響範囲のチェックリストは `references/影響範囲チェックリスト.md` を参照する。
 ADR テンプレートは `templates/90_ADR/ADRテンプレート.md` を使用する。
@@ -37,7 +36,7 @@ Phase 6: TDD → 実装 → 検証
 ## Phase 2: ADR 作成（必要時）
 
 1. アーキテクチャ、責務境界、保存方式、外部 IF などの意思決定が必要か判定する
-2. 必要な場合は **3 案を提示する**
+2. 必要な場合は 3 案を提示する
 3. 各案について概要・メリット・デメリット・適合性を示す
 4. ユーザーが案を決定する
 5. テンプレート `templates/90_ADR/ADRテンプレート.md` をコピーして生成する
@@ -63,9 +62,10 @@ Phase 6: TDD → 実装 → 検証
 
 ## Phase 4: 概要設計の修正
 
-1. `ユースケース一覧.md` / `システム全体俯瞰.md` / `ドメインモデル.md` / ADR を必要順に修正する
-2. 修正完了ごとにチェックリストを更新する
-3. 全概要設計の修正完了後、ユーザーに確認・承認を得る
+1. `ユースケース一覧.md` / `システム全体俯瞰.md` / ADR を必要順に修正する
+2. `style: ddd` の場合: `ドメインモデル.md` も必要に応じて修正する
+3. 修正完了ごとにチェックリストを更新する
+4. 全概要設計の修正完了後、ユーザーに確認・承認を得る
 
 ### 修正時の注意
 
@@ -74,11 +74,18 @@ Phase 6: TDD → 実装 → 検証
 
 ## Phase 5: 詳細設計の修正
 
+`style: ddd` の場合:
+
 1. `docs/03_詳細設計/01_ドメイン/**` のドメイン設計を修正する
 2. `docs/03_詳細設計/02_ユースケース/**` の UC 設計を修正する
 3. DB・外部サービスの変更がある場合は `docs/03_詳細設計/03_DB・外部サービス/**` を修正する
-4. frontmatter の `depends_on` / `maps_to` を更新する
-5. ユーザーに最終確認を得る
+
+`style: layered` の場合:
+
+1. `docs/03_詳細設計/01_ユースケース/**` の UC 設計を修正する
+2. DB・外部サービスの変更がある場合は `docs/03_詳細設計/02_DB・外部サービス/**` を修正する
+
+frontmatter の `depends_on` / `maps_to` を更新する。ユーザーに最終確認を得る。
 
 ## Phase 6: TDD → 実装 → 検証
 
@@ -91,6 +98,6 @@ Phase 6: TDD → 実装 → 検証
 
 ## 原則
 
-- **影響候補の洗い出しを ADR より先に行う**
-- **概要設計を先に直し、そのあと詳細設計を直す**
-- **frontmatter の更新を後回しにしない**
+- 影響候補の洗い出しを ADR より先に行う
+- 概要設計を先に直し、そのあと詳細設計を直す
+- frontmatter の更新を後回しにしない

package/spec-runner/templates/.github/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

@@ -1,66 +1,59 @@
 # 影響範囲チェックリスト
 
-design-change の Phase 3（影響ドキュメントの特定）で参照する。
+> このファイルはテンプレートです。`architecture-skill-development` でプロジェクトの変更カテゴリと詳細設計パスに合わせて書き換えてください。
+
+design-change の Phase 3（影響ドキュメントの確定）で参照する。
 変更の種類に応じて、修正が必要なドキュメントを網羅的に特定する。
 
 ## 変更種別ごとのチェック項目
 
-### エージェントの追加・変更・削除
+### ユースケース（UC）の追加・変更・削除
 
 | ドキュメント | パス | チェック |
 |------------|------|------|
-| ユースケース一覧 | `docs/02_概要設計/ユースケース一覧.md` | エージェントが担当する UC の追加・修正・削除を反映 |
-| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | エージェント構成・責務分割への影響 |
-| エージェント設計 | `docs/03_詳細設計/src/agents/{agent_name}/agent.md` | オーケストレーション、利用プラグイン、I/O の変更 |
-| ドメイン設計 | `docs/03_詳細設計/src/agents/{agent_name}/domain.md` | エンティティ・値オブジェクト・不変条件の変更 |
-| プロンプト設計 | `docs/03_詳細設計/src/agents/{agent_name}/prompts.md` | プロンプト構成・指示内容の変更 |
-| 設定 | `docs/03_詳細設計/src/agents/{agent_name}/config.md` | 設定パラメータ・閾値の変更 |
+| ユースケース一覧 | `docs/02_概要設計/ユースケース一覧.md` | UC の追加・修正・削除を反映 |
+| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | 責務分割・外部 IF への影響 |
+| UC 詳細設計 | `docs/03_詳細設計/<UC詳細設計パス>/UC-{日本語名}.md` | シーケンス・入出力・判断条件の変更 |
+| DB・外部サービス | `docs/03_詳細設計/<DB・外部サービスパス>/` | UC が利用するスキーマ・外部 IF への影響 |
 
-### ドメインモデル（エンティティ・値オブジェクト）の変更
+### ドメイン設計の変更（style: ddd のみ）
 
 | ドキュメント | パス | チェック |
 |------------|------|------|
-| ドメイン設計 | `docs/03_詳細設計/src/agents/{agent_name}/domain.md` | フィールド・ルール・不変条件の変更 |
-| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | 責務境界や共有概念への影響 |
-| プロンプト設計 | `docs/03_詳細設計/src/agents/{agent_name}/prompts.md` | ドメイン変更がプロンプトに影響する場合 |
-| データベース設計 | `docs/03_詳細設計/infrastructure/database.md` | テーブル構造・保存方針への影響 |
-| スキーマ定義 | `docs/03_詳細設計/infrastructure/schema.dbml` | カラム・型・制約の変更 |
-| スキル設計 | `docs/03_詳細設計/src/plugins/skills/{skill_name}/skill.md` | スキルの入出力・判定ロジックへの影響 |
-| ツール設計 | `docs/03_詳細設計/src/plugins/tools/{tool_name}/tool.md` | ツールの入出力への影響 |
+| ドメインモデル | `docs/02_概要設計/ドメインモデル.md` | 集約・境界コンテキストへの影響 |
+| ドメイン詳細設計 | `docs/03_詳細設計/<ドメイン詳細設計パス>/{ドメイン名}.md` | エンティティ・値オブジェクト・不変条件の変更 |
+| UC 詳細設計 | `docs/03_詳細設計/<UC詳細設計パス>/UC-{日本語名}.md` | ドメイン変更が UC フローに影響する場合 |
+| DB・外部サービス | `docs/03_詳細設計/<DB・外部サービスパス>/` | スキーマ・保存方針への影響 |
 
-### プラグイン（スキル・ツール）の追加・変更・削除
+### DB・外部サービスの変更
 
 | ドキュメント | パス | チェック |
 |------------|------|------|
-| スキル設計 | `docs/03_詳細設計/src/plugins/skills/{skill_name}/skill.md` | スキルの追加・修正・削除 |
-| ツール設計 | `docs/03_詳細設計/src/plugins/tools/{tool_name}/tool.md` | ツールの追加・修正・削除 |
-| エージェント設計 | `docs/03_詳細設計/src/agents/{agent_name}/agent.md` | 利用プラグイン一覧と呼び出し順の更新 |
-| ユースケース一覧 | `docs/02_概要設計/ユースケース一覧.md` | 対応する UC がある場合 |
-| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | プラグイン構成の変更が全体構造に影響する場合 |
+| DB・外部サービス | `docs/03_詳細設計/<DB・外部サービスパス>/` | テーブル定義・外部 API 仕様の変更 |
+| UC 詳細設計 | `docs/03_詳細設計/<UC詳細設計パス>/UC-{日本語名}.md` | 保存フロー・外部呼び出しへの影響 |
+| ドメイン詳細設計 | `docs/03_詳細設計/<ドメイン詳細設計パス>/{ドメイン名}.md` | ドメインモデルへの影響（style: ddd のみ） |
 
-### データベーススキーマの変更
+### アーキテクチャ・設計方針の変更
 
 | ドキュメント | パス | チェック |
 |------------|------|------|
-| データベース設計 | `docs/03_詳細設計/infrastructure/database.md` | テーブル定義・インデックス・リレーション |
-| スキーマ定義 | `docs/03_詳細設計/infrastructure/schema.dbml` | dbml ファイルの更新 |
-| ドメイン設計 | `docs/03_詳細設計/src/agents/{agent_name}/domain.md` | ドメインモデルへの影響 |
-| エージェント設計 | `docs/03_詳細設計/src/agents/{agent_name}/agent.md` | 保存フローやトランザクションへの影響 |
+| ADR | `docs/02_概要設計/90_ADR/全体/` | 横断的な決定を記録 |
+| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | 技術方針・全体構成の変更 |
+| 要件定義 | `docs/01_要件定義/要件定義.md` | 要件レベルの変更がある場合 |
+| 詳細設計一式 | `docs/03_詳細設計/**` | 方針変更の具体反映 |
 
-### アーキテクチャ・設計方針の変更
+### 要件の変更
 
 | ドキュメント | パス | チェック |
 |------------|------|------|
-| ADR | `docs/02_概要設計/90_ADR/` | 横断的な決定 |
-| ADR（ドメインローカル） | `docs/02_概要設計/<ドメイン>/90_ADR/` | 特定ドメインの決定 |
-| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | 技術方針・全体構成の変更 |
-| 要件定義 | `docs/01_要件定義/要件定義.md` | 要件レベルの変更がある場合 |
-| 詳細設計一式 | `docs/03_詳細設計/src/**` | 方針変更の具体反映 |
+| 要件定義 | `docs/01_要件定義/要件定義.md` | 要件・スコープの変更 |
+| ユビキタス言語辞書 | `docs/01_要件定義/ユビキタス言語辞書.md` | 用語の追加・変更 |
+| ユースケース一覧 | `docs/02_概要設計/ユースケース一覧.md` | 要件変更に伴う UC の追加・削除 |
+| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | スコープ変更による構成への影響 |
 
 ## 二次影響の確認観点
 
-- **ユースケース一覧 ↔ エージェント設計**: 一覧に記載の UC がエージェントとプラグインでカバーされているか
-- **システム全体俯瞰 ↔ 詳細設計**: 責務分割が `docs/03_詳細設計/src/**` に落ちているか
-- **ドメイン設計 ↔ DBスキーマ**: ドメインのフィールドが DB カラムと対応しているか
-- **schema.dbml ↔ database.md**: dbml と設計書の内容が一致しているか
+- **ユースケース一覧 ↔ 詳細設計**: 一覧に記載の UC が詳細設計でカバーされているか
+- **システム全体俯瞰 ↔ 詳細設計**: 責務分割が詳細設計に落ちているか
+- **ドメイン設計 ↔ DB スキーマ**: ドメインのフィールドが DB カラムと対応しているか（style: ddd のみ）
 - **frontmatter ↔ 実ファイル**: `depends_on` と `maps_to` が現状に追随しているか

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

@@ -5,10 +5,8 @@ description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジ
 
 # docs-driven-seed
 
-**DDD（ドメイン駆動設計）を採用するプロジェクト向け**の docs 正本開発フロー参照実装（種）。
-`architecture.yaml` の `style: ddd` のときに使う。レイヤード / CRUD 中心のプロジェクトは `simple-seed` を使う。
-
-**このスキルをそのまま使い続けない。`architecture-skill-development` で自プロジェクト専用スキルに育てることを前提とする。**
+> DDD を採用するプロジェクト向けの docs 正本開発フロー（種）。`architecture.yaml` の `style: ddd` で使う。レイヤード / CRUD 中心は `simple-seed` を使う。
+> このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てる。
 
 ## 全体フロー
 
@@ -65,7 +63,7 @@ docs/02_概要設計/
 ## Phase 3: ADR（必要時のみ）
 
 1. 設計判断が必要な場合だけ ADR を作る
-2. **提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する**
+2. 提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する
 3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
 
 | 対象 | 配置先 |
@@ -79,7 +77,7 @@ docs/02_概要設計/
 
 ## Phase 4: 詳細設計
 
-**ドメイン → UC → DB・外部サービス の順に設計する。**
+ドメイン → UC → DB・外部サービス の順に設計する。
 
 ### 4-1. ドメイン
 
@@ -122,6 +120,5 @@ docs/03_詳細設計/03_DB・外部サービス/
 
 ## 原則
 
-- **このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てることを前提とする**
-- **ドメインを先に設計し、UC はドメインを参照する形で書く**
-- **`maps_to` は必ず設定する。パス推定に頼らない**
+- ドメインを先に設計し、UC はドメインを参照する形で書く
+- `maps_to` は必ず設定する。パス推定に頼らない

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

@@ -10,7 +10,7 @@ spec_runner:
 
 # ドメインモデル
 
-集約と境界コンテキストの概念モデル。DBスキーマ・永続化の詳細はここに書かない。
+集約と境界コンテキストの概念モデル。DB スキーマ・永続化の詳細はここに書かない。
 
 ## 境界コンテキスト