spec-runner 1.1.18 → 1.3.0

package/README.md

@@ -1,8 +1,12 @@
 # spec-runner
 
-`spec-runner` は、`docs/` を正本にして開発を進める運用ハーネスを、**Claude Code（`.claude/`）** と **GitHub Copilot（`.github/`）** に導入するインストーラ。
+AI は設計を飛ばして実装に走る。`docs/` があっても読まないし、仕様が曖昧なまま動くコードを返す。
 
-主線は `要件定義 -> 概要設計 -> 詳細設計 -> TDD -> 実装`。rules / agents / skills はその流れを安定運用するために配る。
+`spec-runner` はそれを防ぐ。**`docs/` を正本にした開発フロー**を AI に守らせるための rules / agents / skills を、**Claude Code（`.claude/`）** と **GitHub Copilot（`.github/`）** にインストーラ一発で配る。
+
+フローは `要件定義 → 概要設計 → 詳細設計 → TDD → 実装`。AI はこの順序で docs を読み書きしながら進み、設計なしに実装フェーズへ進めない。
+
+インストール後は `architecture-skill-development` を使ってプロジェクトのアーキテクチャを定義し、そこから **プロジェクト専用 skill** を生やす。汎用 skill はその土台にすぎない。
 
 ## インストール
 
@@ -42,15 +46,22 @@ curl -sSL https://raw.githubusercontent.com/TEEE88/spec-runner/main/install.sh |
 
 ### 同梱するベース skill
 
+**セットアップ用**（プロジェクト初期に使い、完了後はアーカイブする）
+
 - `architecture-definition`: 新規プロジェクトで docs と architecture contract を起こす
 - `existing-project-to-docs`: 既存コードから docs の draft と構造化情報を起こす
 - `architecture-skill-development`: architecture contract から project 専用 skill を育てる
-- `plugin-development`: プラグイン型アーキテクチャ向けの reference workflow
-- `design-change`: 変更要求に対して影響調査 -> ADR -> 設計修正 -> TDD で進める
+- `docs-driven-seed`: DDD 向けの project 専用 skill の種（`style: ddd` のとき）
+- `simple-seed`: レイヤードアーキテクチャ向けの project 専用 skill の種（`style: layered` のとき）
+
+**開発ループ用**（日常的に使う）
+
+- `design-change`: 変更要求に対して影響調査 → ADR → 設計修正 → TDD で進める
 - `test-driven-development`: アプリケーションコード向けの TDD を徹底する
 - `harness-engineering`: rules / agents / skills / templates 自体を改善する
+- `commit`: コミットメッセージの生成とコミット実行
 
-`docs/` や `.spec-runner/` の中身は、導入後にこれらの skill を使ってプロジェクトごとに作る。
+`docs/` の中身は、導入後にこれらの skill を使ってプロジェクトごとに作る。
 
 ## 推奨フロー
 
@@ -87,13 +98,9 @@ SPEC_RUNNER_FORCE=1 npx spec-runner
 - `spec-runner/templates/.claude/`
 - `spec-runner/templates/.github/`
 
-### 構想メモ
-
-- `docs/ハーネスエンジニアリング構想.md`
-
 ## バージョン運用ルール
 
-- このリポジトリでは **コミットごとに `package.json` の `version` を更新**する
+- **開発のたびに `package.json` の `version` を更新してからコミットする**
 - バージョンは原則 SemVer に従い、迷う場合はパッチを 1 つ上げる
 
 ## ライセンス

package/package.json

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

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

@@ -15,9 +15,10 @@ model: sonnet
 
 1. `git diff --name-only` で変更ファイルを確認する
 2. 変更ファイルに対応するテストファイルを特定する（`tests/` 配下の同構造）
-3. テストを実行する:
-   - 対象テストが明確な場合: `<your-test-command> <test-file> -v`
-   - 全体実行が必要な場合: `<your-test-command> -v`
+3. `.claude/rules/testing.md` を読んでテスト実行コマンドを確認する
+4. テストを実行する:
+   - 対象テストが明確な場合: テストコマンド + `<test-file> -v`
+   - 全体実行が必要な場合: 全テストコマンド + `-v`
 4. 結果を分析する
 
 ## 失敗時の分析

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

@@ -24,10 +24,22 @@ paths: ["src/**", "tests/**"]
 
 ## コメント
 
