spec-runner 1.1.10 → 1.1.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spec-runner",
-  "version": "1.1.10",
+  "version": "1.1.16",
   "description": "docs を正本にした開発運用ハーネスを Claude / Copilot に導入する",
   "license": "MIT",
   "bin": {
@@ -20,7 +20,6 @@
     "rails",
     "django",
     "nextjs",
-    "spec-kit",
     "docs-as-code",
     "architecture-driven"
   ],

package/spec-runner/templates/.claude/agents/code-reviewer.md

@@ -1,51 +1,21 @@
 ---
 name: code-reviewer
-description: コーディング規約ファイルへの適合をチェックする。コード変更後のレビューに使用する。
+description: 実装・修正が完了したときに自動で呼ぶ。変更ファイルをコーディング規約と照合し違反を報告する。修正はしない。
 tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
 
 # コーディング規約チェックエージェント
 
-同梱のコーディング規約ファイルに定義されたコーディング規約への適合をチェックする。
+変更されたコードをコーディング規約と照合し、違反を報告する。
 
 ## 手順
 
 1. `git diff --name-only` で変更ファイルを確認する（引数でファイルが指定された場合はそちらを使用）
-2. 変更された `.py` ファイルを読み込む
-3. 以下のチェック項目を検証する
-4. 違反を報告する
-
-## チェック項目
-
-### 命名規則
-- ファイル名: snake_case
-- クラス名: PascalCase
-- 関数・メソッド: snake_case
-- 変数: snake_case
-- 定数: UPPER_SNAKE_CASE
-- モジュール内部定数: _UPPER_SNAKE_CASE（先頭アンダースコア）
-- テストクラス: Test + PascalCase
-- テストメソッド: test_ + snake_case（日本語不可）
-
-### 型ヒント
-- Python 3.12+ のビルトイン型を使用（`list[str]`, `dict[str, int]`, `str | None`）
-- `typing` モジュールの `List`, `Dict`, `Optional` を使っていないか
-- 値オブジェクトに `frozen=True` の dataclass を使っているか
-
-### コメント・docstring
-- コメントが日本語であるか（英語コメント禁止）
-- モジュール先頭に1行概要があるか
-- 不要なdocstring（名前で意図が伝わる関数へのdocstring）がないか
-
-### テストコメント
-- 全テストメソッドにdocstring（テスト意図を日本語1行）があるか
-- セットアップ5行以上のテストに `# 準備` / `# 実行` / `# 検証` があるか
-- テストクラスが3つ以上のファイルにセクション区切り（`# ====`）があるか
-
-### プロジェクト構造
-- テストファイルが実装と同じディレクトリ構造にあるか
-- `__init__.py` が存在するか
+2. `.claude/rules/coding.md` を読み、チェック項目を把握する
+3. 変更されたソースファイルを読み込む
+4. チェック項目に照らして違反を検出する
+5. 違反を報告する
 
 ## 報告フォーマット
 

package/spec-runner/templates/.claude/agents/design-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: design-reviewer
-description: 設計書（docs/）と実装コード（src/）の整合性をチェックする。設計書と実装の乖離が心配なときに使用する。
+description: 設計書を変更したとき、またはフェーズレビュー時に自動で呼ぶ。docs⇔src の乖離を報告する。修正はしない。
 tools: Read, Grep, Glob
 model: sonnet
 ---
@@ -11,12 +11,12 @@ docs/ 配下の設計書と src/ 配下の実装コードを突合し、乖離
 
 ## 手順
 
-1. docs/ 配下の設計書ファイルを一覧取得する
+1. `docs/` 配下の設計書ファイルを一覧取得する
 2. 各設計書の frontmatter を読み、`spec_runner.node_id` / `kind` / `depends_on` / `maps_to` を確認する
