spec-runner 1.1.13 → 1.1.17

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

@@ -41,16 +41,17 @@ Phase 6: TDD → 実装 → 検証
 3. 各案について概要・メリット・デメリット・適合性を示す
 4. ユーザーが案を決定する
 5. テンプレート `templates/90_ADR/ADRテンプレート.md` をコピーして生成する
-6. ファイル名は `mmdd-{日本語タイトル}.md` 形式にする（例: `0404-キャッシュ戦略の変更.md`）
+6. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
+7. ユーザーに確認・承認を得る
 
 ### ADR 配置ルール
 
-| 変更スコープ | 配置先 |
-|------------|--------|
-| 横断的な決定 | `docs/02_概要設計/90_ADR/` |
-| 特定ドメイン寄りの決定 | `docs/02_概要設計/<ドメイン>/90_ADR/` |
-
-MVP では `docs/02_概要設計/90_ADR/` に集約する。
+| 対象 | 配置先 |
+|------|--------|
+| システム横断の決定 | `docs/02_概要設計/90_ADR/全体/` |
+| ドメイン設計の決定 | `docs/02_概要設計/90_ADR/ドメイン/` |
+| UC フローの決定 | `docs/02_概要設計/90_ADR/UC/` |
+| DB・外部サービスの決定 | `docs/02_概要設計/90_ADR/DB/` |
 
 ## Phase 3: 影響ドキュメントの確定
 
@@ -62,7 +63,7 @@ MVP では `docs/02_概要設計/90_ADR/` に集約する。
 
 ## Phase 4: 概要設計の修正
 
-1. `ユースケース一覧.md` / `システム全体俯瞰.md` / UC 個別文書 / ADR を必要順に修正する
+1. `ユースケース一覧.md` / `システム全体俯瞰.md` / `ドメインモデル.md` / ADR を必要順に修正する
 2. 修正完了ごとにチェックリストを更新する
 3. 全概要設計の修正完了後、ユーザーに確認・承認を得る
 
@@ -73,10 +74,11 @@ MVP では `docs/02_概要設計/90_ADR/` に集約する。
 
 ## Phase 5: 詳細設計の修正
 
-1. `docs/03_詳細設計/src/**` を `src/` ミラーで修正する
-2. 補助設計が必要な場合だけ `docs/03_詳細設計/infrastructure/**` を修正する
-3. frontmatter の `depends_on` / `maps_to` を更新する
-4. ユーザーに最終確認を得る
+1. `docs/03_詳細設計/01_ドメイン/**` のドメイン設計を修正する
+2. `docs/03_詳細設計/02_ユースケース/**` の UC 設計を修正する
+3. DB・外部サービスの変更がある場合は `docs/03_詳細設計/03_DB・外部サービス/**` を修正する
+4. frontmatter の `depends_on` / `maps_to` を更新する
+5. ユーザーに最終確認を得る
 
 ## Phase 6: TDD → 実装 → 検証
 

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

@@ -2,9 +2,6 @@
 spec_runner:
   node_id: adr.{decision_slug}
   kind: adr
-  depends_on:
-    - overview.system_context
-  maps_to: []
 ---
 
 # {決定内容のタイトル}
@@ -21,35 +18,6 @@ spec_runner:
 | 要件 | {実現する必要があること} |
 | 制約 | {技術的・ビジネス的制約} |
 
-## 選択肢
-
-### 案1: {案1の名前}
-
-- 概要: {何をするか}
-- メリット:
-  - {メリット}
-- デメリット:
-  - {デメリット}
-- 適合性: {このプロジェクトにどう合うか}
-
-### 案2: {案2の名前}
-
-- 概要: {何をするか}
-- メリット:
-  - {メリット}
-- デメリット:
-  - {デメリット}
-- 適合性: {このプロジェクトにどう合うか}
-
-### 案3: {案3の名前}
-
-- 概要: {何をするか}
-- メリット:
-  - {メリット}
-- デメリット:
-  - {デメリット}
-- 適合性: {このプロジェクトにどう合うか}
-
 ## 決定
 
 **採用案**: {案名}

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

