spec-runner 1.7.0 → 1.8.0

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

@@ -0,0 +1,121 @@
+---
+name: frontend-seed
+description: フロントエンド向け docs 正本開発フローの種。画面・コンポーネント設計を中心に、要件定義から詳細設計まで進める。architecture-skill-development でプロジェクト専用スキルに育てる。
+---
+
+# frontend-seed
+
+## 前提: architecture.yaml の読み込み
+
+開始前に `.spec-runner/architecture/architecture.yaml` を読み、以下を確認する:
+
+| キー | 用途 |
+|------|------|
+| `has_frontend` | `true` であることを確認 |
+| `folder_structure` | `maps_to` パスの基準として参照する |
+
+設計フェーズで新たな方針・コンポーネントが確定したら、都度 architecture.yaml を最新状態に保つ。
+
+## 全体フロー
+
+```
+Phase 1: 要件定義
+Phase 2: 概要設計（画面一覧 + 画面遷移図 + コンポーネント一覧）
+Phase 3: ADR（必要時のみ）
+Phase 4: 詳細設計（画面 → コンポーネント）
+Phase 5: TDD → 実装
+```
+
+## 前提ルール
+
+- docs は正本とし、各ドキュメントに `spec_runner` ヘッダーを付ける
+- 詳細設計は `01_画面/` `02_コンポーネント/` の 2 層で構成する
+- 画面を先に設計し、コンポーネントは画面を参照する形で書く
+- `maps_to` は必ず設定する。パス推定に頼らない
+- ユーザー承認なしに次フェーズへ進めない
+
+## Phase 1: 要件定義
+
+`architecture-definition` で完了済み。`docs/フロントエンド/01_要件定義/` が存在することを確認して次へ進む。
+
+存在しない場合はテンプレートから作成し、ユーザーに確認・承認を得る。
+
+テンプレート: `templates/01_要件定義/要件定義.md`
+
+```
+docs/フロントエンド/01_要件定義/
+  要件定義.md
+```
+
+## Phase 2: 概要設計
+
+### 2-1. 画面一覧
+
+1. 要件定義から画面を洗い出す
+2. `docs/フロントエンド/02_概要設計/画面一覧.md` を作る
+3. ユーザーに確認・承認を得る
+
+### 2-2. 画面遷移図
+
+1. 画面一覧をもとに遷移フローを Mermaid で整理する
+2. `docs/フロントエンド/02_概要設計/画面遷移図.md` を作る
+3. ユーザーに確認・承認を得る
+
+### 2-3. コンポーネント一覧
+
+1. 画面一覧から共通コンポーネントを抽出する
+2. `docs/フロントエンド/02_概要設計/コンポーネント一覧.md` を作る
+3. ユーザーに確認・承認を得る
+
+### 出力
+
+テンプレート: `templates/02_概要設計/画面一覧.md` / `templates/02_概要設計/画面遷移図.md` / `templates/02_概要設計/コンポーネント一覧.md`
+
+```
+docs/フロントエンド/02_概要設計/
+  画面一覧.md
+  画面遷移図.md
+  コンポーネント一覧.md
+  90_ADR/
+```
+
+## Phase 3: ADR（必要時のみ）
+
+1. 設計判断が必要な場合だけ ADR を作る
+2. 提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する
+3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は `90_ADR/`
+
+4. 採用案を概要設計へ反映してから次へ進む
+
+## Phase 4: 詳細設計
+
+画面 → コンポーネント の順に設計する。
+
+### 4-1. 画面
+
+カテゴリ（機能ドメイン）でディレクトリを切り、画面ごとに 1 ファイル作成する。
+
+テンプレート: `templates/03_詳細設計/01_画面/{カテゴリ名}/{画面名}.md`
+
+```
+docs/フロントエンド/03_詳細設計/01_画面/
+  {カテゴリ名}/
+    {画面名}.md
+```
+
+### 4-2. コンポーネント
+
+概要設計のコンポーネント一覧をもとに、共通コンポーネントごとに 1 ファイル作成する。
+
+テンプレート: `templates/03_詳細設計/02_コンポーネント/{コンポーネント名}.md`
+
+```
+docs/フロントエンド/03_詳細設計/02_コンポーネント/
+  {コンポーネント名}.md
+```
+
+ユーザーに確認・承認を得る。
+
+## Phase 5: TDD → 実装
+
+`test-driven-development` スキルへ移行する。