-3. `docs/02_概要設計/**` は上位設計として扱い、ユースケース・責務・外部 IF・非機能方針が実装に反映されているか確認する
-4. `docs/03_詳細設計/src/**` は `maps_to` で対応先コードを特定し、責務・入出力・判断条件・テスト観点を比較する
-5. `docs/03_詳細設計/infrastructure/**` などの例外文書も `maps_to` を起点に IaC / 設定 / DB 定義と比較する
-6. 乖離を報告する
+3. `docs/02_概要設計/**` の各ファイルを読む。ユースケース・責務・外部 IF が実装に反映されているか確認するために、`maps_to` から対応する `src/` ファイルを特定して実際に読んで比較する
+4. `docs/03_詳細設計/**` の各ファイルを読む。`maps_to` に列挙された `src/` / `tests/` ファイルを**実際に読み**、責務・入出力・判断条件・テスト観点を設計書と行レベルで比較する
+   - `maps_to` が空または未設定の場合はフロントマターの問題として報告する（パス推定は行わない）
+5. 乖離を報告する
 
 ## チェック項目
 
@@ -28,13 +28,13 @@ docs/ 配下の設計書と src/ 配下の実装コードを突合し、乖離
 
 ### 概要設計
 
-- **ユースケース整合**: `ユースケース一覧.md` と個別 UC が実装のエンドポイント・コマンド・画面遷移と一致しているか
+- **ユースケース整合**: `ユースケース一覧.md` の各 UC が実装のエンドポイント・コマンド・画面遷移と一致しているか
 - **全体俯瞰**: `システム全体俯瞰.md` の責務分割・連携フロー・外部 IF が実装構造と一致しているか
 - **ADR 反映**: `docs/02_概要設計/90_ADR/**` の採用方針が概要設計・詳細設計に反映されているか
 
 ### 詳細設計
 
-- **責務整合**: `docs/03_詳細設計/src/**` の責務記述が対応コードの責務と一致しているか
+- **責務整合**: `docs/03_詳細設計/**` の責務記述が `maps_to` 先コードの責務と一致しているか
 - **入出力整合**: 関数シグネチャ、設定値、エラー処理、外部依存の扱いが設計どおりか
 - **テスト整合**: `maps_to` に含まれる `tests/**` が設計上の主要シナリオをカバーしているか
 - **不足 / 過剰**: 設計書にあるがコードにない、またはコードにあるが設計書にない要素があるか
@@ -62,4 +62,4 @@ docs/ 配下の設計書と src/ 配下の実装コードを突合し、乖離
 - 読み取り専用（コードや設計書の変更は行わない）
 - 日本語で報告する
 - ADR はコードと 1 対 1 の突合対象ではないが、配置先と反映有無は確認する
-- hard code のパス推定より frontmatter の `maps_to` を優先する
+- `maps_to` を唯一の参照先とする。パス推定は行わない

package/spec-runner/templates/.claude/agents/impact-analyzer.md