+### 原則（全プロジェクト共通）
+
 - **言語**: 日本語
-- **インラインコメント**: ビジネスロジックの「なぜ」を説明する場合のみ。処理内容の「何」は書かない
 - **変更履歴コメント禁止**: 変更経緯はコードに書かない。git の commit message で管理する
 
+### プロジェクト固有の決定事項
+
+> `architecture-skill-development` で以下をチームで合意し、`<...>` を書き換える。
+
+- **インラインコメント（なぜ）**: `<ビジネスロジックの判断理由は必ず書く / 任意>`
+- **処理ブロックのコメント（何）**: `<禁止（命名で表現する） / 複雑なフローに限り許可>`
+- **ファイル / モジュールレベルのコメント**: `<必須 / 任意 / 不要>`
+- **関数・クラスの docコメント**: `<常に必須 / 公開 API のみ / 複雑なものだけ / 不要>`
+- **TODO / FIXME マーカー**: `<許可する（課題管理ツールの番号を添える） / 禁止>`
+- **セクション区切りコメント**: `<許可する場合はフォーマットを記載 / 禁止>`
+
 ## 言語・型固有ルール
 
 > このセクションを言語・フレームワークに合わせて書き換える。

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

@@ -45,10 +45,10 @@ spec_runner:
 |------|-------------|-----|
 | 要件定義 | `requirement.{名前}` | `requirement.要件定義` |
 | システム全体俯瞰 | `overview.system_context` | — |
-| ドメインモデル | `overview.domain_model` | — |
+| ドメインモデル（style: ddd のみ） | `overview.domain_model` | — |
 | ユースケース一覧 | `overview.use_case_list` | — |
 | ADR | `overview.adr.{slug}` | `overview.adr.0404-ドメイン-注文集約` |
-| ドメイン詳細設計 | `detail.domain.{ドメイン名}` | `detail.domain.注文` |
+| ドメイン詳細設計（style: ddd のみ） | `detail.domain.{ドメイン名}` | `detail.domain.注文` |
 | UC 詳細設計 | `detail.usecase.{UC名}` | `detail.usecase.注文確定` |
 | DB・外部サービス | `detail.db.{名前}` | `detail.db.スキーマ定義` |
 
@@ -57,12 +57,13 @@ spec_runner:
 | 対象 | 規則 | 例 |
 |------|------|-----|
 | `docs/01_要件定義` | 日本語 | `要件定義.md`, `ユビキタス言語辞書.md` |
-| `docs/02_概要設計` | 日本語 | `ユースケース一覧.md`, `システム全体俯瞰.md`, `ドメインモデル.md` |
+| `docs/02_概要設計` | 日本語 | `ユースケース一覧.md`, `システム全体俯瞰.md` |
+| `docs/02_概要設計`（style: ddd のみ） | 日本語 | `ドメインモデル.md` |
 | `docs/02_概要設計/90_ADR/{対象}/` | `mmdd-{日本語タイトル}.md` | `0404-注文集約の設計.md` |
 | `{対象}` の選択肢 | `全体` / `ドメイン` / `UC` / `DB` | — |
-| `docs/03_詳細設計/01_ドメイン` | 日本語 | `注文.md`, `在庫.md` |
-| `docs/03_詳細設計/02_ユースケース` | `UC-{日本語名}.md` | `UC-注文確定.md` |
-| `docs/03_詳細設計/03_DB・外部サービス` | 日本語 | `スキーマ定義.dbml`, `外部サービス.md` |
+| `docs/03_詳細設計/01_ドメイン`（style: ddd のみ） | 日本語 | `注文.md`, `在庫.md` |
+| `docs/03_詳細設計/02_ユースケース`（style: ddd） / `01_ユースケース`（style: layered） | `UC-{日本語名}.md` | `UC-注文確定.md` |
+| `docs/03_詳細設計/03_DB・外部サービス`（style: ddd） / `02_DB・外部サービス`（style: layered） | 日本語 | `スキーマ定義.dbml`, `外部サービス.md` |
 
 ## ADR
 
@@ -84,7 +85,7 @@ spec_runner:
 - 「関連ドキュメント」セクションを設計書に作らない。依存関係は frontmatter の `depends_on` で管理する
 - 「スケジュール」セクションを設計書に作らない。進捗管理は設計書の責務ではない
 
