spec-runner 1.7.0 → 1.8.0

package/package.json

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

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

@@ -1,20 +1,10 @@
 ---
-description: 設計書共通ルール（ヘッダー・命名規則・ADR・文書品質）
+description: 設計書共通ルール（ヘッダー・node_id 体系・命名規則・文書品質）
 paths: ["docs/**"]
 ---
 
 # 設計書共通ルール
 
-## フェーズ管理
-
-- ユーザー承認なしにフェーズを進めない
-- フェーズは必ず `要件定義 -> 概要設計 -> 詳細設計 -> TDD -> 実装` の順に進める
-
-## テンプレート
-
-- 設計書は必ずテンプレートをコピーして生成する。独自にゼロから作成しない
-- 手順: テンプレートを読む → 出力先へコピーする → プレースホルダーを埋める
-
 ## ヘッダー
 
 - `docs/**` の全設計書にヘッダーを付ける
@@ -41,6 +31,8 @@ spec_runner:
 
 ### node_id 体系
 
+#### バックエンド
+
 | 対象 | node_id 形式 | 例 |
 |------|-------------|-----|
 | 要件定義 | `requirement.{名前}` | `requirement.要件定義` |
@@ -52,26 +44,42 @@ spec_runner:
 | UC 詳細設計 | `detail.usecase.{UC名}` | `detail.usecase.注文確定` |
 | DB・外部サービス | `detail.db.{名前}` | `detail.db.スキーマ定義` |
 
+#### フロントエンド（has_frontend: true のみ）
+
+| 対象 | node_id 形式 | 例 |
+|------|-------------|-----|
+| 要件定義 | `frontend.requirement.{名前}` | `frontend.requirement.要件定義` |
+| 画面一覧 | `frontend.overview.画面一覧` | — |
+| 画面遷移図 | `frontend.overview.画面遷移図` | — |
+| コンポーネント一覧 | `frontend.overview.コンポーネント一覧` | — |
+| ADR | `frontend.adr.{slug}` | `frontend.adr.0404-UIフレームワーク選定` |
+| 画面詳細設計 | `frontend.detail.画面.{画面名}` | `frontend.detail.画面.ログイン` |
+| コンポーネント詳細設計 | `frontend.detail.component.{名前}` | `frontend.detail.component.ボタン` |
+
 ## 命名規則
 
+### バックエンド
+
 | 対象 | 規則 | 例 |
 |------|------|-----|
-| `docs/01_要件定義` | 日本語 | `要件定義.md`, `ユビキタス言語辞書.md` |
-| `docs/02_概要設計` | 日本語 | `ユースケース一覧.md`, `システム全体俯瞰.md` |
-| `docs/02_概要設計`（style: ddd のみ） | 日本語 | `ドメインモデル.md` |
-| `docs/02_概要設計/90_ADR/{対象}/` | `mmdd-{日本語タイトル}.md` | `0404-注文集約の設計.md` |
+| `docs/バックエンド/01_要件定義` | 日本語 | `要件定義.md`, `ユビキタス言語辞書.md` |
+| `docs/バックエンド/02_概要設計` | 日本語 | `ユースケース一覧.md`, `システム全体俯瞰.md` |
+| `docs/バックエンド/02_概要設計`（style: ddd のみ） | 日本語 | `ドメインモデル.md` |
+| `docs/バックエンド/02_概要設計/90_ADR/{対象}/` | `mmdd-{日本語タイトル}.md` | `0404-注文集約の設計.md` |
 | `{対象}` の選択肢 | `全体` / `ドメイン` / `UC` / `DB` | — |