@@ -0,0 +1,75 @@
+---
+name: impact-analyzer
+description: design-change で影響範囲を調査するときに呼ぶ。変更対象の node_id またはファイルパスを受け取り、.spec-runner/scan/graph.json のキャッシュを参照して影響ファイルを一覧化し、maps_to の参照整合性も報告する。
+tools: Bash
+model: sonnet
+---
+
+# 影響範囲分析エージェント
+
+`.spec-runner/scan/graph.json`（`scan.js` が生成するキャッシュ）を読み、変更対象の node_id から連鎖する影響ファイルを一覧化する。
+
+## 入力
+
+- 変更対象の `node_id`（例: `detail.usecase.order_registration`）またはファイルパス
+
+## 手順
+
+### 1. グラフキャッシュの確認・更新
+
+```bash
+node .spec-runner/scripts/scan.js
+```
+
+キャッシュが古い場合や存在しない場合は再生成する。
+
+### 2. 影響範囲をグラフから取得
+
+```bash
+node -e "
+const g = require('./.spec-runner/scan/graph.json');
+const id = '{node_id}';
+const node = g.nodes[id] || {};
+const direct = g.reverse_index[id] || [];
+const indirect = [...new Set(
+  direct.flatMap(n => g.reverse_index[n] || []).filter(n => !direct.includes(n) && n !== id)
+)];
+console.log(JSON.stringify({ node, direct: direct.map(n => ({id: n, ...g.nodes[n]})), indirect: indirect.map(n => ({id: n, ...g.nodes[n]})), missing: g.missing_maps_to }, null, 2));
+"
+```
+
+### 3. 結果を一覧化して報告する
+
+## 報告フォーマット
+
+```
+## 影響範囲分析
+
+### 起点
+- node_id: {node_id}
+- ファイル: {ファイルパス}
+- kind: {kind}
+
+### 直接影響（1階層目）
+- [ファイルパス] — node_id: {node_id}, kind: {kind}
+
+### 間接影響（2階層目）
+- [ファイルパス] — node_id: {node_id}, kind: {kind}
+
+### 実装影響（maps_to で対応）
+- [src/ または tests/ のファイルパス]
+
+### maps_to 整合性チェック
+- OK: 全参照ファイルが存在する
+- MISSING: {missing} — {source} ({node_id}) に記載されているが存在しない
+
+### 影響なし（確認済みで変更不要）
+- [ファイルパス] — 理由: {理由}
+```
+
+## 注意事項
+
+- 読み取り専用（ファイルの変更は行わない）
+- 日本語で報告する
+- graph.json が存在しない場合は scan.js を実行してから進む
+- 影響ファイルが多い場合は kind 別にグループ化する

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

@@ -1,6 +1,6 @@
 ---
 name: test-runner
-description: コード変更後にテストを実行し、失敗時は原因分析まで行う。コード修正・機能追加の後に使用する。
+description: 実装・修正が完了したときに自動で呼ぶ。テストを実行し、失敗時は原因と修正案を報告する。コードは修正しない。
 tools: Read, Grep, Glob, Bash
 model: sonnet
 ---

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

@@ -24,6 +24,7 @@ paths: ["src/**", "tests/**"]
 - **言語**: 日本語
 - **docstring**: モジュール先頭に1行で概要を書く。関数・クラスには原則不要（名前で意図が伝わる場合）
 - **インラインコメント**: ビジネスロジックの「なぜ」を説明する場合のみ。処理内容の「何」は書かない
+- **変更履歴コメント禁止**: `# 新機能追加`, `# ここを修正`, `# v2 で変更` のような変更経緯はコードに書かない。git の commit message で管理する
 
 ```python
 # 良い例
@@ -89,6 +90,16 @@ truncated_json = '[{"account_name": "売掛金", ...'
 
 - **英語コメント禁止**: `Arrange` / `Act` / `Assert` 等の英語は使わない
 
+## 後方互換ハックの禁止
+
+使われなくなったコードは完全に削除する。互換性維持のための温存は行わない。
+
+禁止パターン:
+- 未使用の引数・変数を `_` プレフィックスで残す（`_old_param`）
+- 削除した型・関数を `from x import Y` で再公開する
+- `# removed`, `# deprecated`, `# 旧実装` コメントとともにコードを残す
+- 後方互換用のラッパー関数・エイリアスを追加する
+
 ## 検索ルール
 
 - コードの検索・置換は `src/` と `tests/` の両方を対象にする

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

@@ -20,44 +20,61 @@ paths: ["docs/**"]
 - **`docs/**` の全設計書に frontmatter を付ける**
 - 正本の必須項目は `spec_runner.node_id` / `spec_runner.kind` / `spec_runner.depends_on` / `spec_runner.maps_to`
 - `depends_on` はまず文字列配列でよい。依存理由が必要な場合のみオブジェクト形式を使う
