spec-runner 1.1.17 → 1.1.18

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

@@ -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/.claude/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/.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

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

package/spec-runner/templates/.claude/skills/existing-project-to-docs/SKILL.md

@@ -34,18 +34,25 @@ Phase 5: architecture contract 化
 
 ## Phase 3: 概要設計の draft 化
 
-1. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を draft する
-2. `docs/02_概要設計/システム全体俯瞰.md` を作る
+1. `docs/02_概要設計/システム全体俯瞰.md` を作る
+2. `style: ddd` の場合: UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を draft する
 3. 必要なら ADR 候補も洗い出す（配置先は `90_ADR/全体/` / `ドメイン/` / `UC/` / `DB/`）
 4. ユーザーに確認・承認を得る
 
 ## Phase 4: 詳細設計の draft 化
 
+`style: ddd` の場合:
+
 1. ドメインごとにビジネスルール・集約を整理し `docs/03_詳細設計/01_ドメイン/{ドメイン名}.md` を draft する
 2. UC ごとに `docs/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を draft する
 3. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/03_DB・外部サービス/` を作る
-4. 各ファイルの `maps_to` に対応コードとテストを入れる
-5. ユーザーに確認・承認を得る
+
+`style: layered` の場合:
+
+1. UC ごとに `docs/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を draft する
+2. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/02_DB・外部サービス/` を作る
+
+各ファイルの `maps_to` に対応コードとテストを入れる。ユーザーに確認・承認を得る。
 
 ## Phase 5: architecture contract 化
 
@@ -55,6 +62,6 @@ Phase 5: architecture contract 化
 
 ## 原則
 
-- 既存コードを正として観測し、推測は明示する
-- docs は最初から完璧を目指さず、draft として起こす
+- 既存コードを正として観測する。推測する場合は明示する
+- docs は最初から完璧を目指さず draft として起こす
 - `maps_to` と `depends_on` を使って後続変更に耐える形へ整える

package/spec-runner/templates/.claude/skills/harness-engineering/SKILL.md

@@ -1,12 +1,11 @@
 ---
 name: harness-engineering
-description: AI 開発運用の skills・rules・agents・テンプレートを改善・保守するためのメタスキル。別の作業を進めた結果、繰り返し発生する手戻り、ルール不足、責務の曖昧さ、テンプレートの重複が見つかったときに使用する。通常の機能実装やアプリコードの TDD には使わない。
+description: skills・rules・agents・テンプレートを改善・保守するメタスキル。手戻り・ルール不足・責務の曖昧さ・テンプレート重複が繰り返し発生したときに使う。通常の機能実装や TDD には使わない。
 ---
 
 # harness-engineering
 
-skills・rules・agents・テンプレートを改善するためのメタスキル。
-**主目的の作業を先に進め、再利用価値のある改善が必要なときだけ使う。**
+skills・rules・agents・テンプレートを改善するためのメタスキル。主目的の作業を先に進め、再利用価値のある改善が必要なときだけ使う。
 
 ## 使うタイミング
 
@@ -24,8 +23,7 @@ skills・rules・agents・テンプレートを改善するためのメタスキ
 - アプリケーションコードに対する TDD
 - 単なる言い回しの微調整で済む変更
 
-**TDD はこのスキルの対象ではない。**
-TDD は `test-driven-development` スキルに従い、対象プロダクトのコード品質を上げるために行う。
+TDD はこのスキルの対象ではない。TDD は `test-driven-development` スキルに従い、対象プロダクトのコード品質を上げるために行う。
 
 ## 全体フロー
 
@@ -68,7 +66,7 @@ Phase 4: 影響範囲の反映確認
 
 ## Phase 3: skill / rule / agent / template の修正
 
-ファイルを作成・修正する前に **`.claude/rules/harness-formats.md`** を読み、フォーマットを確認する。
+ファイルを作成・修正する前に `.claude/rules/harness-formats.md` を読み、フォーマットを確認する。
 
 1. 対象ファイルを特定する
 2. 意図が変わらない最小差分で修正する
@@ -98,8 +96,8 @@ Phase 4: 影響範囲の反映確認
 
 ## 原則
 
-- **ハーネス改善は常時実行しない。必要なときだけ行う**
-- **主目的の作業を優先する**
-- **最小変更で改善する**
-- **新しい skill の追加は慎重に行う**
-- **TDD の責務を skill 改善と混同しない**
+- ハーネス改善は常時実行しない。必要なときだけ行う
+- 主目的の作業を優先する
+- 最小変更で改善する
+- 新しい skill の追加は慎重に行う
+- TDD の責務を skill 改善と混同しない

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

@@ -5,10 +5,8 @@ description: レイヤードアーキテクチャ / CRUD 中心のプロジェ
 
 # simple-seed
 