-## ドメインモデルとデータモデルの分離
+## ドメインモデルとデータモデルの分離（style: ddd のみ）
 
 ドメインモデルとデータモデルは別物であり、置き場所も内容も分ける。
 

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

@@ -0,0 +1,39 @@
+---
+description: テスト実行コマンドと種別構成。test-driven-development スキルと test-runner エージェントの両方がここを参照する。
+paths: ["src/**", "tests/**"]
+---
+
+# テスト実行コマンド
+
+> このファイルは `architecture-skill-development` でプロジェクト固有のコマンドに書き換えてください。
+
+## 実行コマンド
+
+```bash
+# 単体テスト（高速・毎回実行）
+<your-unit-test-command>
+
+# 結合テスト
+<your-integration-test-command>
+
+# E2E テスト
+<your-e2e-test-command>
+
+# 全テスト
+<your-all-test-command>
+
+# 特定ファイル
+<your-test-command> <test-file>
+
+# カバレッジ計測
+<your-test-command> --coverage
+```
+
+## テスト構成
+
+```
+tests/
+  unit/        # 単体テスト（src/ と同じ構造を鏡写し）
+  integration/ # 結合テスト
+  e2e/         # E2E テスト
+```

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

@@ -65,11 +65,11 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 > 以降の書き換えはすべて `architecture.yaml` の `integrations` に従う。`claude` のみなら `.claude/` だけ、`github` のみなら `.github/` だけ、両方なら対で更新する。
 
-### test-driven-development の書き換え
+### testing.md の書き換え
 
-`architecture.yaml` の `testing_policy` と `language` を参照して、以下を実際の値に置き換える。
+`rules/testing.md`（GitHub Copilot は `instructions/testing.instructions.md`）はテスト実行コマンドの単一ソースとして `test-driven-development` スキルと `test-runner` エージェントの両方から参照される。`architecture.yaml` の `testing_policy` を参照して書き換える。
 
-1. **テスト実行コマンド**: `<your-test-command>` を実際のコマンドに書き換える
+1. **テスト実行コマンド**: `<your-unit-test-command>` / `<your-integration-test-command>` 等を実際のコマンドに書き換える
 
    例:
    ```bash
@@ -83,20 +83,19 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
    docker compose run --rm test pytest --cov=. --cov-report=term-missing
    ```
 
-2. **コード例**: 言語・フレームワークに合わせて RED / GREEN の例を書き直す
-
-3. **fixture / テストデータ**: このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
-
-4. **モックのルール**: 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
+2. **テスト構成**: `tests/` のディレクトリ構成が実態と異なる場合は書き換える
 
 上記の `integrations` ルールに従って反映する。
 
-### test-runner エージェントの書き換え
+### test-driven-development の書き換え（テストコマンド以外）
 
-`architecture.yaml` の `testing_policy` を参照して、以下を実際の値に置き換える。
+`architecture.yaml` の `language` を参照して、以下を実際の値に置き換える。
 
-1. **テスト実行コマンド**: `<your-test-command>` を実際のコマンドに書き換える
-2. **説明文**: 実行環境（Docker / ローカル など）が分かるよう補足する
+1. **コード例**: 言語・フレームワークに合わせて RED / GREEN の例を書き直す
+2. **fixture / テストデータ**: このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
+3. **モックのルール**: 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
+
+上記の `integrations` ルールに従って反映する。
 
 ### 影響範囲チェックリストの書き換え
 
@@ -110,8 +109,10 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 `architecture.yaml` の `language` と `folder_structure` を参照して、以下を実際の値に置き換える。
 
 1. **命名規則**: 言語の慣習に合わせてテーブルの規則・例を書き換える
-2. **言語・型固有ルール**: `<your-language-and-type-rules>` を言語・フレームワークに合わせた具体的なルールに書き換える
-3. **プロジェクト構造**: `<your-project-structure>` を `folder_structure` の実際のディレクトリ構成に書き換える
+2. **コメント規約**: `## コメント` の「プロジェクト固有の決定事項」をユーザーと合意してから書き換える
+   - インラインコメント（なぜ）・処理ブロック（何）・docコメント・TODO/FIXME・セクション区切りの各方針を決定する
+3. **言語・型固有ルール**: `<your-language-and-type-rules>` を言語・フレームワークに合わせた具体的なルールに書き換える
+4. **プロジェクト構造**: `<your-project-structure>` を `folder_structure` の実際のディレクトリ構成に書き換える
 
 上記の `integrations` ルールに従って反映する。
 