-- `maps_to` には見直し対象となる `src/` / `tests/` / IaC / 設定ファイルを列挙する
+- `maps_to` には見直し対象となる `src/` / `tests/` / IaC / 設定ファイルを列挙する。**必ず設定する（空にしない）**
 - `modules` / `source_files` などの拡張項目を足す場合でも、`maps_to` と矛盾させない
 
 ```yaml
 ---
 spec_runner:
-  node_id: detail.src.agents.reconciliation.agent
+  node_id: detail.usecase.注文確定
   kind: detailed_design
   depends_on:
-    - overview.system_context
-    - use_case.reconciliation.list
+    - overview.use_case_list
+    - detail.domain.注文
   maps_to:
-    - src/agents/reconciliation/agent.py
-    - tests/agents/reconciliation/test_agent.py
+    - src/application/order/confirm.py
+    - src/domain/order/aggregate.py
+    - tests/application/order/test_confirm.py
 ---
 ```
 
+### node_id 体系
+
+| 対象 | node_id 形式 | 例 |
+|------|-------------|-----|
+| 要件定義 | `requirement.{名前}` | `requirement.要件定義` |
+| システム全体俯瞰 | `overview.system_context` | — |
+| ドメインモデル | `overview.domain_model` | — |
+| ユースケース一覧 | `overview.use_case_list` | — |
+| ADR | `overview.adr.{slug}` | `overview.adr.0404-ドメイン-注文集約` |
+| ドメイン詳細設計 | `detail.domain.{ドメイン名}` | `detail.domain.注文` |
+| UC 詳細設計 | `detail.usecase.{UC名}` | `detail.usecase.注文確定` |
+| DB・外部サービス | `detail.db.{名前}` | `detail.db.スキーマ定義` |
+
 ## 命名規則
 
 | 対象 | 規則 | 例 |
 |------|------|-----|
-| `docs/01_要件定義` | 日本語 | `要件定義.md` |
-| `docs/02_概要設計` | 日本語 | `ユースケース一覧.md`, `システム全体俯瞰.md` |
-| `docs/02_概要設計/ユースケース` | `UC-{日本語名}.md` | `UC-差異一覧表示.md` |
-| `docs/02_概要設計/90_ADR` | `ADR-0001-{slug}.md` | `ADR-0001-detailed-design-mirrors-src.md` |
-| `docs/03_詳細設計/src/**` | `src/` に合わせた英語 `snake_case` | `agent.md`, `domain.md`, `skill.md` |
-| `docs/03_詳細設計/infrastructure/**` | 対応先に合わせる。例外で置く場合も `maps_to` 必須 | `database.md`, `schema.dbml` |
+| `docs/01_要件定義` | 日本語 | `要件定義.md`, `ユビキタス言語辞書.md` |
+| `docs/02_概要設計` | 日本語 | `ユースケース一覧.md`, `システム全体俯瞰.md`, `ドメインモデル.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` |
 
 ## ADR
 
 - **ADR は必ず 3 案を比較してから採用案を決める**
-- ADR は原則 `docs/02_概要設計/90_ADR/` に置く
-- ドメインローカル ADR が必要な場合だけ `docs/02_概要設計/<ドメイン>/90_ADR/` を使う
+- ADR は `docs/02_概要設計/90_ADR/{対象}/` で管理する（`全体` / `ドメイン` / `UC` / `DB`）
+- ファイル名は `mmdd-{日本語タイトル}.md`。対象はフォルダで表す
 - ADR は理由の記録であり、詳細設計の代わりにしない
+- 廃止 UC の理由も ADR に記録する（UC ファイル本体は削除）
 
 ## 文書品質
 
 - **概要設計では「何をするか」を書き、コード片・DDL・クラス定義は持ち込まない**
-- **詳細設計では `src/` に対応する責務・入出力・判断条件・テスト観点を書く**
-- **`docs/03_詳細設計` は原則 `src/` ミラーにする。例外文書は `maps_to` で根拠を残す**
+- **詳細設計ではドメインルール・UC の責務・入出力・判断条件・テスト観点を書く。コード・プロンプト本文は書かない**
+- **`maps_to` を唯一の src 対応として使う。パス推定に頼らない**
 - **Markdown に HTML タグ（details, summary, br など）を使わない**