-| `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` |
+| `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
+### フロントエンド（has_frontend: true のみ）
 
-- ADR は提案時に必ず 3 案を比較してから採用案を決める。ドキュメントには採用案と採用理由のみ記録する
-- ADR は `docs/02_概要設計/90_ADR/{対象}/` で管理する（`全体` / `ドメイン` / `UC` / `DB`）
-- ファイル名は `mmdd-{日本語タイトル}.md`。対象はフォルダで表す
-- ADR は理由の記録であり、詳細設計の代わりにしない
-- 廃止 UC の理由も ADR に記録する（UC ファイル本体は削除）
+| 対象 | 規則 | 例 |
+|------|------|-----|
+| `docs/フロントエンド/01_要件定義` | 日本語 | `要件定義.md` |
+| `docs/フロントエンド/02_概要設計` | 日本語 | `画面一覧.md`, `画面遷移図.md`, `コンポーネント一覧.md` |
+| `docs/フロントエンド/02_概要設計/90_ADR/` | `mmdd-{日本語タイトル}.md` | `0404-UIフレームワーク選定.md` |
+| `docs/フロントエンド/03_詳細設計/01_画面/{カテゴリ名}/` | 日本語 | `ログイン.md`, `ダッシュボード.md` |
+| `docs/フロントエンド/03_詳細設計/02_コンポーネント/` | 日本語 | `ボタン.md`, `モーダル.md` |
 
 ## 文書品質
 
@@ -91,8 +99,8 @@ spec_runner:
 
 | 種別 | 内容 | 置き場所 |
 |------|------|---------|
-| ドメインモデル | ビジネスルール・集約・値オブジェクト・不変条件 | `docs/03_詳細設計/01_ドメイン/` |
-| データモデル | DBスキーマ・テーブル定義・カラム定義・インデックス | `docs/03_詳細設計/03_DB・外部サービス/` |
+| ドメインモデル | ビジネスルール・集約・値オブジェクト・不変条件 | `docs/バックエンド/03_詳細設計/01_ドメイン/` |
+| データモデル | DBスキーマ・テーブル定義・カラム定義・インデックス | `docs/バックエンド/03_詳細設計/03_DB・外部サービス/` |
 
 - `01_ドメイン/` に DB スキーマ・テーブル定義・カラム定義を書かない
 - `03_DB・外部サービス/` にビジネスルール・ドメインロジックを書かない

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

@@ -20,10 +20,12 @@ Phase 5: architecture-skill-development へ自動移行
 
 テンプレート: `.claude/skills/ddd-seed/templates/01_要件定義/`
 
-1. 曖昧な前提があれば `spec-probe` スキルで先に整理する
+1. 背景・提供価値・制約・スコープ外について、曖昧な点があれば一問一答で深掘りする（各質問に推奨回答を添える。コードで確認できることは質問しない）
 2. ユーザーから背景、提供価値、制約、スコープ外を確認する
-3. テンプレートをコピーして `docs/01_要件定義/要件定義.md` を作る
-4. ドメイン用語が出てきたら `docs/01_要件定義/ユビキタス言語辞書.md` に随時追記する
+3. テンプレートをコピーして以下を作る
+   - `docs/バックエンド/01_要件定義/要件定義.md`
+   - `has_frontend: true` の場合は `docs/フロントエンド/01_要件定義/要件定義.md` も作る
+4. ドメイン用語が出てきたら `docs/バックエンド/01_要件定義/ユビキタス言語辞書.md` に随時追記する
 5. アーキテクチャスタイルを選択する
 
    | スタイル | 選ぶ基準 |
@@ -87,4 +89,10 @@ Phase 4 が承認されたら、ユーザーにコマンドを打たせずに `a
 1. `architecture-skill-development` に渡す前提（docs・architecture.yaml・確定済みフォルダ構造）を要約する
 2. project 専用 skill に切り出すべき反復フローを列挙する
 3. 確認なしに `architecture-skill-development` Phase 1 へ進む
-4. スキル整備完了後、プロジェクト専用スキルを使って概要設計へ進む
+4. スキル整備完了後、以下のスキルで概要設計へ進む
+
+   | 条件 | 起動するスキル |
+   |------|--------------|
+   | `style: ddd` | `ddd-seed`（バックエンド） |
+   | `style: layered` | `simple-seed`（バックエンド） |
+   | `has_frontend: true` | 上記に加えて `frontend-seed` を並走させる |

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

@@ -18,7 +18,7 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 ## Phase 1: 入力の確認
 
-1. `docs/01_要件定義/**` を読む
+1. `docs/バックエンド/01_要件定義/**` を読む。`has_frontend: true` の場合は `docs/フロントエンド/01_要件定義/**` も読む
 2. `.spec-runner/architecture/architecture.yaml` を読む
 3. 固定化すべき判断と project 固有判断を切り分ける
 
@@ -49,7 +49,7 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 seed が存在しない場合は「新規に作る」で進める。
 
