spec-runner 1.7.0 → 1.9.0

package/spec-runner/templates/.github/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 を最新状態に保つ。
@@ -23,13 +23,15 @@ description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジ
 Phase 1: 要件定義
 Phase 2: 概要設計（ユースケース + ドメインモデル）
 Phase 3: ADR（必要時のみ）
-Phase 4: 詳細設計（ドメイン → UC → DB・外部サービス）
-Phase 5: TDD → 実装
+Phase 4: ベストプラクティス調査（必要時のみ）
+Phase 5: 詳細設計（ドメイン → UC → DB・外部サービス）
+Phase 6: TDD → 実装
 ```
 
 ## 前提ルール
 
 - docs は正本とし、各ドキュメントに `spec_runner`ヘッダーを付ける
+- バックエンドの設計はすべて `docs/バックエンド/` 配下に置く
 - 詳細設計は `01_ドメイン/` `02_ユースケース/` `03_DB・外部サービス/` の 3 層で構成する
 - ドメインを先に設計し、UC はドメインを参照する形で書く。ドメインの中に UC は入れない
 - `maps_to` は必ず設定する。パス推定に頼らない
@@ -38,20 +40,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 +61,7 @@ Phase 5: TDD → 実装
 テンプレート: `templates/02_概要設計/ユースケース一覧.md` / `templates/02_概要設計/ドメインモデル.md` / `templates/02_概要設計/システム全体俯瞰.md`
 
 ```
-docs/02_概要設計/
+docs/バックエンド/02_概要設計/
   ユースケース一覧.md
   ドメインモデル.md
   システム全体俯瞰.md
@@ -72,6 +74,8 @@ docs/02_概要設計/
 
 ## Phase 3: ADR（必要時のみ）
 
+ADR テンプレート: `templates/90_ADR/ADRテンプレート.md`
+
 1. 設計判断が必要な場合だけ ADR を作る
 2. 提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する
 3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
@@ -85,42 +89,64 @@ docs/02_概要設計/
 
 4. 採用案を概要設計へ反映してから次へ進む
 
-## Phase 4: 詳細設計
+## Phase 4: ベストプラクティス調査（必要時のみ）
+
+ADR で使用サービス・技術が確定した後、詳細設計に入る前に実施する。
+
+1. 「詳細設計に先立ち、ベストプラクティスを調査すべき技術・サービスはありますか？」とユーザーに確認する
+2. 調査する技術・サービスの公式ドキュメント URL を `.spec-runner/references/resources.md` に追記する（ユーザーが知っている URL ＋ AI が有用と判断した URL も積極的に追加する）
+3. WebSearch（resources.md の URL を起点に）でベストプラクティスを調査し、結果を保存する
+4. 調査不要の場合はスキップして次へ進む
+
+テンプレート: `templates/04_調査資料/{カテゴリ名}/{トピック名}.md`
+
+```
+docs/バックエンド/04_調査資料/
+  {カテゴリ名}/          # 例: AWS/, GCP/, 設計パターン/
+    {トピック名}.md      # 例: DynamoDB-キー設計.md, S3-アクセス制御.md
+```
+
+- 1 調査テーマ = 1 ファイル（複数テーマは別ファイルに分ける）
+- ユーザーに確認・承認を得てから次へ進む
+
+## Phase 5: 詳細設計
 
 ドメイン → UC → DB・外部サービス の順に設計する。
 
-### 4-1. ドメイン
+### 5-1. ドメイン
 
 テンプレート: `templates/03_詳細設計/01_ドメイン/{ドメイン名}.md`
 
 ```
-docs/03_詳細設計/01_ドメイン/
+docs/バックエンド/03_詳細設計/01_ドメイン/
   {ドメイン名}.md
 ```
 
-### 4-2. ユースケース
+### 5-2. ユースケース
 
 シーケンス図は UC ファイルに Mermaid で埋め込む。
 
 テンプレート: `templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md`
 
-> `has_frontend: true` の場合は各 UC ファイルに「画面レイアウト」セクションを含める。`false` なら削除する。
-
 ```
-docs/03_詳細設計/02_ユースケース/
+docs/バックエンド/03_詳細設計/02_ユースケース/
   UC-{日本語名}.md
 ```
 
-### 4-3. DB・外部サービス（必要時のみ）
+### 5-3. DB・外部サービス（必要時のみ）
 
 ```
-docs/03_詳細設計/03_DB・外部サービス/
+docs/バックエンド/03_詳細設計/03_DB・外部サービス/
   スキーマ定義.dbml
-  外部サービス.md
+  {プロバイダー名}/      # 例: AWS/, GCP/, Azure/
+    {サービス名}.md      # 例: S3.md, DynamoDB.md, Athena.md
 ```
 
+- 外部サービスはクラウドプロバイダー（AWS / GCP / Azure など）をカテゴリフォルダとし、中にサービス名の md を置く
+- `外部サービス.md` のような汎用名は使わない
+
 4. ユーザーに確認・承認を得る
 
-## Phase 5: TDD → 実装
+## Phase 6: TDD → 実装
 
 `test-driven-development` スキルへ移行する。

package/spec-runner/templates/.github/skills/ddd-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/03_DB/343/203/273/345/244/226/351/203/250/343/202/265/343/203/274/343/203/223/343/202/271/{/343/203/227/343/203/255/343/203/220/343/202/244/343/203/200/343/203/274/345/220/215}/{/343/202/265/343/203/274/343/203/223/343/202/271/345/220/215}.md