package/spec-runner/templates/.claude/skills/frontend-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

@@ -0,0 +1,35 @@
+---
+spec_runner:
+  node_id: frontend.requirement.要件定義
+  kind: requirement
+  depends_on: []
+  maps_to:
+    - docs/フロントエンド/02_概要設計/
+---
+
+# 要件定義
+
+## 解決すべき課題・提供価値
+
+- {課題}
+- {提供価値}
+
+## 対象ユーザー
+
+- {ユーザー種別}: {説明}
+
+## 非機能要件
+
+| 項目 | 内容 |
+|------|------|
+| {パフォーマンス} | {要件} |
+| {アクセシビリティ} | {要件} |
+| {対応デバイス} | {要件} |
+
+## スコープ外
+
+- {スコープ外の機能・画面}
+
+## 技術・ビジネス制約
+
+- {制約}

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

@@ -0,0 +1,19 @@
+---
+spec_runner:
+  node_id: frontend.overview.コンポーネント一覧
+  kind: overview_design
+  depends_on:
+    - frontend.overview.画面一覧
+  maps_to:
+    - docs/フロントエンド/03_詳細設計/02_コンポーネント/
+---
+
+# コンポーネント一覧
+
+<!-- 共通コンポーネントのみ記載。画面固有のものは各画面MDで管理する -->
+
+## {カテゴリ名}（例: フォーム、ナビゲーション、フィードバック）
+
+| コンポーネントID | コンポーネント名 | 概要 | 使用画面 |
+|----------------|----------------|------|---------|
+| CMP-{番号} | {コンポーネント名} | {概要} | {画面名}, {画面名} |

package/spec-runner/templates/.claude/skills/frontend-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//347/224/273/351/235/242/344/270/200/350/246/247.md

@@ -0,0 +1,25 @@
+---
+spec_runner:
+  node_id: frontend.overview.画面一覧
+  kind: overview_design
+  depends_on:
+    - frontend.requirement.要件定義
+  maps_to:
+    - docs/フロントエンド/03_詳細設計/01_画面/
+---
+
+# 画面一覧
+
+<!-- カテゴリは機能領域で分ける。例: 認証、ダッシュボード、設定 など -->
+
+## {カテゴリ名}
+
+| 画面ID | 画面名 | URL | 概要 |
+|--------|--------|-----|------|
+| SCR-{番号} | {画面名} | /{path} | {概要} |
+
+## {カテゴリ名}
+
+| 画面ID | 画面名 | URL | 概要 |
+|--------|--------|-----|------|
+| SCR-{番号} | {画面名} | /{path} | {概要} |

package/spec-runner/templates/.claude/skills/frontend-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//347/224/273/351/235/242/351/201/267/347/247/273/345/233/263.md

@@ -0,0 +1,23 @@
+---
+spec_runner:
+  node_id: frontend.overview.画面遷移図
+  kind: overview_design
+  depends_on:
+    - frontend.overview.画面一覧
+  maps_to:
+    - docs/フロントエンド/03_詳細設計/01_画面/
+---
+
+# 画面遷移図
+
+```mermaid
+flowchart TD
+  {画面A}([{画面名}]) -->|{操作}| {画面B}([{画面名}])
+  {画面B} -->|{操作}| {画面C}([{画面名}])
+```
+
+## 遷移説明
+
+| 遷移元 | 操作 | 遷移先 | 条件 |
+|--------|------|--------|------|
+| {画面名} | {操作} | {画面名} | {条件} |

