spec-runner 1.4.1 → 1.6.0

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. 結果を分析する
 
 ## 失敗時の分析
 

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

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

package/spec-runner/templates/.github/instructions/{coding.instructions.md → code-style.instructions.md}

@@ -1,5 +1,6 @@
 ---
-applyTo: "src/**,tests/**"
+description: コーディング規約（命名規則・コメント・テスト構成）
+paths: ["src/**", "tests/**"]
 ---
 
 # コーディング規約
@@ -47,15 +48,26 @@ applyTo: "src/**,tests/**"
 
 ## テスト
 
-- テストファイルは実装と同じディレクトリ構造を維持する（`tests/` 配下に `src/` と同じ構造）
-- TDD サイクル: RED → GREEN → REFACTOR
-
 ### テストコメント規約
 
 - **意図の記述**: 全テストにテスト意図を日本語 1 行で書く（メソッド名の言い換えではなく「なぜそのテストが必要か」を書く）
-- **準備・実行・検証**: セットアップが 5 行以上のテストでは `# 準備` / `# 実行` / `# 検証` で構造を明示する
+- **準備・実行・検証**: セットアップが 5 行以上のテストでは `# 準備 - ...` / `# 実行 - ...` / `# 検証 - ...` で構造を明示する。サフィックスには具体的に何をしているかを書く
 - **英語コメント禁止**: `Arrange` / `Act` / `Assert` 等の英語は使わない
 
+```
+# なぜそのテストが必要かを1行で書く
+test("ある入力に対して期待する出力を返す", () => {
+  # 準備 - テスト対象の入力データを用意する
+  const input = ...
+
+  # 実行 - テスト対象の関数を呼び出す
+  const result = targetFunction(input)
+
+  # 検証 - 期待する出力と一致するか確認する
+  expect(result).toBe(expectedOutput)
+})
+```
+
 ## 後方互換ハックの禁止
 
 使われなくなったコードは完全に削除する。互換性維持のための温存は行わない。

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

@@ -14,9 +14,9 @@ applyTo: "docs/**"
 - 設計書は必ずテンプレートをコピーして生成する。独自にゼロから作成しない
 - 手順: テンプレートを読む → 出力先へコピーする → プレースホルダーを埋める
 
-## frontmatter
+## ヘッダー
 
-- `docs/**` の全設計書に frontmatter を付ける
+- `docs/**` の全設計書にヘッダーを付ける
 - 正本の必須項目は `spec_runner.node_id` / `spec_runner.kind` / `spec_runner.depends_on` / `spec_runner.maps_to`
 - `depends_on` はまず文字列配列でよい。依存理由が必要な場合のみオブジェクト形式を使う
 - `maps_to` には `src/` / `tests/` / IaC / 設定ファイルを列挙する。必ず設定する（空にしない）
@@ -81,7 +81,7 @@ spec_runner:
 - Markdown に HTML タグ（details, summary, br など）を使わない
 - 設計書に絵文字・記号（✓ ✅ ☑ ◯ × △ など）を使わない。状態・判定は文字で表現する
 - `概要.md` のような汎用的な名前は使わない（`要件定義.md`、`ユースケース一覧.md` のように内容を示す名前にする）
-- 「関連ドキュメント」セクションを設計書に作らない。依存関係は frontmatter の `depends_on` で管理する
+- 「関連ドキュメント」セクションを設計書に作らない。依存関係はヘッダーの `depends_on` で管理する
 - 「スケジュール」セクションを設計書に作らない。進捗管理は設計書の責務ではない
 
 ## ドメインモデルとデータモデルの分離（style: ddd のみ）

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

@@ -5,9 +5,6 @@ description: 新規プロジェクトで docs と `.spec-runner/architecture/arc
 
 # architecture-definition
 
-新規プロジェクト向けの初期化フロー。
-要件定義・フォルダ構造の決定・architecture contract の作成までを先に固め、スキル整備を経てから概要設計へ進む。
-
 ## 全体フロー
 
 ```