@@ -0,0 +1,127 @@
+---
+name: docs-driven-seed
+description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジェクトの初期テンプレートとして使い、architecture-skill-development でプロジェクト専用スキルに育てる。
+---
+
+# docs-driven-seed
+
+**DDD（ドメイン駆動設計）を採用するプロジェクト向け**の docs 正本開発フロー参照実装（種）。
+`architecture.yaml` の `style: ddd` のときに使う。レイヤード / CRUD 中心のプロジェクトは `simple-seed` を使う。
+
+**このスキルをそのまま使い続けない。`architecture-skill-development` で自プロジェクト専用スキルに育てることを前提とする。**
+
+## 全体フロー
+
+```
+Phase 1: 要件定義
+Phase 2: 概要設計（ユースケース + ドメインモデル）
+Phase 3: ADR（必要時のみ）
+Phase 4: 詳細設計（ドメイン → UC → DB・外部サービス）
+Phase 5: TDD → 実装
+```
+
+## 前提ルール
+
+- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- 詳細設計は `01_ドメイン/` `02_ユースケース/` `03_DB・外部サービス/` の 3 層で構成する
+- UC がドメインを使う。ドメインの中に UC は入れない
+- `maps_to` は必ず設定する。パス推定に頼らない
+- ユーザー承認なしに次フェーズへ進めない
+
+## Phase 1: 要件定義
+
+`architecture-definition` で完了済み。`docs/01_要件定義/` が存在することを確認して次へ進む。
+
+## Phase 2: 概要設計
+
+### 2-1. ユースケース一覧
+
+1. 要件定義からユースケースを洗い出す（Query / Command を意識）
+2. `docs/02_概要設計/ユースケース一覧.md` を作る
+3. ユーザーに確認・承認を得る
+
+### 2-2. ドメインモデル + システム全体俯瞰
+
+1. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を作る
+2. コンポーネント全体図・外部 IF を整理し `docs/02_概要設計/システム全体俯瞰.md` を作る
+3. ユーザーに確認・承認を得る
+
+### 出力
+
+テンプレート: `templates/02_概要設計/ユースケース一覧.md` / `templates/02_概要設計/ドメインモデル.md` / `templates/02_概要設計/システム全体俯瞰.md`
+
+```
+docs/02_概要設計/
+  ユースケース一覧.md
+  ドメインモデル.md
+  システム全体俯瞰.md
+  90_ADR/
+    全体/
+    ドメイン/
+    UC/
+    DB/
+```
+
+## Phase 3: ADR（必要時のみ）
+
+1. 設計判断が必要な場合だけ ADR を作る
+2. **提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する**
+3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
+
+| 対象 | 配置先 |
+|------|--------|
+| システム横断の決定 | `90_ADR/全体/` |
+| ドメイン設計の決定 | `90_ADR/ドメイン/` |
+| UC フローの決定 | `90_ADR/UC/` |
+| DB・外部サービスの決定 | `90_ADR/DB/` |
+
+4. 採用案を概要設計へ反映してから次へ進む
+
+## Phase 4: 詳細設計
+
+**ドメイン → UC → DB・外部サービス の順に設計する。**
+
+### 4-1. ドメイン
+
+テンプレート: `templates/03_詳細設計/01_ドメイン/{ドメイン名}.md`
+
+```
+docs/03_詳細設計/01_ドメイン/
+  {ドメイン名}.md
+```
+
+### 4-2. ユースケース
+
+シーケンス図は UC ファイルに Mermaid で埋め込む。
+
+テンプレート: `templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md`
+
+```
+docs/03_詳細設計/02_ユースケース/
+  UC-{日本語名}.md
+```
+
+### 4-3. DB・外部サービス（必要時のみ）
+
+```
+docs/03_詳細設計/03_DB・外部サービス/
+  スキーマ定義.dbml
+  外部サービス.md
+```
+
+4. ユーザーに確認・承認を得る
+
+## Phase 5: TDD → 実装
+
+`test-driven-development` スキルへ移行する。
+
+### 実装完了後
+
+- `@design-reviewer` — 設計書⇔実装の整合性チェック
+- `@code-reviewer` — コーディング規約への適合チェック
+
+## 原則
+
+- **このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てることを前提とする**
+- **ドメインを先に設計し、UC はドメインを参照する形で書く**
+- **`maps_to` は必ず設定する。パス推定に頼らない**

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

@@ -0,0 +1,15 @@
+---
+spec_runner:
+  node_id: requirement.ユビキタス言語辞書
+  kind: requirement
+  depends_on:
+    - requirement.要件定義
+  maps_to:
+    - docs/03_詳細設計/01_ドメイン/
+---
+
+# ユビキタス言語辞書
+
+| 用語 | 定義 | 補足 |
+|------|------|------|
+| {用語} | {定義} | {補足} |