@@ -148,6 +149,7 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 4. `.spec-runner/` の不要ファイルも整理する
    - `intake/current-system-inventory.md` — docs に昇格済みなら削除してよい
    - `architecture/architecture.yaml` — project 専用 skill が完成し、参照不要になったら削除してよい
+   - `scripts/scan.js` — **削除しない**。`@impact-analyzer` が常時依存しているため
 5. `CLAUDE.md` を更新する
    - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
    - 作成した project 専用 skill の名前と使いどころを記載する

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

@@ -95,28 +95,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 ## テスト実行コマンド
 
-> このスキルはテンプレートとして配布されます。
-> `architecture-skill-development` を使ってプロジェクト固有のコマンドに書き換えてください。
-
-```bash
-# 単体テスト（高速・毎回実行）
-<your-unit-test-command>
-
-# 結合テスト
-<your-integration-test-command>
-
-# E2E テスト
-<your-e2e-test-command>
-
-# 全テスト
-<your-test-command>
-
-# 特定ファイル
-<your-test-command> <test-file>
-
-# カバレッジ計測
-<your-test-command> --coverage
-```
+`.claude/rules/testing.md` に記載されたコマンドを使う。
 
 ## Red-Green-Refactor
 

package/spec-runner/templates/.github/agents/test-runner.agent.md

@@ -15,9 +15,10 @@ model: sonnet
 
 1. `git diff --name-only` で変更ファイルを確認する
 2. 変更ファイルに対応するテストファイルを特定する（`tests/` 配下の同構造）
-3. テストを実行する:
-   - 対象テストが明確な場合: `<your-test-command> <test-file> -v`
-   - 全体実行が必要な場合: `<your-test-command> -v`
+3. `.github/instructions/testing.instructions.md` を読んでテスト実行コマンドを確認する
+4. テストを実行する:
+   - 対象テストが明確な場合: テストコマンド + `<test-file> -v`
+   - 全体実行が必要な場合: 全テストコマンド + `-v`
 4. 結果を分析する
 
 ## 失敗時の分析

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

@@ -23,10 +23,22 @@ applyTo: "src/**,tests/**"
 
 ## コメント
 
+### 原則（全プロジェクト共通）
+
 - **言語**: 日本語
-- **インラインコメント**: ビジネスロジックの「なぜ」を説明する場合のみ。処理内容の「何」は書かない
 - **変更履歴コメント禁止**: 変更経緯はコードに書かない。git の commit message で管理する
 
+### プロジェクト固有の決定事項
+
+> `architecture-skill-development` で以下をチームで合意し、`<...>` を書き換える。
+
+- **インラインコメント（なぜ）**: `<ビジネスロジックの判断理由は必ず書く / 任意>`
+- **処理ブロックのコメント（何）**: `<禁止（命名で表現する） / 複雑なフローに限り許可>`
+- **ファイル / モジュールレベルのコメント**: `<必須 / 任意 / 不要>`
+- **関数・クラスの docコメント**: `<常に必須 / 公開 API のみ / 複雑なものだけ / 不要>`
+- **TODO / FIXME マーカー**: `<許可する（課題管理ツールの番号を添える） / 禁止>`
+- **セクション区切りコメント**: `<許可する場合はフォーマットを記載 / 禁止>`
+
 ## 言語・型固有ルール
 
 > このセクションを言語・フレームワークに合わせて書き換える。

package/spec-runner/templates/.github/instructions/design-docs.instructions.md

@@ -44,10 +44,10 @@ spec_runner:
 |------|-------------|-----|
 | 要件定義 | `requirement.{名前}` | `requirement.要件定義` |
 | システム全体俯瞰 | `overview.system_context` | — |
-| ドメインモデル | `overview.domain_model` | — |
+| ドメインモデル（style: ddd のみ） | `overview.domain_model` | — |
 | ユースケース一覧 | `overview.use_case_list` | — |
 | ADR | `overview.adr.{slug}` | `overview.adr.0404-ドメイン-注文集約` |