-`has_frontend: true` の場合は、UC ファイルに画面レイアウトセクションを含める旨を専用スキルに明記する。
+`has_frontend: true` の場合は、`frontend-seed` と バックエンド seed の両方を並走させる旨を専用スキルに明記する。
 
 4. ユーザーに確認・承認を得る
 
@@ -58,12 +58,25 @@ seed が存在しない場合は「新規に作る」で進める。
 インストール時に配布された基盤 skill のプレースホルダーを、このプロジェクトの実態に書き換える。
 以降の書き換えはすべて `architecture.yaml` の `integrations` に従う（`claude` のみなら `.claude/` だけ、`github` のみなら `.github/` だけ、両方なら対で更新する）。
 
+### インフラ構成ファイルの整備
+
+`architecture.yaml` の `language` / `folder_structure` / `testing_policy` を参照して以下を作成する。
+
+1. **`.gitignore`**: 言語・フレームワーク固有のパターン（依存パッケージ・ビルド成果物・キャッシュ）と、プロジェクト固有の除外パス（`.env`、`docs/` 等）をユーザーと確認して作成する
+2. **`.dockerignore`**: `.git`・`docs/`・`tests/`・依存パッケージ・ビルド成果物をビルドコンテキストから除外する。ユーザーに追加除外パスを確認する
+3. **`Dockerfile.test`**: テスト実行専用イメージを作成する
+   - ベースイメージをユーザーに確認する（例: `python:3.12-slim`, `node:20-alpine`）
+   - テスト依存（テストフレームワーク・カバレッジツール等）をインストールする
+   - `has_frontend: true` の場合はフロントエンド用も作成する
+
 ### test-config.md の書き換え
 
 `rules/test-config.md`（GitHub Copilot は `instructions/test-config.instructions.md`）はテスト実行コマンドの単一ソースとして `test-driven-development` スキルと `run-tests` エージェントの両方から参照される。`architecture.yaml` の `testing_policy` を参照して書き換える。
 
-1. **テスト実行コマンド**: `<your-unit-test-command>` / `<your-integration-test-command>` 等を実際のコマンドに書き換える
-2. **テスト構成**: `tests/` のディレクトリ構成が実態と異なる場合は書き換える
+1. **Docker Compose サービス名の確認**: バックエンド・フロントエンドそれぞれのサービス名をユーザーに確認する（例: `backend`, `frontend`）
+2. **LocalStack の確認**: AWS サービスを使うか確認する。使う場合は対象サービス（S3, SQS, DynamoDB 等）と LocalStack のサービス名をユーザーに確認する
+3. **テスト実行コマンド**: `docker compose run --rm <service> <test-command>` の形式で各コマンドを書き換える
+4. **テスト構成**: `tests/` のディレクトリ構成が実態と異なる場合は書き換える
 
 ### test-driven-development の書き換え
 
@@ -72,13 +85,6 @@ seed が存在しない場合は「新規に作る」で進める。
 1. **fixture / テストデータ**: このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
 2. **モックのルール**: 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
 
-### 影響範囲チェックリストの書き換え
-
-`.claude/skills/design-change/references/影響範囲チェックリスト.md` をプロジェクト固有の変更カテゴリとパスに合わせて書き換える。
-
-1. 変更カテゴリをプロジェクトの構成要素（モジュール・サービス・ドメインなど）に合わせて追加・削除する
-2. 詳細設計のパスを `architecture.yaml` の `folder_structure` に合わせて書き換える
-
 ### code-style.md の書き換え
 
 `architecture.yaml` の `language` と `folder_structure` を参照して、以下を実際の値に置き換える。
@@ -124,6 +130,7 @@ seed が存在しない場合は「新規に作る」で進める。
 | `architecture-definition` | 新規プロジェクト初期化専用。アーキテクチャ確定後は不要 |
 | `existing-project-to-docs` | 既存プロジェクト取り込み専用。docs 生成後は不要 |
 | `ddd-seed` / `simple-seed` | プロジェクト専用スキル作成後は不要 |
+| `frontend-seed` | `has_frontend: true` かつプロジェクト専用スキル作成後は不要 |
 | `architecture-skill-development`（このファイル自身） | project 専用 skill が安定したら不要。アーキテクチャ大変更時は再利用可 |
 
 ### 手順

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

@@ -1,6 +1,6 @@
 ---
 name: ddd-seed