package/spec-runner/templates/.claude/skills/docs-driven-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,34 @@
+---
+spec_runner:
+  node_id: requirement.要件定義
+  kind: requirement
+  depends_on: []
+  maps_to:
+    - docs/02_概要設計/
+---
+
+# 要件定義
+
+## 解決すべき課題・提供価値
+
+- {課題}
+- {提供価値}
+
+## 対象ユーザー
+
+- {ユーザー種別}: {説明}
+
+## 非機能要件
+
+| 項目 | 内容 |
+|------|------|
+| {パフォーマンス} | {要件} |
+| {セキュリティ} | {要件} |
+
+## スコープ外
+
+- {スコープ外の機能・要件}
+
+## 技術・ビジネス制約
+
+- {制約}

package/spec-runner/templates/.claude/skills/docs-driven-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/202/267/343/202/271/343/203/206/343/203/240/345/205/250/344/275/223/344/277/257/347/236/260.md

@@ -0,0 +1,33 @@
+---
+spec_runner:
+  node_id: overview.system_context
+  kind: overview_design
+  depends_on:
+    - overview.domain_model
+  maps_to:
+    - src/
+---
+
+# システム全体俯瞰
+
+## コンポーネント全体図
+
+```mermaid
+graph LR
+  User([ユーザー])
+  subgraph システム
+    {フロントエンド}
+    {バックエンド}
+  end
+  Ext([{外部サービス}])
+
+  User --> {フロントエンド}
+  {フロントエンド} --> {バックエンド}
+  {バックエンド} --> Ext
+```
+
+## 外部インターフェース
+
+| 外部システム | 方向 | プロトコル | 概要 |
+|------------|------|----------|------|
+| {外部システム名} | 受信 / 送信 | {HTTP / gRPC など} | {概要} |

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

@@ -0,0 +1,32 @@
+---
+spec_runner:
+  node_id: overview.domain_model
+  kind: overview_design
+  depends_on:
+    - overview.use_case_list
+  maps_to:
+    - docs/03_詳細設計/01_ドメイン/
+---
+
+# ドメインモデル
+
+集約と境界コンテキストの概念モデル。DBスキーマ・永続化の詳細はここに書かない。
+
+## 境界コンテキスト
+
+```mermaid
+graph LR
+  subgraph {コンテキストA}
+    {集約A}
+  end
+  subgraph {コンテキストB}
+    {集約B}
+  end
+  {コンテキストA} -->|下流| {コンテキストB}
+```
+
+## 集約一覧
+
+| 境界コンテキスト | 集約 | 責務 |
+|----------------|------|------|
+| {コンテキスト名} | {集約名} | {責務} |

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

@@ -0,0 +1,15 @@
+---
+spec_runner:
+  node_id: overview.use_case_list
+  kind: overview_design
+  depends_on:
+    - requirement.要件定義
+  maps_to:
+    - docs/03_詳細設計/02_ユースケース/
+---
+
+# ユースケース一覧
+
+| UC ID | UC名 | 種別 | 概要 |
+|-------|------|------|------|
+| UC-{番号} | {UC名} | Command / Query | {概要} |

package/spec-runner/templates/.claude/skills/docs-driven-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/01_/343/203/211/343/203/241/343/202/244/343/203/263/{/343/203/211/343/203/241/343/202/244/343/203/263/345/220/215}.md

@@ -0,0 +1,56 @@
+---
+spec_runner:
+  node_id: detail.domain.{ドメイン名}
+  kind: detailed_design
+  depends_on:
+    - overview.domain_model
+  maps_to:
+    - src/domain/{ドメイン名}/
+---
+
+# {ドメイン名} ドメイン詳細設計
+
+## 責務
+
+- {このドメインが扱うビジネス概念}
+- {このドメインの不変条件・制約}
+
+## 集約
+
+```mermaid
+classDiagram
+  class {集約ルート} {
+    +{ID型} id
+    +{値オブジェクト} {フィールド名}
+    +{操作}() {戻り値型}
+  }
+  class {エンティティ} {
+    +{ID型} id
+  }
+  class {値オブジェクト} {
+    +{型} {フィールド名}
+  }
+  {集約ルート} "1" --> "0..*" {エンティティ} : 含む
+  {集約ルート} --> {値オブジェクト} : 持つ
+```
+
+| 集約 | 責務 | ルートエンティティ |
+|------|------|----------------|
+| {集約名} | {責務} | {ルートエンティティ名} |
+
+## 値オブジェクト
+
+| 値オブジェクト | 制約・ルール |
+|--------------|------------|
+| {名前} | {制約} |
+
+## ドメインルール
+
+- {ルール1}
+- {ルール2}
+
+## テスト観点
+
+- {正常系の観点}
+- {ルール違反の観点}
+- {境界条件の観点}

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