@@ -0,0 +1,24 @@
+---
+spec_runner:
+  type: external-service
+  provider: {プロバイダー名}
+  service: {サービス名}
+  maps_to: ""
+  depends_on: []
+---
+
+# {サービス名}
+
+## 用途・役割
+
+## 設定・接続情報
+
+| 項目 | 値 |
+|------|-----|
+|  |  |
+
+## データ構造・スキーマ
+
+## アクセス制御・権限
+
+## 注意事項

package/spec-runner/templates/.github/skills/ddd-seed/templates/04_/350/252/277/346/237/273/350/263/207/346/226/231/{/343/202/253/343/203/206/343/202/264/343/203/252/345/220/215}/{/343/203/210/343/203/224/343/203/203/343/202/257/345/220/215}.md

@@ -0,0 +1,20 @@
+---
+spec_runner:
+  type: research
+  topic: {トピック名}
+  category: {カテゴリ名}
+  searched_at: YYYY-MM-DD
+  sources:
+    - title: ""
+      url: ""
+---
+
+# {トピック名}
+
+## 調査目的
+
+## ベストプラクティス
+
+## 注意点・落とし穴
+
+## 本プロジェクトへの適用方針

package/spec-runner/templates/.github/skills/ddd-seed/templates/90_ADR/ADR/343/203/206/343/203/263/343/203/227/343/203/254/343/203/274/343/203/210.md

@@ -0,0 +1,48 @@
+---
+spec_runner:
+  node_id: adr.{decision_slug}
+  kind: adr
+---
+
+# {決定内容のタイトル}
+
+**ステータス**: 提案 / 採用 / 廃止 / 置換
+**日付**: YYYY-MM-DD
+
+## コンテキスト
+
+| 項目 | 内容 |
+|------|------|
+| 現在の状況 | {問題・課題} |
+| 要件 | {実現する必要があること} |
+| 制約 | {技術的・ビジネス的制約} |
+
+## 決定
+
+**採用案**: {案名}
+
+### 採用理由
+
+- {理由1}
+- {理由2}
+
+### 実装方針
+
+1. {方針1}
+2. {方針2}
+3. {方針3}
+
+## 影響
+
+| カテゴリ | 項目 | 内容 |
+|----------|------|------|
+| システム | 新規追加 | {コンポーネント} |
+| システム | 変更 | {コンポーネント} |
+| パフォーマンス | 処理速度 | {変化} |
+| コスト | 追加コスト | {影響} |
+| 制約 | 将来課題 | {課題} |
+
+### 反映が必要な文書
+
+- `docs/02_概要設計/{対象文書}.md`
+- `docs/03_詳細設計/src/{対象パス}.md`

package/spec-runner/templates/.github/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 も合わせて更新する。
@@ -29,22 +28,25 @@ Phase 1: 変更要求の整理と軽い影響調査
 Phase 2: ADR 作成（必要時）
 Phase 3: 影響ドキュメントの確定
 Phase 4: 概要設計の修正
-Phase 5: 詳細設計の修正
-Phase 6: TDD → 実装 → 検証
+Phase 5: ベストプラクティス調査（必要時）
+Phase 6: 詳細設計の修正
+Phase 7: 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 +62,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,26 +80,56 @@ Phase 6: TDD → 実装 → 検証
 
 概要設計では「何をするか」に留める。変更理由は ADR または本文で追えるようにする。
 
-1. `ユースケース一覧.md` / `システム全体俯瞰.md` / ADR を必要順に修正する
+### バックエンド
+
+1. `docs/バックエンド/02_概要設計/ユースケース一覧.md` / `システム全体俯瞰.md` / ADR を必要順に修正する
 2. `style: ddd` の場合: `ドメインモデル.md` も必要に応じて修正する
-3. 修正完了ごとにチェックリストを更新する
-4. 全概要設計の修正完了後、ユーザーに確認・承認を得る
 
-## Phase 5: 詳細設計の修正
+### フロントエンド（has_frontend: true かつ影響がある場合）
+
+1. `docs/フロントエンド/02_概要設計/画面一覧.md` / `画面遷移図.md` / `コンポーネント一覧.md` を必要順に修正する
+
+修正完了ごとにチェックリストを更新する。全概要設計の修正完了後、ユーザーに確認・承認を得る。
+
+## Phase 5: ベストプラクティス調査（必要時）
+
+概要設計の修正が承認された後、詳細設計の修正に入る前に実施する。
+
+1. 「詳細設計の修正に先立ち、ベストプラクティスを調査すべき技術・サービスはありますか？」とユーザーに確認する
+2. 調査する技術・サービスの公式ドキュメント URL を `.spec-runner/references/resources.md` に追記する（ユーザーが知っている URL ＋ AI が有用と判断した URL も積極的に追加する）
+3. WebSearch（resources.md の URL を起点に）でベストプラクティスを調査し、結果を保存する
+4. 調査不要の場合はスキップして次へ進む
+
+```
+docs/バックエンド/04_調査資料/
+  {カテゴリ名}/          # 例: AWS/, GCP/, 設計パターン/
+    {トピック名}.md
+```
+
+- ユーザーに確認・承認を得てから次へ進む
+
+## Phase 6: 詳細設計の修正
+
+### バックエンド
 
 `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 → 実装 → 検証
+## Phase 7: TDD → 実装 → 検証
 
 設計書修正が承認されたら `test-driven-development` スキルへ移行する。

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

@@ -8,7 +8,6 @@ spec_runner:
 
 **ステータス**: 提案 / 採用 / 廃止 / 置換
 **日付**: YYYY-MM-DD
-**決定者**: {名前}
 
 ## コンテキスト
 

package/spec-runner/templates/.github/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` へ引き渡す
-