package/spec-runner/templates/.claude/skills/frontend-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/01_/347/224/273/351/235/242/{/343/202/253/343/203/206/343/202/264/343/203/252/345/220/215}/{/347/224/273/351/235/242/345/220/215}.md

@@ -0,0 +1,65 @@
+---
+spec_runner:
+  node_id: frontend.detail.画面.{画面名}
+  kind: detailed_design
+  depends_on:
+    - frontend.overview.画面一覧
+    - frontend.overview.画面遷移図
+  maps_to:
+    - src/app/{path}/page.tsx
+---
+
+# {画面名}
+
+## 概要
+
+- **画面ID**: SCR-{番号}
+- **URL**: /{path}
+- **目的**: {この画面が達成すること}
+
+## レイアウト
+
+```
++---------------------------+
+| {ヘッダー}                |
++---------------------------+
+| {メインコンテンツ}         |
+|                           |
++---------------------------+
+| {フッター}                |
++---------------------------+
+```
+
+## 表示要素
+
+| 要素 | 種別 | 概要 |
+|------|------|------|
+| {要素名} | テキスト / ボタン / フォーム / リスト | {概要} |
+
+## 使用コンポーネント
+
+| コンポーネント | 用途 |
+|--------------|------|
+| CMP-{番号} {コンポーネント名} | {用途} |
+
+## インタラクション
+
+| 操作 | 処理 | 遷移先 |
+|------|------|--------|
+| {操作} | {処理内容} | {画面名} / なし |
+
+## API連携
+
+| API | 呼び出しタイミング | 概要 |
+|-----|-----------------|------|
+| {エンドポイント} | {タイミング} | {概要} |
+
+## バリデーション
+
+- {バリデーションルール}
+
+## テスト観点
+
+- {正常系の観点}
+- {エラー表示の観点}
+- {権限・認証の観点}

package/spec-runner/templates/.claude/skills/frontend-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/02_/343/202/263/343/203/263/343/203/235/343/203/274/343/203/215/343/203/263/343/203/210/{/343/202/263/343/203/263/343/203/235/343/203/274/343/203/215/343/203/263/343/203/210/345/220/215}.md

@@ -0,0 +1,41 @@
+---
+spec_runner:
+  node_id: frontend.detail.component.{コンポーネント名}
+  kind: detailed_design
+  depends_on:
+    - frontend.overview.コンポーネント一覧
+  maps_to:
+    - src/components/{コンポーネント名}/
+---
+
+# {コンポーネント名}
+
+## 概要
+
+- **コンポーネントID**: CMP-{番号}
+- **目的**: {このコンポーネントが提供する UI・機能}
+- **使用画面**: {画面名}, {画面名}
+
+## Props
+
+| Prop名 | 型 | 必須 | デフォルト | 概要 |
+|--------|-----|------|-----------|------|
+| {prop名} | {型} | ○ / - | {値} | {概要} |
+
+## 表示パターン
+
+| パターン | 条件 | 表示内容 |
+|---------|------|---------|
+| {パターン名} | {条件} | {表示内容} |
+
+## イベント
+
+| イベント | 発火条件 | コールバック |
+|---------|---------|------------|
+| {イベント名} | {条件} | {コールバック名} |
+
+## テスト観点
+
+- {正常表示の観点}
+- {各パターンの観点}
+- {アクセシビリティの観点}

package/spec-runner/templates/.claude/skills/frontend-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/90_ADR/ADR-{/346/227/245/346/234/254/350/252/236/345/220/215}.md

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

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

@@ -1,6 +1,6 @@
 ---
 name: simple-seed
-description: レイヤードアーキテクチャ / CRUD 中心のプロジェクト向け docs 正本開発フロー。ドメイン層を持たず UC・サービス層で設計する。architecture.yaml の style: layered のときに使う。
+description: レイヤードアーキテクチャ / CRUD 中心のプロジェクト向け docs 正本開発フロー（バックエンド担当）。ドメイン層を持たず UC・サービス層で設計する。architecture.yaml の style: layered のときに使う。
 ---
 
 # simple-seed