@@ -0,0 +1,55 @@
+---
+spec_runner:
+  node_id: detail.usecase.{UC名}
+  kind: detailed_design
+  depends_on:
+    - overview.use_case_list
+    - detail.domain.{ドメイン名}
+  maps_to:
+    - src/application/{uc_name}/
+    - tests/application/{uc_name}/
+---
+
+# UC-{UC名} 詳細設計
+
+## 概要
+
+- 使用するドメイン: {ドメイン名}
+- トリガー: {何がこのUCを呼び出すか}
+- 事前条件: {UCが成立するために必要な状態}
+- 事後条件: {UC完了後の状態}
+
+## 入出力
+
+| 種別 | 名前 | 型 | 説明 |
+|------|------|----|------|
+| 入力 | {入力名} | {型} | {説明} |
+| 出力 | {出力名} | {型} | {説明} |
+
+## 主要フロー
+
+```mermaid
+sequenceDiagram
+  {シーケンス図}
+```
+
+1. {ステップ1}
+2. {ステップ2}
+
+## 判断条件
+
+| 判断ポイント | 条件 | アクション |
+|------------|------|----------|
+| {判断ポイント} | {条件} | {アクション} |
+
+## エラーポリシー
+
+| エラーケース | 発生条件 | 対応 |
+|------------|---------|------|
+| {エラーケース} | {発生条件} | {対応} |
+
+## テスト観点
+
+- {正常系の観点}
+- {異常系の観点}
+- {境界条件の観点}

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

@@ -27,22 +27,25 @@ Phase 5: architecture contract 化
 
 ## Phase 2: 要件とユースケースの抽出
 
-1. 既存機能からユースケースを逆算する
+1. `current-system-inventory.md` を起点に、既存機能からユースケースを逆算する
 2. `docs/01_要件定義/要件定義.md` と `docs/02_概要設計/ユースケース一覧.md` の draft を作る
-3. ユーザーに確認・承認を得る
+3. ドメイン用語が識別できたら `docs/01_要件定義/ユビキタス言語辞書.md` も draft する
+4. ユーザーに確認・承認を得る
 
 ## Phase 3: 概要設計の draft 化
 
-1. `docs/02_概要設計/システム全体俯瞰.md` を作る
-2. 必要なら ADR 候補も洗い出す
-3. ユーザーに確認・承認を得る
+1. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を draft する
+2. `docs/02_概要設計/システム全体俯瞰.md` を作る
+3. 必要なら ADR 候補も洗い出す（配置先は `90_ADR/全体/` / `ドメイン/` / `UC/` / `DB/`）
+4. ユーザーに確認・承認を得る
 
 ## Phase 4: 詳細設計の draft 化
 
-1. `docs/03_詳細設計/src/**` を `src/` ミラーで作る
-2. `maps_to` に対応コードとテストを入れる
-3. 補助設計が必要なら `docs/03_詳細設計/infrastructure/**` を作る
-4. ユーザーに確認・承認を得る
+1. ドメインごとにビジネスルール・集約を整理し `docs/03_詳細設計/01_ドメイン/{ドメイン名}.md` を draft する
+2. UC ごとに `docs/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を draft する
+3. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/03_DB・外部サービス/` を作る
+4. 各ファイルの `maps_to` に対応コードとテストを入れる
+5. ユーザーに確認・承認を得る
 
 ## Phase 5: architecture contract 化
 

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

@@ -68,6 +68,8 @@ Phase 4: 影響範囲の反映確認
 
 ## Phase 3: skill / rule / agent / template の修正
 
+ファイルを作成・修正する前に **`.claude/rules/harness-formats.md`** を読み、フォーマットを確認する。
+
 1. 対象ファイルを特定する
 2. 意図が変わらない最小差分で修正する
 3. 片系だけでなく、対応するテンプレートも揃えて更新する
@@ -91,6 +93,8 @@ Phase 4: 影響範囲の反映確認
 - Claude / Copilot の対応ファイルに反映漏れがないか
 - 今回限りのノイズをルール化していないか
 - skill 名・起動条件・使いどころを変更した場合、`CLAUDE.md` の記述と一致しているか
+- `CLAUDE.md` が肥大化していないか（20行超えたら `rules/` や `skills/` へ移動を検討する）
+- docs 構造・命名規則・node_id 体系に影響する変更の場合、`design-docs.md` と整合しているか
 
 ## 原則
 

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

