---
name: fullstack-seed
description: フロントエンド・バックエンドを一体管理する docs 正本開発フローの種。フルスタック構成の新規プロジェクト向け統合テンプレート。architecture-skill-development でプロジェクト専用スキルに育てる。
---

# fullstack-seed

## 前提

`.spec-runner/architecture/architecture.yaml` を読む: `scope`（all / backend / frontend）と `folder_structure`（`maps_to` の基準）。設計で方針が確定するたび architecture.yaml を最新に保つ。

`scope` 未設定ならユーザーに確認して書き込み、**このスキルから scope 不一致のセクション（`> scope:` 注釈）を削除して最適化する**。

## ルール

- docs が正本。全ドキュメントに `spec_runner` ヘッダー。`maps_to` 必須（パス推定禁止）
- 設計ドキュメントは `docs/` に一元管理（バック・フロントを分けない）
- ユーザー承認なしに次フェーズへ進まない

```
Phase 1: 要件定義
Phase 2: 概要設計
Phase 3: ADR（必要時のみ）
Phase 4: ベストプラクティス調査（必要時のみ）
Phase 5: 詳細設計（バックエンド -> フロントエンド）
Phase 6: TDD -> 実装
```

テンプレートは全てこのスキルの `templates/` 配下。`templates/{相対パス}` を `docs/{相対パス}` にコピーして使う。

## Phase 1: 要件定義

`architecture-definition` で完了済み。`docs/01_要件定義/` の存在を確認して次へ。なければテンプレートから作成 -> 承認。

- `要件定義.md` — 機能要件は「受け入れ基準」に `REQ-XX` 形式で書く（詳細設計の `satisfies` が引き受ける）
- `ユビキタス言語辞書.md`（scope に backend がある場合、ドメイン用語が識別できたら）
- `00_インプット資料/` に企画書・ヒアリングメモ等

## Phase 2: 概要設計

順に作成し、各ステップで承認を得る。

### 2-1. システム全体設計

`01_システム全体設計/システム俯瞰図.md`（コンポーネント全体図・外部 IF）-> `システム構成図.md`（アーキテクチャ・インフラ・デプロイ方針）。

### 2-2. バックエンド概要設計

> `scope: frontend` はスキップ。

`02_バックエンド/ドメインモデル.md`（集約・境界コンテキスト）-> `業務ロジック概要.md`（主要ロジック・計算式）-> `状態遷移図.md`（主要データのライフサイクル）。

### 2-3. フロントエンド概要設計

> `scope: backend` はスキップ。

`03_フロントエンド/画面一覧.md` -> `画面遷移図.md`（Mermaid）-> `コンポーネント構成.md`。
「デザインガイドラインや HTML/CSS の提供はありますか？」と確認 -> あれば `03_フロントエンド/UIデザイン/` に配置案内。

### 2-4. インターフェース設計

> `scope: backend` / `frontend` はスキップ。

`04_インターフェース設計/API仕様.md`（パス⇔UC の目次。詳細は各 UC の `公開IF` が正本）。外部連携があれば `外部API連携仕様.md`。

## Phase 3: ADR（必要時のみ）

設計判断が必要な場合だけ。3案比較 -> ドキュメントには採用案と理由のみ。配置・命名は `.github/instructions/design-docs.instructions.md` の ADR テーブル。採用案を概要設計へ反映してから次へ。

テンプレート: `templates/02_概要設計/90_ADR/{mmdd}-{日本語タイトル}.md`

## Phase 4: ベストプラクティス調査（必要時のみ）

「詳細設計に先立ち調査すべき技術はありますか？」と確認。調査する場合: URL を `.spec-runner/references/resources.md` に追記（AI が有用と判断した URL も追加）-> WebSearch -> `docs/04_調査資料/{カテゴリ名}/{トピック名}.md`（1テーマ1ファイル）-> 承認。

## Phase 5: 詳細設計

本文はハイブリッド仕様YAML形式（design-docs.instructions.md）。バックエンド -> フロントエンドの順。

### 5-1. バックエンド詳細設計

> `scope: frontend` はスキップ。

共通ポリシー -> ドメイン -> UC -> DB・外部サービスの順:

```
docs/03_詳細設計/01_バックエンド/
  00_共通/エラーポリシー.md                       # 例外型・ステータスコード・リトライ・ロールバック方針
  01_ドメイン/{ドメイン名}.md
  02_ユースケース/{カテゴリ名}/UC-{日本語名}.md   # カテゴリ = 集約・境界コンテキスト
  03_DB・外部サービス/                            # 必要時のみ
    DB/スキーマ定義.dbml, マイグレーション戦略.md
    {プロバイダー名}/{サービス名}.md               # AWS / GCP 等をカテゴリに
```

承認を得る。

### 5-2. フロントエンド詳細設計

> `scope: backend` はスキップ。

画面 -> コンポーネントの順:

```
docs/03_詳細設計/02_フロントエンド/
  01_画面/{カテゴリ名}/{画面名}.md               # カテゴリ = 機能ドメイン
  02_コンポーネント/{カテゴリ名}/{コンポーネント名}.md
```

承認を得る。

## Phase 5.5: マイグレーション戦略

> `scope: frontend` はスキップ。

スキーマ確定後・TDD 前。Migration ツール・命名規則・Up/Down 方針 -> ゼロダウンタイム要否 -> ロールバック・既存データの扱い -> `DB/マイグレーション戦略.md` 作成。

## Phase 6: TDD -> 実装

`test-driven-development` スキルへ。

継続開発: 既存機能変更 -> `design-change` / 新機能追加 -> プロジェクト専用スキル（または `fullstack-seed`）。