spec-runner 1.4.1 → 1.5.0

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

@@ -5,9 +5,6 @@ description: 既存プロジェクトを読み解き、docs の正本と archite
 
 # existing-project-to-docs
 
-既存コードから docs を起こすフロー。
-コード、テスト、設定、インフラ定義を読み、`docs/` と `.spec-runner/` の最初の土台を作る。
-
 ## 全体フロー
 
 ```
@@ -21,9 +18,10 @@ Phase 5: architecture contract 化
 
 ## 前提ルール
 
-- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- docs は正本とし、各ドキュメントに `spec_runner`ヘッダーを付ける
 - `maps_to` は必ず設定する。パス推定に頼らない
 - 既存コードを正として観測する。推測する場合は明示する
+- `depends_on` を使って後続変更に耐える形へ整える
 - ユーザー承認なしに次フェーズへ進めない
 - `style: ddd` の場合: UC がドメインを使う。ドメインの中に UC を入れない
 - `style: ddd` の場合: 詳細設計は `01_ドメイン/` `02_ユースケース/` `03_DB・外部サービス/` の 3 層で構成する
@@ -50,20 +48,20 @@ Phase 5: architecture contract 化
 
 ## Phase 2: 要件とユースケースの抽出
 
-要件定義テンプレートは `simple-seed` に存在しないため、`style` に関わらず `docs-driven-seed` のテンプレートを使う。
+要件定義テンプレートは `simple-seed` に存在しないため、`style` に関わらず `ddd-seed` のテンプレートを使う。
 
 1. `current-system-inventory.md` を起点に、既存機能からユースケースを逆算する
-2. `.claude/skills/docs-driven-seed/templates/01_要件定義/要件定義.md` を使い `docs/01_要件定義/要件定義.md` を作る
-3. `.claude/skills/docs-driven-seed/templates/02_概要設計/ユースケース一覧.md` を使い `docs/02_概要設計/ユースケース一覧.md` を作る
-4. ドメイン用語が識別できたら `.claude/skills/docs-driven-seed/templates/01_要件定義/ユビキタス言語辞書.md` を使い `docs/01_要件定義/ユビキタス言語辞書.md` を作る
+2. `.claude/skills/ddd-seed/templates/01_要件定義/要件定義.md` を使い `docs/01_要件定義/要件定義.md` を作る
+3. `.claude/skills/ddd-seed/templates/02_概要設計/ユースケース一覧.md` を使い `docs/02_概要設計/ユースケース一覧.md` を作る
+4. ドメイン用語が識別できたら `.claude/skills/ddd-seed/templates/01_要件定義/ユビキタス言語辞書.md` を使い `docs/01_要件定義/ユビキタス言語辞書.md` を作る
 5. ユーザーに確認・承認を得る
 
 ## Phase 3: 概要設計
 
 `style: ddd` の場合:
 
-1. `.claude/skills/docs-driven-seed/templates/02_概要設計/システム全体俯瞰.md` を使い `docs/02_概要設計/システム全体俯瞰.md` を作る
-2. `.claude/skills/docs-driven-seed/templates/02_概要設計/ドメインモデル.md` を使い `docs/02_概要設計/ドメインモデル.md` を作る
+1. `.claude/skills/ddd-seed/templates/02_概要設計/システム全体俯瞰.md` を使い `docs/02_概要設計/システム全体俯瞰.md` を作る
+2. `.claude/skills/ddd-seed/templates/02_概要設計/ドメインモデル.md` を使い `docs/02_概要設計/ドメインモデル.md` を作る
 3. 必要なら ADR を作る（作成ルールは下記）
 
 `style: layered` の場合:
@@ -101,8 +99,8 @@ Phase 5: architecture contract 化
 
 `style: ddd` の場合（ドメイン → UC → DB・外部サービス の順に設計する）:
 
-1. `.claude/skills/docs-driven-seed/templates/03_詳細設計/01_ドメイン/{ドメイン名}.md` を使い、ドメインごとにビジネスルール・集約を整理し `docs/03_詳細設計/01_ドメイン/{ドメイン名}.md` を作る
-2. `.claude/skills/docs-driven-seed/templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を使い、UC ごとに `docs/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を作る（シーケンス図は Mermaid で埋め込む）
+1. `.claude/skills/ddd-seed/templates/03_詳細設計/01_ドメイン/{ドメイン名}.md` を使い、ドメインごとにビジネスルール・集約を整理し `docs/03_詳細設計/01_ドメイン/{ドメイン名}.md` を作る
+2. `.claude/skills/ddd-seed/templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を使い、UC ごとに `docs/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を作る（シーケンス図は Mermaid で埋め込む）
 3. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/03_DB・外部サービス/` を作る
 
 `style: layered` の場合（UC → DB・外部サービス の順に設計する）:
@@ -118,9 +116,3 @@ Phase 5: architecture contract 化
 2. 現状構造を project 専用 skill へ渡せる粒度に整える
 3. `architecture-skill-development` へ引き渡す
 
-## 原則
-
-- docs は正本。draft であっても `spec_runner` frontmatter とテンプレートを使う
-- `maps_to` は必ず設定する。パス推定に頼らない
-- 既存コードを正として観測する。推測する場合は明示する
-- `depends_on` を使って後続変更に耐える形へ整える

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

@@ -5,8 +5,6 @@ description: skills・rules・agents・テンプレートを改善・保守す
 
 # harness-engineering
 
-skills・rules・agents・テンプレートを改善するためのメタスキル。主目的の作業を先に進め、再利用価値のある改善が必要なときだけ使う。
-
 ## 使うタイミング
 
 以下のいずれかに当てはまるときに使う。
@@ -23,8 +21,6 @@ skills・rules・agents・テンプレートを改善するためのメタスキ
 - アプリケーションコードに対する TDD
 - 単なる言い回しの微調整で済む変更
 
-TDD はこのスキルの対象ではない。TDD は `test-driven-development` スキルに従い、対象プロダクトのコード品質を上げるために行う。
-
 ## 全体フロー
 
 ```
@@ -36,56 +32,29 @@ Phase 4: 影響範囲の反映確認
 
 ## Phase 1: 問題の抽出
 
-### 手順
-
 1. 今回の作業で何が詰まり、どこに無駄が出たかを整理する
 2. その問題が一時的なものか、再発しうる構造的な問題かを判定する
-3. 改善対象を特定する
-   - skill
-   - rule
-   - agent
-   - template
+3. 改善対象を特定する（skill / rule / agent / template）
 
-### 出力
-
-- 問題の要約
-- 再発条件
-- 変更対象の候補一覧
+**出力:** 問題の要約・再発条件・変更対象の候補一覧
 
 ## Phase 2: 対応方針の決定
 
-1. 最小変更で解決できる対象を選ぶ
+1. 最小変更で解決できる対象を選ぶ（まず既存の資産を直す。新しい skill は繰り返し使う独立したワークフローがある場合だけ追加する）
 2. 新しい skill を増やすべきか、既存 skill / rule / agent の修正で十分かを判断する
 3. Claude / Copilot の両テンプレートに影響するか確認する
 
-### 判断原則
-
-- まず既存の資産を直す
-- 新しい skill は、繰り返し使う独立したワークフローがある場合だけ追加する
-- 一時的な事情を恒久ルールにしない
-
 ## Phase 3: skill / rule / agent / template の修正
 
-ファイルを作成・修正する前に `.claude/rules/harness-formats.md` を読み、フォーマットを確認する。
+ファイルを作成・修正する前に `.claude/skills/harness-engineering/references/harness-format.md` を読み、フォーマットを確認する。
 
 1. 対象ファイルを特定する
-2. 意図が変わらない最小差分で修正する
-3. 片系だけでなく、対応するテンプレートも揃えて更新する
-   - `.claude/`
-   - `.github/`
+2. 意図が変わらない最小差分で修正する（役割の重複を増やさない。既存スキルの主要フローを壊さない。ユーザー承認が前提のフローは勝手に短絡しない）
+3. `.claude/` と `.github/` を対で更新する
 4. references や templates を参照している場合、必要な範囲だけ更新する
 
-### 修正時の注意
-
-- 役割の重複を増やさない
-- 既存スキルの主要フローを壊さない
-- ユーザー承認が前提のフローは勝手に短絡しない
-- アプリコード向けの TDD ルールを、このスキルの改善目的と混同しない
-
 ## Phase 4: 影響範囲の反映確認
 
-### 確認項目
-
 - 問題の原因に対して、変更箇所が直接効いているか
 - 関連する skill / rule / agent / template の記述が矛盾していないか
 - Claude / Copilot の対応ファイルに反映漏れがないか
@@ -93,11 +62,3 @@ Phase 4: 影響範囲の反映確認
 - skill 名・起動条件・使いどころを変更した場合、`CLAUDE.md` の記述と一致しているか
 - `CLAUDE.md` が肥大化していないか（20行超えたら `rules/` や `skills/` へ移動を検討する）
 - docs 構造・命名規則・node_id 体系に影響する変更の場合、`design-docs.md` と整合しているか
-
-## 原則
-
-- ハーネス改善は常時実行しない。必要なときだけ行う
-- 主目的の作業を優先する
-- 最小変更で改善する
-- 新しい skill の追加は慎重に行う
-- TDD の責務を skill 改善と混同しない

package/spec-runner/templates/.claude/{rules/harness-formats.md → skills/harness-engineering/references/harness-format.md}

@@ -4,8 +4,6 @@ description: rules・agents・skills ファイルのフォーマット定義。h
 
 # ハーネスファイルフォーマット
 
-`harness-engineering` や `architecture-skill-development` で rules / agents / skills を作成・修正するときは、このフォーマットに従う。
-
 ## rule ファイル（`.claude/rules/*.md`）
 
 ```markdown
@@ -22,7 +20,7 @@ paths: ["対象パス/**"]   # 省略すると全ファイルに適用
 - `description` は必須。Claude がルールを選択するときに使う
 - `paths` は省略可。省略すると `**` 相当（全ファイルに適用）
 - `integrations` に `github` が含まれる場合、対応する `.github/instructions/{name}.instructions.md` も作成・更新する
-  - `.github/` 版の frontmatter は `applyTo: "対象パス/**"` 形式に変換する
+  - `.github/` 版のヘッダーは `applyTo: "対象パス/**"` 形式に変換する
 
 ## agent ファイル（`.claude/agents/*.md`）
 
@@ -73,7 +71,7 @@ CLAUDE.md は全会話で常にコンテキストに読み込まれる。書く
 
 | 内容 | 正しい置き場所 |
 |------|--------------|
-| コーディング規約の詳細 | `.claude/rules/coding.md` |
+| コーディング規約の詳細 | `.claude/rules/code-style.md` |
 | フォーマット定義・手順 | `.claude/rules/*.md` |
 | スキルの詳細フロー | `.claude/skills/*/SKILL.md` |
 | 過去の決定・背景 | `docs/02_概要設計/90_ADR/` |
@@ -91,3 +89,11 @@ CLAUDE.md は全会話で常にコンテキストに読み込まれる。書く
   - 両方 → `.claude/` と `.github/` を対で更新する
 - `description` は「何をするか」より「いつ・なぜ使うか」を優先して書く
 - 新規作成時は既存ファイルを参考にフォーマットを確認してから作る
+
+## 書き方の原則
+
+- H1 は用途を示す。description の言い換えは書かない
+- H1 直下に説明文を置かない。description に書いたことを本文で繰り返さない
+- `（読み取り専用）` のような付記は H1 に入れない。tools の構成で表現する
+- agent のテンプレート注記（「このファイルはテンプレートです」）は agent ファイルに書かない。test-config.md に書く
+- agent の書き順: ヘッダー → H1 → 前提・入力（必要な場合のみ） → 手順 → 報告フォーマット

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

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

package/spec-runner/templates/.claude/skills/spec-probe/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: spec-probe
+description: 設計・要件の前提を一問一答で深掘りする。設計レビュー・要件定義・ADR 前に使う。
+---
+
+計画・設計・要件のあらゆる側面について、共通理解に達するまで容赦なくインタビューする。
+決定ツリーの各分岐を辿り、依存関係のある判断を一つずつ解決する。
+各質問に対して、推奨する答えも提示する。
+
+質問は一度に一つだけ行う。
+
+コードベースを読めば答えられる質問は、質問する代わりにコードを読む。

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

@@ -5,40 +5,27 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 # テスト駆動開発（TDD）
 
-## 概要
-
-テストを先に書く。失敗するのを確認する。通る最小のコードを書く。
-
-テストが失敗するのを見ていないなら、そのテストが正しいものを検証しているか分からない。
-
-## いつ使うか
-
 常に使う: 新機能・バグ修正・リファクタリング・振る舞い変更
-
 例外（ユーザーに確認する）: 使い捨てプロトタイプ・生成コード・設定ファイル
 
-## 鉄の掟
+**テストを先に書く。実装する。テストを実行して確認する。**
 
-```
-失敗するテストなしに本番コードを書かない
-```
+テスト実行コマンドと構成は `.claude/rules/test-config.md` を参照する。
 
-テストより先にコードを書いたなら削除して最初からやり直す。
-「参考として残す」も「テストを書きながら適応させる」も不可。
+## Step 1: テスト種別を決める
 
-## テスト戦略：テストピラミッド
+単体（多数）> 結合（中程度）> E2E（少数）の順で比率を保つ。迷ったら単体から始める。
 
-実装前にどのテスト種別を書くかを決める。迷ったら単体テストから始める。
+| 実装するもの | まず書くテスト | 追加で書くテスト |
+|---|---|---|
+| ロジック・計算 | 単体 | — |
+| DB 操作 | 結合 | — |
+| API エンドポイント | 結合 | 主要シナリオは E2E |
+| 複数サービスをまたぐフロー | 結合 | — |
+| ユーザー向け主要機能 | 単体＋結合 | E2E（絞る） |
+| バグ修正 | 最小レベルで再現テスト | — |
 
-```
-        /\
-       /E2E\        少数・遅い・ユーザーシナリオ全体
-      /------\
-     /  結合   \    中程度・モジュール間連携・外部境界
-    /----------\
-   /    単体    \   多数・高速・関数・クラス単位
-  /______________\
-```
+**バグ修正の場合:** バグを再現できる最も低いレベルのテストを書く。単体で再現できるなら単体、DB が絡むなら結合。E2E で初めて再現するバグは、単体・結合に落とし込めないか検討する。
 
 ### 単体テスト（Unit）
 
@@ -62,8 +49,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 - 外部サービス呼び出し（HTTP, メッセージキュー等）
 - 複数の集約をまたぐユースケース
 
-**外部依存の扱い:** 原則として実物を使う（テスト用 DB、テスト環境の外部サービス）。
-動かせない外部サービスのみスタブ／フェイクで代替する。
+**外部依存の扱い:** 原則として実物を使う（テスト用 DB、テスト環境の外部サービス）。動かせない外部サービスのみスタブ／フェイクで代替する。
 
 **速度目安:** 秒単位。PR ごとに実行できる。
 
@@ -79,121 +65,54 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 **速度目安:** 分単位。夜間や本番リリース前など頻度を落として実行。
 
-## テスト種別の選び方
-
-| 実装するもの | まず書くテスト | 追加で書くテスト |
-|---|---|---|
-| ロジック・計算 | 単体 | — |
-| DB 操作 | 結合 | — |
-| API エンドポイント | 結合 | 主要シナリオは E2E |
-| 複数サービスをまたぐフロー | 結合 | — |
-| ユーザー向け主要機能 | 単体＋結合 | E2E（絞る） |
-| バグ修正 | 最小レベルで再現テスト | — |
-
-**バグ修正の場合:** バグを再現できる最も低いレベルのテストを書く。
-単体で再現できるなら単体、DB が絡むなら結合。E2E で初めて再現するバグは、単体・結合に落とし込めないか検討する。
-
-## テスト実行コマンド
-
-`.claude/rules/testing.md` に記載されたコマンドを使う。
-
-## Red-Green-Refactor
-
-### RED - 失敗するテストを書く
-
-テスト種別を決めたうえで、起きてほしいことを示す最小のテストを1つ書く。
-
-```
-// 例（言語・フレームワークはプロジェクトに合わせる）
-test("ある入力に対して期待する出力を返す", () => {
-  // 準備 - テスト対象の入力データを用意する
-  const input = ...
-
-  // 実行 - テスト対象の関数を呼び出す
-  const result = targetFunction(input)
+## Step 2: テストを書く
 
-  // 判定 - 期待する出力と一致するか確認する
-  expect(result).toBe(expectedOutput)
-})
-```
+起きてほしいことを示す最小のテストを1つ書く。
 
 **要件:**
 - 1つの振る舞い
 - 明確なテスト名（振る舞いを説明する）
 - 実コード中心（不可避な場合のみモック）
+- 望ましい API の使い方が伝わる書き方にする
 
-### Verify RED - 失敗するのを確認する
+## Step 3: 実装する
 
-> 必須。絶対に省略しない。
+テストを通すコードを書く。実装コードにもビジネスロジックの意図をコメントする。
 
-`@test-runner` エージェントに委任して実行する。
+## Step 4: テストを実行して確認する
 
-- テストが**失敗する**（エラーではない）
-- 失敗メッセージが期待通り
-- **機能がないこと**が原因で失敗している（誤字等ではない）
-
-テストが通る → 既存挙動をテストしている。テストを修正する。
-テストがエラー → エラーを直して再実行し、「正しく失敗する」まで繰り返す。
-
-### GREEN - 通す最小のコードを書く
-
-テストを通すための最も単純なコードを書く。
-
-テストにない機能を足さない。他の改善やリファクタもここではしない。
-
-### Verify GREEN - 通るのを確認する
-
-> 必須。
-
-`@test-runner` エージェントに委任して実行する。
+`@run-tests` エージェントに委任して実行する。
 
 - テストが通る
 - **同種のテストが全て通る**（単体なら単体全件、結合なら結合全件）
 - 出力がクリーン（エラー、警告なし）
 - **カバレッジの未カバー行を確認** — 新規コードが未カバーなら追加テストを書く
 
-テストが落ちる → テストではなくコードを直す。
+テストが落ちる → 実装を直す。
 他のテストが落ちる → 直ちに修正する。
 
-### REFACTOR - 整理する
-
-Green の後にのみ: 重複削除・命名改善・ヘルパ抽出。
-テストは常に Green を維持する。新しい挙動は追加しない。
+## Step 5: 整理する
 
-### 繰り返す
+重複削除・命名改善・ヘルパ抽出。テストは通ったまま維持する。新しい挙動は追加しない。
 
-次の機能のために、次の失敗するテストを書く。
+**→ Step 2 へ戻り、次の振る舞いのテストを書く。**
 
-## よいテスト
-
-- **最小**: 1つの振る舞いだけ。「and」が入るなら分割する
-- **明確**: テスト名が挙動を説明する
-- **意図が見える**: 望ましい API の使い方が伝わる
-
-## テストのコメント
-
-テストコメントの規約は同梱のコーディング規約ファイルの「テストコメント規約」に従う。
-GREEN / REFACTOR フェーズで書く実装コードにもビジネスロジックの意図をコメントする。
+---
 
-## テスト構成
+## 参考
 
-```
-tests/
-  unit/        # 単体テスト（src/ と同じ構造を鏡写し）
-  integration/ # 結合テスト
-  e2e/         # E2E テスト
-```
+### テストのコメント規約
 
-テストファイルは `src/` と同じディレクトリ構造を各テスト種別のディレクトリ内に鏡写しにする。
+`.claude/rules/code-style.md` のテストコメント規約に従う。
 
-## fixture / テストデータの活用
+### fixture / テストデータ
 
 - テストごとに独立した状態を持つ
 - テストデータ生成にはヘルパ関数を定義して一貫性を保つ
-- 外部サービス（API・メール・ストレージ等）は必要な場合のみモックする
+- テストデータはドメインモデルの全フィールドを含める
 - 結合テスト用のシードデータは `tests/integration/fixtures/` に置く
 
-## モックのルール
+### モックのルール
 
 モックは分離の手段であり、テスト対象ではない。
 
@@ -213,61 +132,13 @@ tests/
 **原則:**
 - 実コンポーネントの**出力**をテストする。モックの呼び出し確認だけにアサートしない
 - 本番クラスにテスト専用メソッドを追加しない → fixtureやテストユーティリティに置く
-- テストデータはドメインモデルの全フィールドを含める
 
-**赤信号（モックをやめて設計を見直す）:**
+**設計見直しのサイン:**
 - モック準備がテスト本体より長い
 - モックを外すとテストが成立しない
 - なぜモックが必要か説明できない
 
-## なぜ順序が重要か
-
-実装後のテストはすぐ通る。すぐ通ることは何も証明しない:
-- 間違ったものをテストしているかもしれない
-- 実装に引きずられて挙動ではなく実装をテストしがち
-- バグを捕まえる力を見ていない
-
-テストファーストは、テストが本当に何かを検証していることを「失敗」で証明する。
-
-## よくある合理化と赤信号
-
-| 兆候 | 問題 |
-|------|------|
-| 「簡単すぎてテスト不要」 | 簡単でも壊れる。テストは30秒 |
-| 「あとでテストする」 | すぐ通るテストは何も証明しない |
-| 「今回だけ TDD を飛ばす」 | 合理化である。止めること |
-| テスト前にコードを書いた | コードを削除し、TDD で最初からやり直す |
-| テストが最初から通る | 既存挙動をテストしている。テストを修正する |
-| なぜ失敗したか説明できない | テストが正しいか再検討する |
-| 全部 E2E で書いた | ピラミッドが逆転している。単体・結合に落とし込む |
-| 全部モックだらけ | 結合が強すぎる。または結合テストを書くべき |
-
-どれか 1 つでも当てはまるなら: コードを削除し、TDD で最初からやり直す。
-
-## 完了時のレビュー
-
-実装完了後、以下のエージェントを**同時に**起動してレビューする:
-- `@design-reviewer` — 設計書⇔実装の整合性チェック
-- `@code-reviewer` — コーディング規約への適合チェック
-
-## 検証チェックリスト
-
-完了宣言の前に:
-
-- [ ] 実装前にテスト種別（単体・結合・E2E）を決めた
-- [ ] 新規関数／メソッドにテストがある
-- [ ] 各テストは実装前に失敗するのを見た
-- [ ] 期待通りの理由で失敗した（機能不足であり誤字ではない）
-- [ ] 通す最小コードを書いた
-- [ ] 同種のテストが全件通る
-- [ ] 出力がクリーン（エラー、警告なし）
-- [ ] カバレッジを確認し、新規コードの未カバー行がない
-- [ ] モック方針がテスト種別に合っている
-- [ ] エッジケースとエラーをカバーした
-
-すべてにチェックできないなら TDD を飛ばしている。やり直すこと。
-
-## 詰まったとき
+### 詰まったとき
 
 | 問題 | 解決 |
 |------|------|
@@ -277,12 +148,3 @@ tests/
 | 何でもモック必須 | 結合が強すぎる。依存性注入を使う。または結合テストで書く |
 | セットアップが巨大 | fixtureやテストユーティリティに抽出する。それでも大きいなら設計を簡素化する |
 | E2E が遅すぎる | 単体・結合に落とし込めるか検討する |
-
-## 最終ルール
-
-```
-本番コード → 先にテストが存在し、失敗している
-それ以外 → TDD ではない
-```
-
-ユーザーの許可なしに例外はない。

package/spec-runner/templates/{.claude/agents/impact-analyzer.md → .github/agents/analyze-impact.agent.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/.github/agents/{code-reviewer.agent.md → review-code.agent.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. `.github/instructions/coding.instructions.md` を読み、チェック項目を把握する
+2. `.github/instructions/code-style.instructions.md` を読み、チェック項目を把握する
 3. 変更されたソースファイルを読み込む
 4. チェック項目に照らして違反を検出する
 5. 違反を報告する

package/spec-runner/templates/{.claude/agents/design-reviewer.md → .github/agents/review-design.agent.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/.github/agents/{test-runner.agent.md → run-tests.agent.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. `.github/instructions/testing.instructions.md` を読んでテスト実行コマンドを確認する
+3. `.github/instructions/test-config.instructions.md` を読んでテスト実行コマンドを確認する
 4. テストを実行する:
    - 対象テストが明確な場合: テストコマンド + `<test-file> -v`
    - 全体実行が必要な場合: 全テストコマンド + `-v`
-4. 結果を分析する
+5. 結果を分析する
 
 ## 失敗時の分析