@@ -12,7 +12,7 @@ description: レイヤードアーキテクチャ / CRUD 中心のプロジェ
 | キー | 用途 |
 |------|------|
 | `style` | このスキル（`layered`）が適切かを確認 |
-| `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_DB・外部サービス/` の 2 層で構成する
 - `maps_to` は必ず設定する。パス推定に頼らない
 - 実装ファイルのパスは UC ドキュメント本文に書かない。`maps_to` ヘッダーで管理する
@@ -37,21 +38,21 @@ Phase 5: TDD → 実装
 
 ## Phase 1: 要件定義
 
-`architecture-definition` で完了済み。`docs/01_要件定義/` が存在することを確認して次へ進む。
+`architecture-definition` で完了済み。`docs/バックエンド/01_要件定義/` が存在することを確認して次へ進む。
 
 ## Phase 2: 概要設計
 
 テンプレート: `templates/02_概要設計/`
 
 1. 要件定義からユースケースを洗い出す（Query / Command を意識）
-2. テンプレートをコピーして `docs/02_概要設計/ユースケース一覧.md` を作る
-3. コンポーネント全体図・外部 IF を整理し `docs/02_概要設計/システム全体俯瞰.md` を作る
+2. テンプレートをコピーして `docs/バックエンド/02_概要設計/ユースケース一覧.md` を作る
+3. コンポーネント全体図・外部 IF を整理し `docs/バックエンド/02_概要設計/システム全体俯瞰.md` を作る
 4. ユーザーに確認・承認を得る
 
 ### 出力
 
 ```
-docs/02_概要設計/
+docs/バックエンド/02_概要設計/
   ユースケース一覧.md
   システム全体俯瞰.md
   90_ADR/
@@ -82,17 +83,15 @@ UC → DB・外部サービス の順に設計する。
 
 テンプレート: `templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md`
 
-> `has_frontend: true` の場合は各 UC ファイルに「画面レイアウト」セクションを含める。`false` なら削除する。
-
 ```
-docs/03_詳細設計/01_ユースケース/
+docs/バックエンド/03_詳細設計/01_ユースケース/
   UC-{日本語名}.md
 ```
 
 ### 4-2. DB・外部サービス（必要時のみ）
 
 ```
-docs/03_詳細設計/02_DB・外部サービス/
+docs/バックエンド/03_詳細設計/02_DB・外部サービス/
   スキーマ定義.dbml
   外部サービス.md
 ```

package/spec-runner/templates/.claude/skills/simple-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_詳細設計/01_ユースケース/
+    - docs/バックエンド/03_詳細設計/01_ユースケース/
 ---
 
 # ユースケース一覧

package/spec-runner/templates/.claude/skills/simple-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/01_/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

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

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

@@ -4,16 +4,6 @@ applyTo: "docs/**"
 
 # 設計書共通ルール
 
-## フェーズ管理
-
-- ユーザー承認なしにフェーズを進めない
-- フェーズは必ず `要件定義 -> 概要設計 -> 詳細設計 -> TDD -> 実装` の順に進める
-
-## テンプレート
-
-- 設計書は必ずテンプレートをコピーして生成する。独自にゼロから作成しない
-- 手順: テンプレートを読む → 出力先へコピーする → プレースホルダーを埋める
-
 ## ヘッダー
 
 - `docs/**` の全設計書にヘッダーを付ける
@@ -40,6 +30,8 @@ spec_runner:
 
 ### node_id 体系
 
+#### バックエンド
+
 | 対象 | node_id 形式 | 例 |
 |------|-------------|-----|
 | 要件定義 | `requirement.{名前}` | `requirement.要件定義` |
@@ -51,26 +43,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` |
 
 ## 文書品質
 
@@ -90,8 +98,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/.github/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` を並走させる |