-| ドメイン詳細設計 | `detail.domain.{ドメイン名}` | `detail.domain.注文` |
+| ドメイン詳細設計（style: ddd のみ） | `detail.domain.{ドメイン名}` | `detail.domain.注文` |
 | UC 詳細設計 | `detail.usecase.{UC名}` | `detail.usecase.注文確定` |
 | DB・外部サービス | `detail.db.{名前}` | `detail.db.スキーマ定義` |
 
@@ -56,12 +56,13 @@ spec_runner:
 | 対象 | 規則 | 例 |
 |------|------|-----|
 | `docs/01_要件定義` | 日本語 | `要件定義.md`, `ユビキタス言語辞書.md` |
-| `docs/02_概要設計` | 日本語 | `ユースケース一覧.md`, `システム全体俯瞰.md`, `ドメインモデル.md` |
+| `docs/02_概要設計` | 日本語 | `ユースケース一覧.md`, `システム全体俯瞰.md` |
+| `docs/02_概要設計`（style: ddd のみ） | 日本語 | `ドメインモデル.md` |
 | `docs/02_概要設計/90_ADR/{対象}/` | `mmdd-{日本語タイトル}.md` | `0404-注文集約の設計.md` |
 | `{対象}` の選択肢 | `全体` / `ドメイン` / `UC` / `DB` | — |
-| `docs/03_詳細設計/01_ドメイン` | 日本語 | `注文.md`, `在庫.md` |
-| `docs/03_詳細設計/02_ユースケース` | `UC-{日本語名}.md` | `UC-注文確定.md` |
-| `docs/03_詳細設計/03_DB・外部サービス` | 日本語 | `スキーマ定義.dbml`, `外部サービス.md` |
+| `docs/03_詳細設計/01_ドメイン`（style: ddd のみ） | 日本語 | `注文.md`, `在庫.md` |
+| `docs/03_詳細設計/02_ユースケース`（style: ddd） / `01_ユースケース`（style: layered） | `UC-{日本語名}.md` | `UC-注文確定.md` |
+| `docs/03_詳細設計/03_DB・外部サービス`（style: ddd） / `02_DB・外部サービス`（style: layered） | 日本語 | `スキーマ定義.dbml`, `外部サービス.md` |
 
 ## ADR
 
@@ -83,7 +84,7 @@ spec_runner:
 - 「関連ドキュメント」セクションを設計書に作らない。依存関係は frontmatter の `depends_on` で管理する
 - 「スケジュール」セクションを設計書に作らない。進捗管理は設計書の責務ではない
 
-## ドメインモデルとデータモデルの分離
+## ドメインモデルとデータモデルの分離（style: ddd のみ）
 
 ドメインモデルとデータモデルは別物であり、置き場所も内容も分ける。
 

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

@@ -0,0 +1,38 @@
+---
+applyTo: "src/**,tests/**"
+---
+
+# テスト実行コマンド
+
+> このファイルは `architecture-skill-development` でプロジェクト固有のコマンドに書き換えてください。
+
+## 実行コマンド
+
+```bash
+# 単体テスト（高速・毎回実行）
+<your-unit-test-command>
+
+# 結合テスト
+<your-integration-test-command>
+
+# E2E テスト
+<your-e2e-test-command>
+
+# 全テスト
+<your-all-test-command>
+
+# 特定ファイル
+<your-test-command> <test-file>
+
+# カバレッジ計測
+<your-test-command> --coverage
+```
+
+## テスト構成
+
+```
+tests/
+  unit/        # 単体テスト（src/ と同じ構造を鏡写し）
+  integration/ # 結合テスト
+  e2e/         # E2E テスト
+```

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

@@ -65,11 +65,11 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 > 以降の書き換えはすべて `architecture.yaml` の `integrations` に従う。`claude` のみなら `.claude/` だけ、`github` のみなら `.github/` だけ、両方なら対で更新する。
 
-### test-driven-development の書き換え
+### testing.md の書き換え
 
-`architecture.yaml` の `testing_policy` と `language` を参照して、以下を実際の値に置き換える。
+`instructions/testing.instructions.md` はテスト実行コマンドの単一ソースとして `test-driven-development` スキルと `test-runner` エージェントの両方から参照される。`architecture.yaml` の `testing_policy` を参照して書き換える。
 