-description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジェクトの初期テンプレートとして使い、architecture-skill-development でプロジェクト専用スキルに育てる。
+description: UC/DDD 駆動の docs 正本開発フローの種（バックエンド担当）。新規プロジェクトの初期テンプレートとして使い、architecture-skill-development でプロジェクト専用スキルに育てる。
 ---
 
 # ddd-seed
@@ -12,7 +12,7 @@ description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジ
 | キー | 用途 |
 |------|------|
 | `style` | このスキル（`ddd`）が適切かを確認 |
-| `has_frontend` | `true` なら UC ファイルに「画面レイアウト」セクションを含める |
+| `has_frontend` | `true` なら `frontend-seed` が並走していることを確認 |
 | `folder_structure` | `maps_to` パスの基準として参照する |
 
 設計フェーズで新たな方針・コンポーネントが確定したら、都度 architecture.yaml を最新状態に保つ。
@@ -30,6 +30,7 @@ Phase 5: TDD → 実装
 ## 前提ルール
 
 - docs は正本とし、各ドキュメントに `spec_runner`ヘッダーを付ける
+- バックエンドの設計はすべて `docs/バックエンド/` 配下に置く
 - 詳細設計は `01_ドメイン/` `02_ユースケース/` `03_DB・外部サービス/` の 3 層で構成する
 - ドメインを先に設計し、UC はドメインを参照する形で書く。ドメインの中に UC は入れない
 - `maps_to` は必ず設定する。パス推定に頼らない
@@ -38,20 +39,20 @@ Phase 5: TDD → 実装
 
 ## Phase 1: 要件定義
 
-`architecture-definition` で完了済み。`docs/01_要件定義/` が存在することを確認して次へ進む。
+`architecture-definition` で完了済み。`docs/バックエンド/01_要件定義/` が存在することを確認して次へ進む。
 
 ## Phase 2: 概要設計
 
 ### 2-1. ユースケース一覧
 
 1. 要件定義からユースケースを洗い出す（Query / Command を意識）
-2. `docs/02_概要設計/ユースケース一覧.md` を作る
+2. `docs/バックエンド/02_概要設計/ユースケース一覧.md` を作る
 3. ユーザーに確認・承認を得る
 
 ### 2-2. ドメインモデル + システム全体俯瞰
 
-1. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を作る
-2. コンポーネント全体図・外部 IF を整理し `docs/02_概要設計/システム全体俯瞰.md` を作る
+1. UC から集約・境界コンテキストを整理し `docs/バックエンド/02_概要設計/ドメインモデル.md` を作る
+2. コンポーネント全体図・外部 IF を整理し `docs/バックエンド/02_概要設計/システム全体俯瞰.md` を作る
 3. ユーザーに確認・承認を得る
 
 ### 出力
@@ -59,7 +60,7 @@ Phase 5: TDD → 実装
 テンプレート: `templates/02_概要設計/ユースケース一覧.md` / `templates/02_概要設計/ドメインモデル.md` / `templates/02_概要設計/システム全体俯瞰.md`
 
 ```
-docs/02_概要設計/
+docs/バックエンド/02_概要設計/
   ユースケース一覧.md
   ドメインモデル.md
   システム全体俯瞰.md
@@ -94,7 +95,7 @@ docs/02_概要設計/
 テンプレート: `templates/03_詳細設計/01_ドメイン/{ドメイン名}.md`
 
 ```
-docs/03_詳細設計/01_ドメイン/
+docs/バックエンド/03_詳細設計/01_ドメイン/
   {ドメイン名}.md
 ```
 
@@ -104,17 +105,15 @@ docs/03_詳細設計/01_ドメイン/
 
 テンプレート: `templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md`
 
-> `has_frontend: true` の場合は各 UC ファイルに「画面レイアウト」セクションを含める。`false` なら削除する。
-
 ```
-docs/03_詳細設計/02_ユースケース/
+docs/バックエンド/03_詳細設計/02_ユースケース/
   UC-{日本語名}.md
 ```
 
 ### 4-3. DB・外部サービス（必要時のみ）
 
 ```