@@ -21,19 +18,27 @@ Phase 5: architecture-skill-development へ自動移行
 
 ## Phase 1: 要件整理
 
-テンプレート: `.claude/skills/docs-driven-seed/templates/01_要件定義/`
+テンプレート: `.claude/skills/ddd-seed/templates/01_要件定義/`
 
-1. ユーザーから背景、提供価値、制約、スコープ外を確認する
-2. テンプレートをコピーして `docs/01_要件定義/要件定義.md` を作る
-3. ドメイン用語が出てきたら `docs/01_要件定義/ユビキタス言語辞書.md` に随時追記する
-4. アーキテクチャスタイルを選択する
+1. 曖昧な前提があれば `spec-probe` スキルで先に整理する
+2. ユーザーから背景、提供価値、制約、スコープ外を確認する
+3. テンプレートをコピーして `docs/01_要件定義/要件定義.md` を作る
+4. ドメイン用語が出てきたら `docs/01_要件定義/ユビキタス言語辞書.md` に随時追記する
+5. アーキテクチャスタイルを選択する
 
    | スタイル | 選ぶ基準 |
    |---------|---------|
    | `ddd` | 複雑なビジネスドメインがある。集約・境界コンテキストで設計する必要がある |
    | `layered` | CRUD 中心またはビジネスロジックがシンプル。UC・サービス層で設計すれば十分 |
 
-5. 使用する AI 連携を確認する
+6. フロントエンドの有無を確認する
+
+   | 値 | 基準 |
+   |----|------|
+   | `true` | Web UI・モバイル画面がある |
+   | `false` | API・バックエンドのみ |
+
+7. 使用する AI 連携を確認する
 
    | 連携 | フォルダ |
    |------|---------|
@@ -41,11 +46,11 @@ Phase 5: architecture-skill-development へ自動移行
    | `github` | `.github/`（GitHub Copilot） |
    | 両方 | `.claude/` と `.github/` |
 
-6. ユーザーに確認・承認を得る
+8. ユーザーに確認・承認を得る
 
 ## Phase 2: フォルダ構造の決定
 
-対話でプロジェクトのフォルダ構造を決める。この段階で決めた構造がテンプレートの `maps_to` パスに焼き込まれるため、概要設計より前に確定させる。
+この段階で決めた構造がテンプレートの `maps_to` パスに焼き込まれるため、概要設計より前に確定させる。
 
 1. 以下をユーザーと対話しながら決める
    - `src/` 配下のパッケージ・モジュール構成
@@ -63,10 +68,11 @@ Phase 5: architecture-skill-development へ自動移行
 
 ## Phase 4: architecture contract 作成
 
-1. `.spec-runner/architecture/architecture.yaml` を作る
+1. `.spec-runner/architecture/architecture.yaml` を作る（`.spec-runner/` は補助情報として扱う）
 2. 最低限、以下を構造化する
    - **integrations**: Phase 1 で確認した連携（`[claude]` / `[github]` / `[claude, github]`）
    - **style**: Phase 1 で選択したスタイル（`ddd` / `layered`）
+   - **has_frontend**: Phase 1 で確認したフロントエンドの有無（`true` / `false`）
    - **folder_structure**: Phase 2 で決定した構造（`src/` / `tests/` / `docs/` など）
    - domain_structure（style: ddd のときのみ）
    - runtime_units
@@ -82,10 +88,3 @@ Phase 4 が承認されたら、ユーザーにコマンドを打たせずに `a
 2. project 専用 skill に切り出すべき反復フローを列挙する
 3. 確認なしに `architecture-skill-development` Phase 1 へ進む
 4. スキル整備完了後、プロジェクト専用スキルを使って概要設計へ進む
-
-## 原則
-
-- フォルダ構造を概要設計より前に確定する
-- スキル整備が完了してから概要設計へ進む（テンプレートの `maps_to` を確定済み構造で焼き込むため）
-- `.spec-runner/` は補助情報として扱う
-- project 専用 skill を作る前にアーキテクチャを固める