-1. **テスト実行コマンド**: `<your-test-command>` を実際のコマンドに書き換える
+1. **テスト実行コマンド**: `<your-unit-test-command>` / `<your-integration-test-command>` 等を実際のコマンドに書き換える
 
    例:
    ```bash
@@ -83,20 +83,19 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
    docker compose run --rm test pytest --cov=. --cov-report=term-missing
    ```
 
-2. **コード例**: 言語・フレームワークに合わせて RED / GREEN の例を書き直す
+2. **テスト構成**: `tests/` のディレクトリ構成が実態と異なる場合は書き換える
 
-3. **fixture / テストデータ**: このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
+上記の `integrations` ルールに従って反映する。
 
-4. **モックのルール**: 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
+### test-driven-development の書き換え（テストコマンド以外）
 
-書き換えは `.claude/skills/test-driven-development/SKILL.md` と `.github/skills/test-driven-development/SKILL.md` の両方に反映する。
+`architecture.yaml` の `language` を参照して、以下を実際の値に置き換える。
 
-### test-runner エージェントの書き換え
+1. **コード例**: 言語・フレームワークに合わせて RED / GREEN の例を書き直す
+2. **fixture / テストデータ**: このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
+3. **モックのルール**: 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
 
-`architecture.yaml` の `testing_policy` を参照して、以下を実際の値に置き換える。
-
-1. **テスト実行コマンド**: `<your-test-command>` を実際のコマンドに書き換える
-2. **説明文**: 実行環境（Docker / ローカル など）が分かるよう補足する
+上記の `integrations` ルールに従って反映する。
 
 ### 影響範囲チェックリストの書き換え
 
@@ -110,10 +109,12 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 `architecture.yaml` の `language` と `folder_structure` を参照して、以下を実際の値に置き換える。
 
 1. **命名規則**: 言語の慣習に合わせてテーブルの規則・例を書き換える
-2. **言語・型固有ルール**: `<your-language-and-type-rules>` を言語・フレームワークに合わせた具体的なルールに書き換える
-3. **プロジェクト構造**: `<your-project-structure>` を `folder_structure` の実際のディレクトリ構成に書き換える
+2. **コメント規約**: `## コメント` の「プロジェクト固有の決定事項」をユーザーと合意してから書き換える
+   - インラインコメント（なぜ）・処理ブロック（何）・docコメント・TODO/FIXME・セクション区切りの各方針を決定する
+3. **言語・型固有ルール**: `<your-language-and-type-rules>` を言語・フレームワークに合わせた具体的なルールに書き換える
+4. **プロジェクト構造**: `<your-project-structure>` を `folder_structure` の実際のディレクトリ構成に書き換える
 
-書き換えは `.claude/rules/coding.md` と `.github/instructions/coding.instructions.md` の両方に反映する。
+上記の `integrations` ルールに従って反映する。
 
 ### その他の基盤 skill
 
@@ -143,11 +144,12 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 ### 手順
 
 1. 上記の候補をユーザーに提示し、整理してよいか確認する
-2. 承認を得た skill を `.claude/skills/` と `.github/skills/` から削除する
+2. 承認を得た skill を削除する（`integrations` に従い `.claude/skills/` / `.github/skills/` の該当するほうを削除する）
 3. 必要であれば削除前にバックアップ先をユーザーに伝える
 4. `.spec-runner/` の不要ファイルも整理する
    - `intake/current-system-inventory.md` — docs に昇格済みなら削除してよい
    - `architecture/architecture.yaml` — project 専用 skill が完成し、参照不要になったら削除してよい
+   - `scripts/scan.js` — **削除しない**。`@impact-analyzer` が常時依存しているため
 5. `CLAUDE.md` を更新する
    - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
    - 作成した project 専用 skill の名前と使いどころを記載する

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

@@ -95,28 +95,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 ## テスト実行コマンド
 
-> このスキルはテンプレートとして配布されます。
-> `architecture-skill-development` を使ってプロジェクト固有のコマンドに書き換えてください。
-
-```bash
-# 単体テスト（高速・毎回実行）
-<your-unit-test-command>
-
-# 結合テスト
-<your-integration-test-command>
-
-# E2E テスト
-<your-e2e-test-command>
-
-# 全テスト
-<your-test-command>
-
-# 特定ファイル
-<your-test-command> <test-file>
-
-# カバレッジ計測
-<your-test-command> --coverage
-```
+`.github/instructions/testing.instructions.md` に記載されたコマンドを使う。
 
 ## Red-Green-Refactor