@@ -0,0 +1,105 @@
+---
+name: simple-seed
+description: レイヤードアーキテクチャ / CRUD 中心のプロジェクト向け docs 正本開発フロー。ドメイン層を持たず UC・サービス層で設計する。architecture.yaml の style: layered のときに使う。
+---
+
+# simple-seed
+
+**レイヤードアーキテクチャ / CRUD 中心のプロジェクト向け**の docs 正本開発フロー参照実装（種）。
+`architecture.yaml` の `style: layered` のときに使う。DDD が必要なプロジェクトは `docs-driven-seed` を使う。
+
+**このスキルをそのまま使い続けない。`architecture-skill-development` で自プロジェクト専用スキルに育てることを前提とする。**
+
+## 全体フロー
+
+```
+Phase 1: 要件定義
+Phase 2: 概要設計（ユースケース + システム全体俯瞰）
+Phase 3: ADR（必要時のみ）
+Phase 4: 詳細設計（UC → DB・外部サービス）
+Phase 5: TDD → 実装
+```
+
+## 前提ルール
+
+- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- 詳細設計は `01_ユースケース/` `02_DB・外部サービス/` の 2 層で構成する
+- `maps_to` は必ず設定する。パス推定に頼らない
+- ユーザー承認なしに次フェーズへ進めない
+
+## Phase 1: 要件定義
+
+`architecture-definition` で完了済み。`docs/01_要件定義/` が存在することを確認して次へ進む。
+
+## Phase 2: 概要設計
+
+テンプレート: `../docs-driven-seed/templates/02_概要設計/`（ユースケース一覧・システム全体俯瞰のみ）
+
+1. 要件定義からユースケースを洗い出す（Query / Command を意識）
+2. テンプレートをコピーして `docs/02_概要設計/ユースケース一覧.md` を作る
+3. コンポーネント全体図・外部 IF を整理し `docs/02_概要設計/システム全体俯瞰.md` を作る
+4. ユーザーに確認・承認を得る
+
+### 出力
+
+```
+docs/02_概要設計/
+  ユースケース一覧.md
+  システム全体俯瞰.md
+  90_ADR/
+    全体/
+    UC/
+    DB/
+```
+
+## Phase 3: ADR（必要時のみ）
+
+1. 設計判断が必要な場合だけ ADR を作る
+2. **提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する**
+3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
+
+| 対象 | 配置先 |
+|------|--------|
+| システム横断の決定 | `90_ADR/全体/` |
+| UC フローの決定 | `90_ADR/UC/` |
+| DB・外部サービスの決定 | `90_ADR/DB/` |
+
+4. 採用案を概要設計へ反映してから次へ進む
+
+## Phase 4: 詳細設計
+
+**UC → DB・外部サービス の順に設計する。**
+
+### 4-1. ユースケース
+
+テンプレート: `templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md`
+
+```
+docs/03_詳細設計/01_ユースケース/
+  UC-{日本語名}.md
+```
+
+### 4-2. DB・外部サービス（必要時のみ）
+
+```
+docs/03_詳細設計/02_DB・外部サービス/
+  スキーマ定義.dbml
+  外部サービス.md
+```
+
+3. ユーザーに確認・承認を得る
+
+## Phase 5: TDD → 実装
+
+`test-driven-development` スキルへ移行する。
+
+### 実装完了後
+
+- `@design-reviewer` — 設計書⇔実装の整合性チェック
+- `@code-reviewer` — コーディング規約への適合チェック
+
+## 原則
+
+- **このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てることを前提とする**
+- **ドメイン層は持たない。ビジネスロジックは UC / サービス層で表現する**
+- **`maps_to` は必ず設定する。パス推定に頼らない**

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

@@ -0,0 +1,53 @@
+---
+spec_runner:
+  node_id: detail.usecase.{UC名}
+  kind: detailed_design
+  depends_on:
+    - overview.use_case_list
+  maps_to:
+    - src/application/{uc_name}/
+    - tests/application/{uc_name}/
+---
+
+# UC-{UC名} 詳細設計
+
+## 概要
+
+- トリガー: {何がこのUCを呼び出すか}
+- 事前条件: {UCが成立するために必要な状態}
+- 事後条件: {UC完了後の状態}
+
+## 入出力
+
+| 種別 | 名前 | 型 | 説明 |
+|------|------|----|------|
+| 入力 | {入力名} | {型} | {説明} |
+| 出力 | {出力名} | {型} | {説明} |
+
+## 主要フロー
+
+```mermaid
+sequenceDiagram
+  {シーケンス図}
+```
+
+1. {ステップ1}
+2. {ステップ2}
+
+## 判断条件
+
+| 判断ポイント | 条件 | アクション |
+|------------|------|----------|
+| {判断ポイント} | {条件} | {アクション} |
+
+## エラーポリシー
+
+| エラーケース | 発生条件 | 対応 |
+|------------|---------|------|
+| {エラーケース} | {発生条件} | {対応} |
+
+## テスト観点
+
+- {正常系の観点}
+- {異常系の観点}
+- {境界条件の観点}