-**レイヤードアーキテクチャ / CRUD 中心のプロジェクト向け**の docs 正本開発フロー参照実装（種）。
-`architecture.yaml` の `style: layered` のときに使う。DDD が必要なプロジェクトは `docs-driven-seed` を使う。
-
-**このスキルをそのまま使い続けない。`architecture-skill-development` で自プロジェクト専用スキルに育てることを前提とする。**
+> レイヤードアーキテクチャ / CRUD 中心のプロジェクト向けの docs 正本開発フロー（種）。`architecture.yaml` の `style: layered` で使う。DDD が必要なプロジェクトは `docs-driven-seed` を使う。
+> このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てる。
 
 ## 全体フロー
 
@@ -33,7 +31,7 @@ Phase 5: TDD → 実装
 
 ## Phase 2: 概要設計
 
-テンプレート: `../docs-driven-seed/templates/02_概要設計/`（ユースケース一覧・システム全体俯瞰のみ）
+テンプレート: `templates/02_概要設計/`
 
 1. 要件定義からユースケースを洗い出す（Query / Command を意識）
 2. テンプレートをコピーして `docs/02_概要設計/ユースケース一覧.md` を作る
@@ -55,7 +53,7 @@ docs/02_概要設計/
 ## Phase 3: ADR（必要時のみ）
 
 1. 設計判断が必要な場合だけ ADR を作る
-2. **提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する**
+2. 提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する
 3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
 
 | 対象 | 配置先 |
@@ -68,7 +66,7 @@ docs/02_概要設計/
 
 ## Phase 4: 詳細設計
 
-**UC → DB・外部サービス の順に設計する。**
+UC → DB・外部サービス の順に設計する。
 
 ### 4-1. ユースケース
 
@@ -100,6 +98,5 @@ docs/03_詳細設計/02_DB・外部サービス/
 
 ## 原則
 
-- **このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てることを前提とする**
-- **ドメイン層は持たない。ビジネスロジックは UC / サービス層で表現する**
-- **`maps_to` は必ず設定する。パス推定に頼らない**
+- ドメイン層は持たない。ビジネスロジックは UC / サービス層で表現する
+- `maps_to` は必ず設定する。パス推定に頼らない

package/spec-runner/templates/.claude/skills/simple-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.use_case_list
+  maps_to:
+    - src/
+---
+
+# システム全体俯瞰
+
+## コンポーネント全体図
+
+```mermaid
+graph LR
+  User([ユーザー])
+  subgraph システム
+    {フロントエンド}
+    {バックエンド}
+  end
+  Ext([{外部サービス}])
+
+  User --> {フロントエンド}
+  {フロントエンド} --> {バックエンド}
+  {バックエンド} --> Ext
+```
+
+## 外部インターフェース
+
+| 外部システム | 方向 | プロトコル | 概要 |
+|------------|------|----------|------|
+| {外部システム名} | 受信 / 送信 | {HTTP / gRPC など} | {概要} |

package/spec-runner/templates/.claude/skills/simple-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_詳細設計/01_ユースケース/
+---
+
+# ユースケース一覧
+
+| UC ID | UC名 | 種別 | 概要 |
+|-------|------|------|------|
+| UC-{番号} | {UC名} | Command / Query | {概要} |

package/spec-runner/templates/.claude/skills/test-driven-development/SKILL.md

@@ -9,13 +9,13 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 テストを先に書く。失敗するのを確認する。通る最小のコードを書く。
 
-**中核原則:** テストが失敗するのを見ていないなら、そのテストが正しいものを検証しているか分からない。
+テストが失敗するのを見ていないなら、そのテストが正しいものを検証しているか分からない。
 
 ## いつ使うか
 
-**常に:** 新機能・バグ修正・リファクタリング・振る舞い変更
+常に使う: 新機能・バグ修正・リファクタリング・振る舞い変更
 
-**例外（ユーザーに確認する）:** 使い捨てプロトタイプ・生成コード・設定ファイル
+例外（ユーザーに確認する）: 使い捨てプロトタイプ・生成コード・設定ファイル
 
 ## 鉄の掟
 
@@ -28,7 +28,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 ## テスト戦略：テストピラミッド
 