+- **`概要.md` のような汎用的な名前のファイルは作らない。内容を具体的に示す名前（`要件定義.md`、`ユースケース一覧.md`、`システム全体俯瞰.md` など）を使う**

package/spec-runner/templates/.claude/rules/harness-formats.md

@@ -0,0 +1,90 @@
+---
+description: rules・agents・skills ファイルのフォーマット定義。harness-engineering や architecture-skill-development で新規作成・修正するときに参照する。
+---
+
+# ハーネスファイルフォーマット
+
+`harness-engineering` や `architecture-skill-development` で rules / agents / skills を作成・修正するときは、このフォーマットに従う。
+
+## rule ファイル（`.claude/rules/*.md`）
+
+```markdown
+---
+description: このルールの概要（1行）
+paths: ["対象パス/**"]   # 省略すると全ファイルに適用
+---
+
+# ルール名
+
+本文...
+```
+
+- `description` は必須。Claude がルールを選択するときに使う
+- `paths` は省略可。省略すると `**` 相当（全ファイルに適用）
+- 対応する `.github/instructions/{name}.instructions.md` も同時に作成・更新する
+  - `.github/` 版の frontmatter は `applyTo: "対象パス/**"` 形式に変換する
+
+## agent ファイル（`.claude/agents/*.md`）
+
+```markdown
+---
+name: agent-name
+description: いつ・何のために呼ぶかを具体的に書く（トリガー型）
+tools: Read, Grep, Glob          # 必要最小限のツールだけ付与
+model: sonnet                    # 通常は sonnet
+---
+
+# エージェント名
+
+本文...
+```
+
+- `description` はトリガー型で書く（「〇〇のときに自動で呼ぶ」形式）
+- `tools` は最小権限原則。読み取りのみなら `Read, Grep, Glob`
+- 書き込みが必要な場合のみ `Edit, Write` を追加する
+- 対応する `.github/agents/{name}.agent.md` も同時に作成・更新する
+
+## skill ファイル（`.claude/skills/{name}/SKILL.md`）
+
+```markdown
+---
+name: skill-name
+description: このスキルの目的と使うタイミング（1〜2行）
+---
+
+# スキル名
+
+本文...
+```
+
+- `description` は Claude がスキルを選択するときに使う。「いつ使うか」を含める
+- 対応する `.github/skills/{name}/SKILL.md` も同時に作成・更新する
+
+## CLAUDE.md
+
+CLAUDE.md は**全会話で常にコンテキストに読み込まれる**。書くほどコストが増えるため、最小に保つ。
+
+### 書いてよいもの
+
+- よく使う skill の名前と起動タイミング（開発ワークフローの入口）
+- プロジェクト全体に常時適用すべき制約（例: 言語、承認フロー）
+
+### 書いてはいけないもの（代わりの置き場所）
+
+| 内容 | 正しい置き場所 |
+|------|--------------|
+| コーディング規約の詳細 | `.claude/rules/coding.md` |
+| フォーマット定義・手順 | `.claude/rules/*.md` |
+| スキルの詳細フロー | `.claude/skills/*/SKILL.md` |
+| 過去の決定・背景 | `docs/02_概要設計/90_ADR/` |
+
+### 目安
+
+- 20行を超えたら見直しを検討する
+- 新しい内容を追加する前に「rules / skills に移せないか」を先に考える
+
+## 共通原則
+
+- `.claude/` と `.github/` は常に対で更新する（片系だけ更新しない）
+- `description` は「何をするか」より「**いつ・なぜ使うか**」を優先して書く
+- 新規作成時は既存ファイルを参考にフォーマットを確認してから作る

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

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

package/spec-runner/templates/.claude/settings.json

@@ -0,0 +1,15 @@
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node .spec-runner/scripts/scan.js 2>&1 | tail -3"
+          }
+        ]
+      }
+    ]
+  }
+}

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