-docs/03_詳細設計/03_DB・外部サービス/
+docs/バックエンド/03_詳細設計/03_DB・外部サービス/
   スキーマ定義.dbml
   外部サービス.md
 ```

package/spec-runner/templates/.claude/skills/ddd-seed/templates/01_/350/246/201/344/273/266/345/256/232/347/276/251//343/203/246/343/203/223/343/202/255/343/202/277/343/202/271/350/250/200/350/252/236/350/276/236/346/233/270.md

@@ -5,7 +5,7 @@ spec_runner:
   depends_on:
     - requirement.要件定義
   maps_to:
-    - docs/03_詳細設計/01_ドメイン/
+    - docs/バックエンド/03_詳細設計/01_ドメイン/
 ---
 
 # ユビキタス言語辞書

package/spec-runner/templates/.claude/skills/ddd-seed/templates/01_/350/246/201/344/273/266/345/256/232/347/276/251//350/246/201/344/273/266/345/256/232/347/276/251.md

@@ -4,7 +4,7 @@ spec_runner:
   kind: requirement
   depends_on: []
   maps_to:
-    - docs/02_概要設計/
+    - docs/バックエンド/02_概要設計/
 ---
 
 # 要件定義

package/spec-runner/templates/.claude/skills/ddd-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/203/211/343/203/241/343/202/244/343/203/263/343/203/242/343/203/207/343/203/253.md

@@ -5,7 +5,7 @@ spec_runner:
   depends_on:
     - overview.use_case_list
   maps_to:
-    - docs/03_詳細設計/01_ドメイン/
+    - docs/バックエンド/03_詳細設計/01_ドメイン/
 ---
 
 # ドメインモデル

package/spec-runner/templates/.claude/skills/ddd-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/344/270/200/350/246/247.md

@@ -5,7 +5,7 @@ spec_runner:
   depends_on:
     - requirement.要件定義
   maps_to:
-    - docs/03_詳細設計/02_ユースケース/
+    - docs/バックエンド/03_詳細設計/02_ユースケース/
 ---
 
 # ユースケース一覧

package/spec-runner/templates/.claude/skills/ddd-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/02_/343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/UC-{/346/227/245/346/234/254/350/252/236/345/220/215}.md

@@ -48,21 +48,6 @@ sequenceDiagram
 |------------|---------|------|
 | {エラーケース} | {発生条件} | {対応} |
 
-## 画面レイアウト
-
-> `has_frontend: true` のときのみ記載する。不要なら削除する。
-
-- 画面名: {画面名}
-- 遷移元: {前の画面 or -}
-- 遷移先: {次の画面 or -}
-
-```
-{画面レイアウト概要 — ASCII art / Markdown テーブルで表現}
-```
-
-- 主要 UI 要素:
-  - {入力フォーム・ボタン・一覧表示など}
-
 ## テスト観点
 
 - {正常系の観点}

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

@@ -7,7 +7,6 @@ description: 既存機能の変更を docs 正本で進めるフローガイド
 
 フェーズは順番通りに進める。ユーザーの承認なしに先へ進めない。
 
-影響範囲のチェックリストは `references/影響範囲チェックリスト.md` を参照する。
 ADR テンプレートは `templates/90_ADR/ADRテンプレート.md` を使用する。
 
 ## 前提: architecture.yaml の読み込み
@@ -17,7 +16,7 @@ ADR テンプレートは `templates/90_ADR/ADRテンプレート.md` を使用
 | キー | 用途 |
 |------|------|
 | `style` | Phase 4/5 のフォルダパス・設計順序を決定 |
-| `has_frontend` | UC 修正時に「画面レイアウト」セクションの要否を判断 |
+| `has_frontend` | `true` なら `docs/フロントエンド/` の設計書も変更対象に含める |
 | `folder_structure` | 影響ドキュメントのパス確認に使用 |
 
 設計変更によって方針・構成に変化があった場合は、architecture.yaml も合わせて更新する。
@@ -35,16 +34,18 @@ Phase 6: TDD → 実装 → 検証
 
 ## Phase 1: 変更要求の整理と軽い影響調査
 
-1. 曖昧な前提があれば `spec-probe` スキルで先に整理する
+1. 変更の背景や目的について曖昧な点があれば、一問一答で深掘りする（各質問に推奨回答を添える。コードで確認できることは質問しない）
 2. 以下をユーザーにヒアリングする
    - 変更の背景・課題
    - 変更の目的・期待する結果
    - 影響を受ける機能カテゴリ
+   - バックエンド / フロントエンド / 両方のどちらに影響するか
    - 技術的・ビジネス的制約
 3. 変更起点となる docs を特定する
 4. `@analyze-impact` に委任して `depends_on` / `maps_to` を辿る影響ファイルを洗い出す
-5. 変更が影響するドメインと成果物を一覧化する
-6. ユーザーに確認・承認を得る
+5. `has_frontend: true` かつバックエンドの **API（UC の入出力・エンドポイント）** が変わる場合、フロントエンドの画面設計も影響対象に追加する（`docs/フロントエンド/03_詳細設計/01_画面/` の「API連携」セクションを確認）
+6. 変更が影響するドメインと成果物を一覧化する
+7. ユーザーに確認・承認を得る
 
 ## Phase 2: ADR 作成（必要時）
 
@@ -60,15 +61,16 @@ Phase 6: TDD → 実装 → 検証
 
 | 対象 | 配置先 |
 |------|--------|
-| システム横断の決定 | `docs/02_概要設計/90_ADR/全体/` |
-| ドメイン設計の決定 | `docs/02_概要設計/90_ADR/ドメイン/` |
-| UC フローの決定 | `docs/02_概要設計/90_ADR/UC/` |
-| DB・外部サービスの決定 | `docs/02_概要設計/90_ADR/DB/` |
+| システム横断の決定 | `docs/バックエンド/02_概要設計/90_ADR/全体/` |
+| ドメイン設計の決定 | `docs/バックエンド/02_概要設計/90_ADR/ドメイン/` |
+| UC フローの決定 | `docs/バックエンド/02_概要設計/90_ADR/UC/` |
+| DB・外部サービスの決定 | `docs/バックエンド/02_概要設計/90_ADR/DB/` |
+| フロントエンドの決定 | `docs/フロントエンド/02_概要設計/90_ADR/` |
 
 ## Phase 3: 影響ドキュメントの確定
 
-1. `references/影響範囲チェックリスト.md` を読み、変更に応じた影響ドキュメントを網羅的に洗い出す
-2.ヘッダーの `depends_on` / `maps_to` を使って候補を絞る
+1. `@analyze-impact` に委任して `depends_on` / `maps_to` を辿る影響ファイルを網羅的に洗い出す
+2. ヘッダーの `depends_on` / `maps_to` を使って候補を絞る
 3. 修正が必要なファイルをチェックリスト形式で提示する
 4. `@review-design` エージェントに委任して、現時点の設計書⇔実装の乖離も合わせて確認する
 5. ユーザーに確認・承認を得る
@@ -77,25 +79,38 @@ Phase 6: TDD → 実装 → 検証
 
 概要設計では「何をするか」に留める。変更理由は ADR または本文で追えるようにする。
 
-1. `ユースケース一覧.md` / `システム全体俯瞰.md` / ADR を必要順に修正する
+### バックエンド
+
+1. `docs/バックエンド/02_概要設計/ユースケース一覧.md` / `システム全体俯瞰.md` / ADR を必要順に修正する
 2. `style: ddd` の場合: `ドメインモデル.md` も必要に応じて修正する
-3. 修正完了ごとにチェックリストを更新する
-4. 全概要設計の修正完了後、ユーザーに確認・承認を得る
+
+### フロントエンド（has_frontend: true かつ影響がある場合）
+
+1. `docs/フロントエンド/02_概要設計/画面一覧.md` / `画面遷移図.md` / `コンポーネント一覧.md` を必要順に修正する
+
+修正完了ごとにチェックリストを更新する。全概要設計の修正完了後、ユーザーに確認・承認を得る。
 
 ## Phase 5: 詳細設計の修正
 
+### バックエンド
+
 `style: ddd` の場合:
 
-1. `docs/03_詳細設計/01_ドメイン/**` のドメイン設計を修正する
-2. `docs/03_詳細設計/02_ユースケース/**` の UC 設計を修正する
-3. DB・外部サービスの変更がある場合は `docs/03_詳細設計/03_DB・外部サービス/**` を修正する
+1. `docs/バックエンド/03_詳細設計/01_ドメイン/**` のドメイン設計を修正する
+2. `docs/バックエンド/03_詳細設計/02_ユースケース/**` の UC 設計を修正する
+3. DB・外部サービスの変更がある場合は `docs/バックエンド/03_詳細設計/03_DB・外部サービス/**` を修正する
 
 `style: layered` の場合:
 
-1. `docs/03_詳細設計/01_ユースケース/**` の UC 設計を修正する
-2. DB・外部サービスの変更がある場合は `docs/03_詳細設計/02_DB・外部サービス/**` を修正する
+1. `docs/バックエンド/03_詳細設計/01_ユースケース/**` の UC 設計を修正する
+2. DB・外部サービスの変更がある場合は `docs/バックエンド/03_詳細設計/02_DB・外部サービス/**` を修正する
+
+### フロントエンド（has_frontend: true かつ影響がある場合）
+
+1. `docs/フロントエンド/03_詳細設計/01_画面/**` の画面設計を修正する
+2. コンポーネントの変更がある場合は `docs/フロントエンド/03_詳細設計/02_コンポーネント/**` を修正する
 
-ヘッダー の `depends_on` / `maps_to` を更新する。ユーザーに最終確認を得る。
+ヘッダーの `depends_on` / `maps_to` を更新する。ユーザーに最終確認を得る。
 
 ## Phase 6: TDD → 実装 → 検証
 

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

@@ -23,6 +23,8 @@ Phase 5: architecture contract 化
 - 既存コードを正として観測する。推測する場合は明示する
 - `depends_on` を使って後続変更に耐える形へ整える
 - ユーザー承認なしに次フェーズへ進めない
+- バックエンドの設計はすべて `docs/バックエンド/` 配下に置く
+- `has_frontend: true` の場合、フロントエンドの設計は `docs/フロントエンド/` 配下に置く
 - `style: ddd` の場合: UC がドメインを使う。ドメインの中に UC を入れない
 - `style: ddd` の場合: 詳細設計は `01_ドメイン/` `02_ユースケース/` `03_DB・外部サービス/` の 3 層で構成する
 - `style: layered` の場合: ドメイン層は持たない。ビジネスロジックは UC / サービス層で表現する
@@ -32,8 +34,9 @@ Phase 5: architecture contract 化
 
 1. `src/`、`tests/`、設定ファイル、README、IaC を読む
 2. 現状システムの入口、主要フロー、外部依存を一覧化する
-3. `.spec-runner/intake/current-system-inventory.md` を作る
-4. ユーザーに確認・承認を得る
+3. フロントエンドの有無（Web UI・画面があるか）を判定する
+4. `.spec-runner/intake/current-system-inventory.md` を作る
+5. ユーザーに確認・承認を得る
 
 ## Phase 1.5: docs 構成の合意
 
@@ -41,34 +44,44 @@ Phase 5: architecture contract 化
 
 1. `current-system-inventory.md` を元に以下を提案する
    - `style`（`ddd` / `layered`）
-   - `docs/` のフォルダ構成
+   - `has_frontend`（`true` / `false`）
+   - `docs/` のフォルダ構成（`バックエンド/` + 必要なら `フロントエンド/`）
    - 作成予定ファイルの一覧
 2. ユーザーに確認・承認を得る
-3. 承認後、`.spec-runner/architecture/architecture.yaml` を新規作成し `style` だけ先に書き込む（残りは Phase 5 で完成させる）
+3. 承認後、`.spec-runner/architecture/architecture.yaml` を新規作成し `style` と `has_frontend` だけ先に書き込む（残りは Phase 5 で完成させる）
 
 ## Phase 2: 要件とユースケースの抽出
 
 要件定義テンプレートは `simple-seed` に存在しないため、`style` に関わらず `ddd-seed` のテンプレートを使う。
 
 1. `current-system-inventory.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. ユーザーに確認・承認を得る
+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. `has_frontend: true` の場合: `.claude/skills/frontend-seed/templates/01_要件定義/要件定義.md` を使い `docs/フロントエンド/01_要件定義/要件定義.md` も作る
+6. ユーザーに確認・承認を得る
 
 ## Phase 3: 概要設計
 
+### バックエンド
+
 `style: ddd` の場合:
 
-1. `.claude/skills/ddd-seed/templates/02_概要設計/システム全体俯瞰.md` を使い `docs/02_概要設計/システム全体俯瞰.md` を作る
-2. `.claude/skills/ddd-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` の場合:
 
-1. `.claude/skills/simple-seed/templates/02_概要設計/システム全体俯瞰.md` を使い `docs/02_概要設計/システム全体俯瞰.md` を作る
+1. `.claude/skills/simple-seed/templates/02_概要設計/システム全体俯瞰.md` を使い `docs/バックエンド/02_概要設計/システム全体俯瞰.md` を作る
 2. 必要なら ADR を作る（作成ルールは下記）
 
+### フロントエンド（has_frontend: true のみ）
+
+1. `.claude/skills/frontend-seed/templates/02_概要設計/画面一覧.md` を使い `docs/フロントエンド/02_概要設計/画面一覧.md` を作る
+2. `.claude/skills/frontend-seed/templates/02_概要設計/画面遷移図.md` を使い `docs/フロントエンド/02_概要設計/画面遷移図.md` を作る
+3. `.claude/skills/frontend-seed/templates/02_概要設計/コンポーネント一覧.md` を使い `docs/フロントエンド/02_概要設計/コンポーネント一覧.md` を作る
+
 ### ADR 作成ルール（必要時のみ）
 
 1. 提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する
@@ -78,18 +91,20 @@ Phase 5: architecture contract 化
 
 | 対象 | 配置先 |
 |------|--------|
-| システム横断の決定 | `90_ADR/全体/` |
-| ドメイン設計の決定 | `90_ADR/ドメイン/` |
-| UC フローの決定 | `90_ADR/UC/` |
-| DB・外部サービスの決定 | `90_ADR/DB/` |
+| システム横断の決定 | `docs/バックエンド/02_概要設計/90_ADR/全体/` |
+| ドメイン設計の決定 | `docs/バックエンド/02_概要設計/90_ADR/ドメイン/` |
+| UC フローの決定 | `docs/バックエンド/02_概要設計/90_ADR/UC/` |
+| DB・外部サービスの決定 | `docs/バックエンド/02_概要設計/90_ADR/DB/` |
+| フロントエンドの決定 | `docs/フロントエンド/02_概要設計/90_ADR/` |
 
 `style: layered` の場合:
 
 | 対象 | 配置先 |
 |------|--------|
-| システム横断の決定 | `90_ADR/全体/` |
-| UC フローの決定 | `90_ADR/UC/` |
-| DB・外部サービスの決定 | `90_ADR/DB/` |
+| システム横断の決定 | `docs/バックエンド/02_概要設計/90_ADR/全体/` |
+| UC フローの決定 | `docs/バックエンド/02_概要設計/90_ADR/UC/` |
+| DB・外部サービスの決定 | `docs/バックエンド/02_概要設計/90_ADR/DB/` |
+| フロントエンドの決定 | `docs/フロントエンド/02_概要設計/90_ADR/` |
 
 3. 採用案を概要設計へ反映してから次へ進む
 
@@ -97,16 +112,23 @@ Phase 5: architecture contract 化
 
 ## Phase 4: 詳細設計
 
+### バックエンド
+
 `style: ddd` の場合（ドメイン → UC → DB・外部サービス の順に設計する）:
 
-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・外部サービス/` を作る
+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・外部サービス の順に設計する）:
 
-1. `.claude/skills/simple-seed/templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を使い、UC ごとに `docs/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を作る
-2. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/02_DB・外部サービス/` を作る
+1. `.claude/skills/simple-seed/templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を使い、UC ごとに `docs/バックエンド/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を作る
+2. DB・外部サービスの仕様が必要なら `docs/バックエンド/03_詳細設計/02_DB・外部サービス/` を作る
+
+### フロントエンド（has_frontend: true のみ）
+
+1. `.claude/skills/frontend-seed/templates/03_詳細設計/01_画面/{カテゴリ名}/{画面名}.md` を使い、カテゴリごとに画面 MD を `docs/フロントエンド/03_詳細設計/01_画面/` に作る
+2. `.claude/skills/frontend-seed/templates/03_詳細設計/02_コンポーネント/{コンポーネント名}.md` を使い、共通コンポーネントを `docs/フロントエンド/03_詳細設計/02_コンポーネント/` に作る
 
 各ファイルの `maps_to` に対応コードとテストを必ず入れる。ユーザーに確認・承認を得る。
 
@@ -115,4 +137,3 @@ Phase 5: architecture contract 化
 1. `.spec-runner/architecture/architecture.yaml` を完成させる
 2. 現状構造を project 専用 skill へ渡せる粒度に整える
 3. `architecture-skill-development` へ引き渡す
-