spec-runner 1.1.9 → 1.1.13

package/bin/spec-runner-installer.js

@@ -336,28 +336,20 @@ function printBanner() {
   console.log("");
 }
 
-function printNextSteps(mode, archStatus) {
+function printNextSteps(archStatus) {
   console.log("─────────────────────────────────────────");
-  console.log("次のステップ:");
-  console.log("");
-  if (mode === "existing") {
-    console.log("  1. /existing-project-to-docs");
-    console.log("     既存コードから docs の draft と architecture contract を生成してください。");
+  if (archStatus === "decided") {
+    console.log("次のステップ:");
     console.log("");
-    console.log("  2. /architecture-skill-development");
-    console.log("     architecture contract を元に、プロジェクト専用の skill を作成してください。");
-  } else if (archStatus === "decided") {
     console.log("  1. .spec-runner/architecture/architecture.yaml を用意してください。");
     console.log("     （既に決まっているアーキテクチャを記述）");
     console.log("");
-    console.log("  2. /architecture-skill-development");
-    console.log("     architecture contract を元に、プロジェクト専用の skill を作成してください。");
+    console.log("  2. Claude Code を開いて /architecture-skill-development を実行してください。");
   } else {
-    console.log("  1. /architecture-definition");
-    console.log("     対話形式でアーキテクチャを決め、docs と architecture contract を生成してください。");
+    console.log("次のステップ:");
     console.log("");
-    console.log("  2. /architecture-skill-development");
-    console.log("     architecture contract を元に、プロジェクト専用の skill を作成してください。");
+    console.log("  Claude Code を開いて、作りたいものを伝えてください。");
+    console.log("  セットアップが自動で始まります。");
   }
   console.log("─────────────────────────────────────────");
 }
@@ -383,6 +375,12 @@ function main() {
     throw new Error(`Claude テンプレートが見つかりません: ${CLAUDE_TEMPLATE_DIR}`);
   }
 
+  // CLAUDE.md をプロジェクトルートへインストール（target によらず常に配置）
+  const claudeMdSrc = path.join(TEMPLATE_ROOT, "CLAUDE.md");
+  if (exists(claudeMdSrc)) {
+    copyFileWithPolicy(claudeMdSrc, path.join(CWD, "CLAUDE.md"), archiveRoot);
+  }
+
   console.log("");
   if (target === "claude" || target === "both") {
     mirrorTreeTo(DEST_CLAUDE_DIR, CLAUDE_TEMPLATE_DIR, archiveRoot);
@@ -405,7 +403,7 @@ function main() {
   else if (target === "copilot") console.log("完了: .github/ を導入しました。");
   else console.log("完了: .claude/ と .github/ を導入しました。");
   console.log("");
-  printNextSteps(mode, archStatus);
+  printNextSteps(archStatus);
 }
 
 main();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spec-runner",
-  "version": "1.1.9",
+  "version": "1.1.13",
   "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
 ---

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

@@ -0,0 +1,51 @@
+---
+name: impact-analyzer
+description: design-change で影響範囲を調査するときに呼ぶ。変更対象の node_id またはファイルパスを受け取り、docs/ 全体の frontmatter を走査して depends_on / maps_to で連鎖する影響ファイルを一覧化する。
+tools: Read, Grep, Glob
+model: sonnet
+---
+
+# 影響範囲分析エージェント
+
+変更対象の docs ノードを起点に、frontmatter の `depends_on` / `maps_to` を辿って影響を受けるファイルを一覧化する。
+
+## 入力
+
+- 変更対象の `node_id`（例: `usecase.order_registration`）またはファイルパス
+
+## 手順
+
+1. `docs/` 配下の全 `.md` ファイルの frontmatter を読む
+2. `depends_on` に入力の node_id を含むファイルを「直接影響」として収集する
+3. 収集したファイルの node_id を起点に同じ検索を繰り返す（2階層まで）
+4. `maps_to` に入力の node_id を含む `src/` / `tests/` ファイルを「実装影響」として収集する
+5. 結果を一覧化する
+
+## 報告フォーマット
+
+```
+## 影響範囲分析
+
+### 起点
+- node_id: {node_id}
+- ファイル: {ファイルパス}
+
+### 直接影響（depends_on で参照）
+- [ファイルパス] — node_id: {node_id}, kind: {kind}
+
+### 間接影響（2階層目）
+- [ファイルパス] — node_id: {node_id}, kind: {kind}
+
+### 実装影響（maps_to で対応）
+- [src/ または tests/ のファイルパス]
+
+### 影響なし（確認済みで変更不要）
+- [ファイルパス] — 理由: {理由}
+```
+
+## 注意事項
+
+- 読み取り専用（ファイルの変更は行わない）
+- 日本語で報告する
+- frontmatter が存在しないファイルはスキップする
+- 影響ファイルが多い場合は 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/design-docs.md

@@ -44,7 +44,7 @@ spec_runner:
 | `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/02_概要設計/90_ADR` | `mmdd-{日本語タイトル}.md` | `0404-詳細設計をsrcミラーにする.md` |
 | `docs/03_詳細設計/src/**` | `src/` に合わせた英語 `snake_case` | `agent.md`, `domain.md`, `skill.md` |
 | `docs/03_詳細設計/infrastructure/**` | 対応先に合わせる。例外で置く場合も `maps_to` 必須 | `database.md`, `schema.dbml` |
 

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/skills/architecture-definition/SKILL.md

@@ -48,10 +48,13 @@ Phase 5: 次の skill へ引き渡し
    - testing_policy
 3. ユーザーに確認・承認を得る
 
-## Phase 5: 次の skill へ引き渡し
+## Phase 5: architecture-skill-development へ自動移行
 
-1. `architecture-skill-development` に渡す前提を整理する
+Phase 4 が承認されたら、**ユーザーにコマンドを打たせずに `architecture-skill-development` を続けて開始する**。
+
+1. `architecture-skill-development` に渡す前提（docs と architecture.yaml の所在）を要約する
 2. project 専用 skill に切り出すべき反復フローを列挙する
+3. 確認なしに `architecture-skill-development` Phase 1 へ進む
 
 ## 原則
 

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

@@ -117,6 +117,17 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 1. 上記の候補をユーザーに提示し、整理してよいか確認する
 2. 承認を得た skill を `.claude/skills/` と `.github/skills/` から削除する
 3. 必要であれば削除前にバックアップ先をユーザーに伝える
+4. `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,7 +41,7 @@ Phase 6: TDD → 実装 → 検証
 3. 各案について概要・メリット・デメリット・適合性を示す
 4. ユーザーが案を決定する
 5. テンプレート `templates/90_ADR/ADRテンプレート.md` をコピーして生成する
-6. ファイル名は `ADR-0001-{slug}.md` 形式にする
+6. ファイル名は `mmdd-{日本語タイトル}.md` 形式にする（例: `0404-キャッシュ戦略の変更.md`）
 
 ### ADR 配置ルール
 

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

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

@@ -90,6 +90,7 @@ Phase 4: 影響範囲の反映確認
 - 関連する skill / rule / agent / template の記述が矛盾していないか
 - Claude / Copilot の対応ファイルに反映漏れがないか
 - 今回限りのノイズをルール化していないか
+- skill 名・起動条件・使いどころを変更した場合、`CLAUDE.md` の記述と一致しているか
 
 ## 原則
 

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

@@ -82,7 +82,7 @@ docs/
 1. 実装方針に意思決定が必要な場合だけ ADR を作る
 2. **必ず 3 案を比較する**
 3. テンプレート `templates/02_概要設計/90_ADR/ADRテンプレート.md` をコピーして生成する
-4. 配置先は `docs/02_概要設計/90_ADR/ADR-0001-{slug}.md` を原則とする
+4. 配置先は `docs/02_概要設計/90_ADR/mmdd-{日本語タイトル}.md` を原則とする
 5. 採用案を概要設計へ反映してから次へ進む
 
 ## Phase 4: 詳細設計

package/spec-runner/templates/.claude/skills/plugin-development/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210/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

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

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

@@ -1,6 +1,6 @@
 ---
 name: design-reviewer
-description: 設計書（docs/）と実装コード（src/）の整合性をチェックする。設計書と実装の乖離が心配なときに使用する。
+description: 設計書を変更したとき、またはフェーズレビュー時に自動で呼ぶ。docs⇔src の乖離を報告する。修正はしない。
 tools: Read, Grep, Glob
 model: sonnet
 ---

package/spec-runner/templates/.github/agents/impact-analyzer.agent.md

@@ -0,0 +1,51 @@
+---
+name: impact-analyzer
+description: design-change で影響範囲を調査するときに呼ぶ。変更対象の node_id またはファイルパスを受け取り、docs/ 全体の frontmatter を走査して depends_on / maps_to で連鎖する影響ファイルを一覧化する。
+tools: Read, Grep, Glob
+model: sonnet
+---
+
+# 影響範囲分析エージェント
+
+変更対象の docs ノードを起点に、frontmatter の `depends_on` / `maps_to` を辿って影響を受けるファイルを一覧化する。
+
+## 入力
+
+- 変更対象の `node_id`（例: `usecase.order_registration`）またはファイルパス
+
+## 手順
+
+1. `docs/` 配下の全 `.md` ファイルの frontmatter を読む
+2. `depends_on` に入力の node_id を含むファイルを「直接影響」として収集する
+3. 収集したファイルの node_id を起点に同じ検索を繰り返す（2階層まで）
+4. `maps_to` に入力の node_id を含む `src/` / `tests/` ファイルを「実装影響」として収集する
+5. 結果を一覧化する
+
+## 報告フォーマット
+
+```
+## 影響範囲分析
+
+### 起点
+- node_id: {node_id}
+- ファイル: {ファイルパス}
+
+### 直接影響（depends_on で参照）
+- [ファイルパス] — node_id: {node_id}, kind: {kind}
+
+### 間接影響（2階層目）
+- [ファイルパス] — node_id: {node_id}, kind: {kind}
+
+### 実装影響（maps_to で対応）
+- [src/ または tests/ のファイルパス]
+
+### 影響なし（確認済みで変更不要）
+- [ファイルパス] — 理由: {理由}
+```
+
+## 注意事項
+
+- 読み取り専用（ファイルの変更は行わない）
+- 日本語で報告する
+- frontmatter が存在しないファイルはスキップする
+- 影響ファイルが多い場合は kind 別にグループ化する

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

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

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

@@ -43,7 +43,7 @@ spec_runner:
 | `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/02_概要設計/90_ADR` | `mmdd-{日本語タイトル}.md` | `0404-詳細設計をsrcミラーにする.md` |
 | `docs/03_詳細設計/src/**` | `src/` に合わせた英語 `snake_case` | `agent.md`, `domain.md`, `skill.md` |
 | `docs/03_詳細設計/infrastructure/**` | 対応先に合わせる。例外で置く場合も `maps_to` 必須 | `database.md`, `schema.dbml` |
 

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

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

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

@@ -48,10 +48,13 @@ Phase 5: 次の skill へ引き渡し
    - testing_policy
 3. ユーザーに確認・承認を得る
 
-## Phase 5: 次の skill へ引き渡し
+## Phase 5: architecture-skill-development へ自動移行
 
-1. `architecture-skill-development` に渡す前提を整理する
+Phase 4 が承認されたら、**ユーザーにコマンドを打たせずに `architecture-skill-development` を続けて開始する**。
+
+1. `architecture-skill-development` に渡す前提（docs と architecture.yaml の所在）を要約する
 2. project 専用 skill に切り出すべき反復フローを列挙する
+3. 確認なしに `architecture-skill-development` Phase 1 へ進む
 
 ## 原則
 

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

@@ -117,6 +117,17 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 1. 上記の候補をユーザーに提示し、整理してよいか確認する
 2. 承認を得た skill を `.claude/skills/` と `.github/skills/` から削除する
 3. 必要であれば削除前にバックアップ先をユーザーに伝える
+4. `CLAUDE.md` を更新する
+   - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
+   - 作成した project 専用 skill の名前と使いどころを記載する
+   - 例:
+     ```markdown
+     ## 開発ワークフロー
+     新機能を実装するときは `/feature-development` を使う。
+     既存機能を変更するときは `/design-change` を使う。
+     テストを書くときは `/test-driven-development` を使う。
+     ```
+   - `.claude/` と `.github/` 両系で内容が変わる場合は、それぞれに反映する
 
 ## 原則
 

package/spec-runner/templates/.github/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,7 +41,7 @@ Phase 6: TDD → 実装 → 検証
 3. 各案について概要・メリット・デメリット・適合性を示す
 4. ユーザーが案を決定する
 5. テンプレート `templates/90_ADR/ADRテンプレート.md` をコピーして生成する
-6. ファイル名は `ADR-0001-{slug}.md` 形式にする
+6. ファイル名は `mmdd-{日本語タイトル}.md` 形式にする（例: `0404-キャッシュ戦略の変更.md`）
 
 ### ADR 配置ルール
 

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

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

@@ -90,6 +90,7 @@ Phase 4: 影響範囲の反映確認
 - 関連する skill / rule / agent / template の記述が矛盾していないか
 - Claude / Copilot の対応ファイルに反映漏れがないか
 - 今回限りのノイズをルール化していないか
+- skill 名・起動条件・使いどころを変更した場合、`CLAUDE.md` の記述と一致しているか
 
 ## 原則
 

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

@@ -82,7 +82,7 @@ docs/
 1. 実装方針に意思決定が必要な場合だけ ADR を作る
 2. **必ず 3 案を比較する**
 3. テンプレート `templates/02_概要設計/90_ADR/ADRテンプレート.md` をコピーして生成する
-4. 配置先は `docs/02_概要設計/90_ADR/ADR-0001-{slug}.md` を原則とする
+4. 配置先は `docs/02_概要設計/90_ADR/mmdd-{日本語タイトル}.md` を原則とする
 5. 採用案を概要設計へ反映してから次へ進む
 
 ## Phase 4: 詳細設計

package/spec-runner/templates/.github/skills/plugin-development/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210/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

package/spec-runner/templates/CLAUDE.md

@@ -0,0 +1,18 @@
+## spec-runner セットアップ
+
+### 初回自動起動
+
+ユーザーが最初に話しかけてきたとき、以下の条件を確認して自動的にセットアップを開始する。**ユーザーにスラッシュコマンドを打たせない。**
+
+| 状態 | 判定方法 | 自動起動するスキル |
+|------|---------|-----------------|
+| 新規プロジェクト | `docs/` が存在しないか空 | `architecture-definition` |
+| 既存プロジェクト | `docs/` にファイルがある | `existing-project-to-docs` |
+
+どちらの場合も、そのスキルが完了したら続けて `architecture-skill-development` を自動起動する。
+
+### 判定の注意
+
+- `docs/` の中身を確認してから判断する（ディレクトリ存在だけで判断しない）
+- ユーザーが「〇〇を作りたい」「〇〇の開発を始めたい」のように要件・作業開始を示す発言をしたら起動する
+- 雑談や質問など、明らかに要件でない場合は起動しない