@@ -28,14 +28,14 @@ Phase 5: 次の skill へ引き渡し
 ## Phase 2: 概要設計の骨格作成
 
 1. `docs/02_概要設計/ユースケース一覧.md` を作る
-2. `docs/02_概要設計/システム全体俯瞰.md` を作る
-3. 必要に応じて `ユースケース/`、`外部IF一覧.md`、`非機能・運用方針.md` を追加する
+2. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を作る
+3. `docs/02_概要設計/システム全体俯瞰.md` を作る
 4. ユーザーに確認・承認を得る
 
 ## Phase 3: アーキテクチャ判断の明文化
 
 1. ドメイン分割、責務境界、実装単位、インフラ方針を整理する
-2. 必要なら `docs/02_概要設計/90_ADR/` に ADR を作る
+2. 必要なら対象フォルダに ADR を作る（`90_ADR/全体/` / `ドメイン/` / `UC/` / `DB/`）
 3. ユーザーに確認・承認を得る
 
 ## Phase 4: architecture contract 作成

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

@@ -35,20 +35,22 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 
 ## Phase 3: skill / rule / template へ分解
 
+ファイルを作成する前に **`.claude/rules/harness-formats.md`** を読み、フォーマットを確認する。
+
 1. 会話フローは skill にする
 2. 常時守る約束は rule にする
 3. 毎回コピーする設計書は template にする
 
-### plugin-development を種として使う
+### docs-driven-seed を種として使う
 
-新規開発フローの skill を作る場合は、`plugin-development` を種として使う。
-`plugin-development` はプラグイン型アーキテクチャ向けの reference workflow であり、
+新規開発フローの skill を作る場合は、`docs-driven-seed` を種として使う。
+`docs-driven-seed` は UC/DDD 駆動の docs 正本開発フローの参照実装であり、
 そのまま使うのではなく、**このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作る**ことを目的とする。
 
 具体的には:
-- `.claude/skills/plugin-development/SKILL.md` をコピーして、project 専用の開発 skill の土台にする
+- `.claude/skills/docs-driven-seed/SKILL.md` をコピーして、project 専用の開発 skill の土台にする
 - フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換える
-- 元の `plugin-development` は書き換え完了後にアーカイブ候補とする（Phase 7 で提案する）
+- 元の `docs-driven-seed` は書き換え完了後にアーカイブ候補とする（Phase 7 で提案する）
 
 ユーザーに確認・承認を得る
 
@@ -109,7 +111,7 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 |---|---|
 | `architecture-definition` | 新規プロジェクト初期化専用。アーキテクチャ確定後は不要 |
 | `existing-project-to-docs` | 既存プロジェクト取り込み専用。docs 生成後は不要 |
-| `plugin-development` | Phase 3 で project 専用 skill の種として使い終えたら不要 |
+| `docs-driven-seed` | Phase 3 で project 専用 skill の種として使い終えたら不要 |
 | `architecture-skill-development`（このファイル自身） | project 専用 skill が安定したら不要。ただしアーキテクチャが大きく変わる場合は再利用する可能性があるため、削除ではなくアーカイブを推奨 |
 
 ### 手順
@@ -117,6 +119,20 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 1. 上記の候補をユーザーに提示し、整理してよいか確認する
 2. 承認を得た skill を `.claude/skills/` と `.github/skills/` から削除する
 3. 必要であれば削除前にバックアップ先をユーザーに伝える
+4. `.spec-runner/` の不要ファイルも整理する
+   - `intake/current-system-inventory.md` — docs に昇格済みなら削除してよい
+   - `architecture/architecture.yaml` — project 専用 skill が完成し、参照不要になったら削除してよい
+5. `CLAUDE.md` を更新する
+   - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
+   - 作成した project 専用 skill の名前と使いどころを記載する
+   - 例:
+     ```markdown
+     ## 開発ワークフロー
+     新機能を実装するときは `/feature-development` を使う。
+     既存機能を変更するときは `/design-change` を使う。
+     テストを書くときは `/test-driven-development` を使う。
+     ```
+   - `.claude/` と `.github/` 両系で内容が変わる場合は、それぞれに反映する
 
 ## 原則
 

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