-実装前にどのテスト種別を書くかを決める。迷ったら**単体テストから始める**。
+実装前にどのテスト種別を書くかを決める。迷ったら単体テストから始める。
 
 ```
         /\
@@ -55,7 +55,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 ### 結合テスト（Integration）
 
-**対象:** 複数モジュールの連携、DB・キャッシュ・外部APIとの境界
+**対象:** 複数モジュールの連携、DB・キャッシュ・外部 API との境界
 
 **書くとき:**
 - DB へのクエリ・永続化
@@ -91,7 +91,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 | バグ修正 | 最小レベルで再現テスト | — |
 
 **バグ修正の場合:** バグを再現できる最も低いレベルのテストを書く。
-単体で再現できるなら単体、DBが絡むなら結合。E2E で初めて再現するバグは、単体・結合に落とし込めないか検討する。
+単体で再現できるなら単体、DB が絡むなら結合。E2E で初めて再現するバグは、単体・結合に落とし込めないか検討する。
 
 ## テスト実行コマンド
 
@@ -145,7 +145,7 @@ test("ある入力に対して期待する出力を返す", () => {
 
 ### Verify RED - 失敗するのを確認する
 
-**必須。絶対に省略しない。**
+> 必須。絶対に省略しない。
 
 `@test-runner` エージェントに委任して実行する。
 
@@ -164,7 +164,7 @@ test("ある入力に対して期待する出力を返す", () => {
 
 ### Verify GREEN - 通るのを確認する
 
-**必須。**
+> 必須。
 
 `@test-runner` エージェントに委任して実行する。
 
@@ -178,8 +178,8 @@ test("ある入力に対して期待する出力を返す", () => {
 
 ### REFACTOR - 整理する
 
-Greenの後にのみ: 重複削除・命名改善・ヘルパ抽出。
-テストは常にGreenを維持する。新しい挙動は追加しない。
+Green の後にのみ: 重複削除・命名改善・ヘルパ抽出。
+テストは常に Green を維持する。新しい挙動は追加しない。
 
 ### 繰り返す
 
@@ -189,12 +189,12 @@ Greenの後にのみ: 重複削除・命名改善・ヘルパ抽出。
 
 - **最小**: 1つの振る舞いだけ。「and」が入るなら分割する
 - **明確**: テスト名が挙動を説明する
-- **意図が見える**: 望ましいAPIの使い方が伝わる
+- **意図が見える**: 望ましい API の使い方が伝わる
 
 ## テストのコメント
 
 テストコメントの規約は同梱のコーディング規約ファイルの「テストコメント規約」に従う。
-GREEN / REFACTORフェーズで書く実装コードにもビジネスロジックの意図をコメントする。
+GREEN / REFACTOR フェーズで書く実装コードにもビジネスロジックの意図をコメントする。
 
 ## テスト構成
 
@@ -256,18 +256,19 @@ tests/
 |------|------|
 | 「簡単すぎてテスト不要」 | 簡単でも壊れる。テストは30秒 |
 | 「あとでテストする」 | すぐ通るテストは何も証明しない |
-| 「今回だけTDDを飛ばす」 | 合理化である。止めること |
-| テスト前にコードを書いた | コードを削除し、TDDで最初からやり直す |
+| 「今回だけ TDD を飛ばす」 | 合理化である。止めること |
+| テスト前にコードを書いた | コードを削除し、TDD で最初からやり直す |
 | テストが最初から通る | 既存挙動をテストしている。テストを修正する |
 | なぜ失敗したか説明できない | テストが正しいか再検討する |
 | 全部 E2E で書いた | ピラミッドが逆転している。単体・結合に落とし込む |
 | 全部モックだらけ | 結合が強すぎる。または結合テストを書くべき |
 
-**どれか1つでも当てはまるなら: コードを削除し、TDDで最初からやり直す。**
+どれか 1 つでも当てはまるなら: コードを削除し、TDD で最初からやり直す。
 
 ## 完了時のレビュー
 
-実装完了後、以下のエージェントでレビューする:
+実装完了後、以下のエージェントを**同時に**起動してレビューする:
+- `@design-reviewer` — 設計書⇔実装の整合性チェック
 - `@code-reviewer` — コーディング規約への適合チェック
 
 ## 検証チェックリスト
@@ -285,13 +286,13 @@ tests/
 - [ ] モック方針がテスト種別に合っている
 - [ ] エッジケースとエラーをカバーした
 
-すべてにチェックできないならTDDを飛ばしている。やり直すこと。
+すべてにチェックできないなら TDD を飛ばしている。やり直すこと。
 
 ## 詰まったとき
 
 | 問題 | 解決 |
 |------|------|
-| どうテストすべきか分からない | 望むAPIを書き、まずアサーションを書く。ユーザーに相談する |
+| どうテストすべきか分からない | 望む API を書き、まずアサーションを書く。ユーザーに相談する |
 | どのテスト種別か迷う | 単体から始める。単体で書けないなら結合を検討する |
 | テストが複雑すぎる | 設計が複雑すぎる。インターフェースを簡素化する |
 | 何でもモック必須 | 結合が強すぎる。依存性注入を使う。または結合テストで書く |
@@ -302,7 +303,7 @@ tests/
 
 ```
 本番コード → 先にテストが存在し、失敗している
-それ以外 → TDDではない
+それ以外 → TDD ではない
 ```
 
 ユーザーの許可なしに例外はない。

package/spec-runner/templates/.github/agents/code-reviewer.agent.md

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

package/spec-runner/templates/.github/agents/design-reviewer.agent.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/.github/agents/impact-analyzer.agent.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/.github/agents/test-runner.agent.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` で行う
-- コードの修正は行わない（分析と提案のみ）
-- 日本語で報告する