@@ -30,7 +30,7 @@ Phase 6: TDD → 実装 → 検証
    - 影響を受ける機能カテゴリ
    - 技術的・ビジネス的制約
 2. 変更起点となる docs を特定する
-3. frontmatter の `depends_on` / `maps_to` を使って影響候補を軽く洗う
+3. `@impact-analyzer` に委任して `depends_on` / `maps_to` を辿る影響ファイルを洗い出す
 4. 変更が影響するドメインと成果物を一覧化する
 5. ユーザーに確認・承認を得る
 
@@ -41,16 +41,16 @@ Phase 6: TDD → 実装 → 検証
 3. 各案について概要・メリット・デメリット・適合性を示す
 4. ユーザーが案を決定する
 5. テンプレート `templates/90_ADR/ADRテンプレート.md` をコピーして生成する
-6. ファイル名は `ADR-0001-{slug}.md` 形式にする
+6. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
 
 ### ADR 配置ルール
 
-| 変更スコープ | 配置先 |
-|------------|--------|
-| 横断的な決定 | `docs/02_概要設計/90_ADR/` |
-| 特定ドメイン寄りの決定 | `docs/02_概要設計/<ドメイン>/90_ADR/` |
-
-MVP では `docs/02_概要設計/90_ADR/` に集約する。
+| 対象 | 配置先 |
+|------|--------|
+| システム横断の決定 | `docs/02_概要設計/90_ADR/全体/` |
+| ドメイン設計の決定 | `docs/02_概要設計/90_ADR/ドメイン/` |
+| UC フローの決定 | `docs/02_概要設計/90_ADR/UC/` |
+| DB・外部サービスの決定 | `docs/02_概要設計/90_ADR/DB/` |
 
 ## Phase 3: 影響ドキュメントの確定
 
@@ -62,7 +62,7 @@ MVP では `docs/02_概要設計/90_ADR/` に集約する。
 
 ## Phase 4: 概要設計の修正
 
-1. `ユースケース一覧.md` / `システム全体俯瞰.md` / UC 個別文書 / ADR を必要順に修正する
+1. `ユースケース一覧.md` / `システム全体俯瞰.md` / `ドメインモデル.md` / ADR を必要順に修正する
 2. 修正完了ごとにチェックリストを更新する
 3. 全概要設計の修正完了後、ユーザーに確認・承認を得る
 
@@ -73,10 +73,11 @@ MVP では `docs/02_概要設計/90_ADR/` に集約する。
 
 ## Phase 5: 詳細設計の修正
 
-1. `docs/03_詳細設計/src/**` を `src/` ミラーで修正する
-2. 補助設計が必要な場合だけ `docs/03_詳細設計/infrastructure/**` を修正する
-3. frontmatter の `depends_on` / `maps_to` を更新する
-4. ユーザーに最終確認を得る
+1. `docs/03_詳細設計/01_ドメイン/**` のドメイン設計を修正する
+2. `docs/03_詳細設計/02_ユースケース/**` の UC 設計を修正する
+3. DB・外部サービスの変更がある場合は `docs/03_詳細設計/03_DB・外部サービス/**` を修正する
+4. frontmatter の `depends_on` / `maps_to` を更新する
+5. ユーザーに最終確認を得る
 
 ## Phase 6: TDD → 実装 → 検証
 

package/spec-runner/templates/.claude/skills/design-change/templates/90_ADR/ADR/343/203/206/343/203/263/343/203/227/343/203/254/343/203/274/343/203/210.md

@@ -7,7 +7,7 @@ spec_runner:
   maps_to: []
 ---
 
-# ADR-0001 {決定内容のタイトル}
+# {決定内容のタイトル}
 
 **ステータス**: 提案 / 採用 / 廃止 / 置換
 **日付**: YYYY-MM-DD