spec-runner 1.9.0 → 2.0.1

package/README.md

@@ -51,8 +51,9 @@ curl -sSL https://raw.githubusercontent.com/TEEE88/spec-runner/main/install.sh |
 - `architecture-definition`: 新規プロジェクトで docs と architecture contract を起こす
 - `existing-project-to-docs`: 既存コードから docs の draft と構造化情報を起こす
 - `architecture-skill-development`: architecture contract から project 専用 skill を育てる
-- `docs-driven-seed`: DDD 向けの project 専用 skill の種（`style: ddd` のとき）
+- `ddd-seed`: DDD 向けの project 専用 skill の種（`style: ddd` のとき）
 - `simple-seed`: レイヤードアーキテクチャ向けの project 専用 skill の種（`style: layered` のとき）
+- `frontend-seed`: フロントエンド向けの project 専用 skill の種
 
 **開発ループ用**（日常的に使う）
 

package/bin/spec-runner-installer.js

@@ -119,6 +119,7 @@ function copySettingsJsonWithMerge(src, dest, archiveRoot) {
     fs.copyFileSync(dest, ap);
   }
   writeFileText(dest, JSON.stringify(merged, null, 2) + "\n");
+  console.log(`  マージ: ${path.relative(CWD, dest)}`);
 }
 
 function appendToGitignore(lines, dest) {
@@ -351,12 +352,6 @@ function main() {
     throw new Error(`Claude テンプレートが見つかりません: ${CLAUDE_TEMPLATE_DIR}`);
   }
 
-  // CLAUDE.md をプロジェクトルートへインストール（target によらず常に配置）
-  const claudeMdSrc = path.join(TEMPLATE_ROOT, "CLAUDE.md");
-  if (exists(claudeMdSrc)) {
-    copyFileWithPolicy(claudeMdSrc, path.join(CWD, "CLAUDE.md"), archiveRoot);
-  }
-
   // .spec-runner/scripts を導入（target によらず常に配置）
   const specRunnerTemplateDir = path.join(TEMPLATE_ROOT, ".spec-runner");
   if (exists(specRunnerTemplateDir)) {
@@ -368,10 +363,18 @@ function main() {
 
   console.log("");
   if (target === "claude" || target === "both") {
+    const claudeMdSrc = path.join(TEMPLATE_ROOT, "CLAUDE.md");
+    if (exists(claudeMdSrc)) {
+      copyFileWithPolicy(claudeMdSrc, path.join(CWD, "CLAUDE.md"), archiveRoot);
+    }
     mirrorTreeTo(DEST_CLAUDE_DIR, CLAUDE_TEMPLATE_DIR, archiveRoot);
   }
   if (target === "copilot" || target === "both") {
     ensureDir(DEST_GITHUB_DIR);
+    const copilotInstructionsSrc = path.join(TEMPLATE_ROOT, "copilot-instructions.md");
+    if (exists(copilotInstructionsSrc)) {
+      copyFileWithPolicy(copilotInstructionsSrc, path.join(CWD, ".github", "copilot-instructions.md"), archiveRoot);
+    }
     if (dirHasFiles(COPILOT_TEMPLATE_DIR)) {
       mirrorTreeTo(DEST_GITHUB_DIR, COPILOT_TEMPLATE_DIR, archiveRoot);
       const copilotSkillsRoot = path.join(COPILOT_TEMPLATE_DIR, "skills");

package/package.json

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

package/spec-runner/templates/.claude/rules/code-style.md

@@ -7,6 +7,10 @@ paths: ["src/**", "tests/**"]
 
 > このファイルはテンプレートです。`architecture-skill-development` で言語・フレームワーク・プロジェクト構造に合わせて書き換えてください。
 
+## スキルファースト原則
+
+コードの修正・実装を始める前に、必ず CLAUDE.md の「開発ワークフロー」を確認し、対応するスキルを特定してから着手する。スキルなしで直接コードや設計書を変更してはならない。
+
 ## 命名規則
 
 > 以下の表をプロジェクトの言語・規約に合わせて書き換える。

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

@@ -51,6 +51,19 @@ seed が存在しない場合は「新規に作る」で進める。
 
 `has_frontend: true` の場合は、`frontend-seed` と バックエンド seed の両方を並走させる旨を専用スキルに明記する。
 
+### テンプレートの移行
+
+seed からスキルを作成した場合（リネーム・リネーム＋構成変更）、seed の `templates/` を新しいスキルの `templates/` にそのままコピーする。
+
+```
+# 例: ddd-seed → my-feature の場合
+cp -r .claude/skills/ddd-seed/templates/ .claude/skills/my-feature/templates/
+```
+
+コピー後、このプロジェクトで不要なテンプレートファイルを削除し、必要なテンプレートファイルを追加してユーザーに承認を得る。プレースホルダー（`{カテゴリ名}` 等）はそのまま残す。
+
+`integrations` に従い `.claude/` / `.github/` 両系で同様に実施する。seed 本体は Phase 6 でアーカイブするまで削除しない。
+
 4. ユーザーに確認・承認を得る
 
 ## Phase 4: 基盤 skill のプロジェクト固有化
@@ -144,10 +157,13 @@ seed が存在しない場合は「新規に作る」で進める。
    - `scripts/scan.js` — **削除しない**。`@analyze-impact` が常時依存しているため
 5. `CLAUDE.md` を更新する
    - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
-   - 作成した project 専用 skill の名前と使いどころを記載する
-   - 例:
+   - **必ず「開発ワークフロー」セクションを設け、各作業でどの skill を使うかを全て明記する。** skill の記載がない CLAUDE.md は未完成とみなす
+   - 以下のフォーマットをベースに、このプロジェクトで使う skill を全て列挙する:
      ```markdown
      ## 開発ワークフロー
+
+     作業を開始するときは必ず対応するスキルを使うこと。スキルなしで直接実装・設計を進めてはならない。
+
      新機能を実装するときは `/feature-development` を使う。
      既存機能を変更するときは `/design-change` を使う。
      テストを書くときは `/test-driven-development` を使う。

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

@@ -124,29 +124,47 @@ docs/バックエンド/03_詳細設計/01_ドメイン/
 
 ### 5-2. ユースケース
 
-シーケンス図は UC ファイルに Mermaid で埋め込む。
+シーケンス図は UC ファイルに Mermaid で埋め込む。カテゴリ（集約・境界コンテキスト）でディレクトリを切る。
 
-テンプレート: `templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md`
+テンプレート: `templates/03_詳細設計/02_ユースケース/{カテゴリ名}/UC-{日本語名}.md`
 
 ```
 docs/バックエンド/03_詳細設計/02_ユースケース/
-  UC-{日本語名}.md
+  {カテゴリ名}/          # 例: 注文/, 在庫/, ユーザー/
+    UC-{日本語名}.md
 ```
 
 ### 5-3. DB・外部サービス（必要時のみ）
 
+テンプレート: `templates/03_詳細設計/03_DB・外部サービス/{プロバイダー名}/{サービス名}.md`
+
 ```
 docs/バックエンド/03_詳細設計/03_DB・外部サービス/
-  スキーマ定義.dbml
+  DB/
+    スキーマ定義.dbml
+    マイグレーション戦略.md
   {プロバイダー名}/      # 例: AWS/, GCP/, Azure/
     {サービス名}.md      # 例: S3.md, DynamoDB.md, Athena.md
 ```
 
+- DB 関連ファイルは `DB/` カテゴリに置く
 - 外部サービスはクラウドプロバイダー（AWS / GCP / Azure など）をカテゴリフォルダとし、中にサービス名の md を置く
 - `外部サービス.md` のような汎用名は使わない
 
 4. ユーザーに確認・承認を得る
 
+## Phase 5.5: マイグレーション戦略
+
+スキーマ定義が確定した後、TDD に入る前に実施する。
+
+1. Migration ツール・命名規則・Up/Down 方針をユーザーと確認する
+2. ゼロダウンタイムの要否を確認する
+3. ロールバック方針・既存データの扱いを決める
+4. `docs/バックエンド/03_詳細設計/03_DB・外部サービス/DB/マイグレーション戦略.md` を作る
+5. ユーザーに確認・承認を得る
+
+テンプレート: `templates/03_詳細設計/03_DB・外部サービス/DB/マイグレーション戦略.md`
+
 ## Phase 6: TDD → 実装
 
 `test-driven-development` スキルへ移行する。

package/spec-runner/templates/.claude/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/DB//343/203/236/343/202/244/343/202/260/343/203/254/343/203/274/343/202/267/343/203/247/343/203/263/346/210/246/347/225/245.md

@@ -0,0 +1,40 @@
+---
+spec_runner:
+  node_id: detail.db.マイグレーション戦略
+  kind: migration_strategy
+  depends_on:
+    - detail.db.スキーマ定義
+---
+
+# マイグレーション戦略
+
+## ツール
+
+- **Migration ツール**: {Flyway / Alembic / Prisma Migrate / その他}
+- **ファイル命名規則**: {例: V{バージョン}__{説明}.sql}
+
+## Up / Down 方針
+
+- **Up**: {適用時の方針}
+- **Down**: {ロールバック時の方針 / Down 不要の場合はその理由}
+
+## 既存データの扱い
+
+| ケース | 対応方針 |
+|--------|---------|
+| {既存レコードの変換} | {方針} |
+| {seed データ} | {方針} |
+| {データ移行スクリプト} | {方針} |
+
+## ゼロダウンタイム戦略
+
+- **要否**: {必要 / 不要}
+- **方針**: {例: backward compatible な変更を先に適用 → デプロイ → 旧カラム削除}
+
+## ロールバック方針
+
+- {ロールバック手順・条件}
+
+## 適用順序・依存関係
+
+- {Migration ファイル間の依存がある場合に記載}

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

@@ -130,6 +130,19 @@ docs/バックエンド/04_調査資料/
 
 ヘッダーの `depends_on` / `maps_to` を更新する。ユーザーに最終確認を得る。
 
+## Phase 6.5: マイグレーション戦略（DB 変更がある場合のみ）
+
+Phase 6 でスキーマ定義の変更があった場合に実施する。DB 変更がなければスキップして Phase 7 へ進む。
+
+1. 既存の `DB/マイグレーション戦略.md` を確認し、今回の変更で影響する項目を洗い出す
+2. 変更内容に応じて以下を更新する
+   - Up / Down 方針の変更有無
+   - ゼロダウンタイムの要否（既存データへの影響があるか）
+   - ロールバック方針の変更有無
+   - 既存データの変換が必要かどうか
+3. `DB/マイグレーション戦略.md` を更新する
+4. ユーザーに確認・承認を得る
+
 ## Phase 7: TDD → 実装 → 検証
 
 設計書修正が承認されたら `test-driven-development` スキルへ移行する。

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

@@ -130,11 +130,13 @@ docs/フロントエンド/03_詳細設計/01_画面/
 
 概要設計のコンポーネント一覧をもとに、共通コンポーネントごとに 1 ファイル作成する。
 
+ファイル名は日本語にする（例: `検索バー.md`, `モーダル.md`, `ヘッダー.md`）。
+
 テンプレート: `templates/03_詳細設計/02_コンポーネント/{コンポーネント名}.md`
 
 ```
 docs/フロントエンド/03_詳細設計/02_コンポーネント/
-  {コンポーネント名}.md
+  {日本語コンポーネント名}.md
 ```
 
 ユーザーに確認・承認を得る。

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

@@ -5,8 +5,10 @@ spec_runner:
   depends_on:
     - frontend.overview.画面一覧
     - frontend.overview.画面遷移図
+    - frontend.detail.コンポーネント.{コンポーネント名}  # 使用するコンポーネントの数だけ列挙
   maps_to:
     - src/app/{path}/page.tsx
+    - src/components/{コンポーネント名}/  # 使用するコンポーネントの数だけ列挙
 ---
 
 # {画面名}

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

@@ -104,27 +104,47 @@ UC → DB・外部サービス の順に設計する。
 
 ### 5-1. ユースケース
 
-テンプレート: `templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md`
+カテゴリ（機能ドメイン）でディレクトリを切る。
+
+テンプレート: `templates/03_詳細設計/01_ユースケース/{カテゴリ名}/UC-{日本語名}.md`
 
 ```
 docs/バックエンド/03_詳細設計/01_ユースケース/
-  UC-{日本語名}.md
+  {カテゴリ名}/          # 例: 注文/, 在庫/, ユーザー/
+    UC-{日本語名}.md
 ```
 
 ### 5-2. DB・外部サービス（必要時のみ）
 
+テンプレート: `templates/03_詳細設計/02_DB・外部サービス/{プロバイダー名}/{サービス名}.md`
+
 ```
 docs/バックエンド/03_詳細設計/02_DB・外部サービス/
-  スキーマ定義.dbml
+  DB/
+    スキーマ定義.dbml
+    マイグレーション戦略.md
   {プロバイダー名}/      # 例: AWS/, GCP/, Azure/
     {サービス名}.md      # 例: S3.md, DynamoDB.md, Athena.md
 ```
 
+- DB 関連ファイルは `DB/` カテゴリに置く
 - 外部サービスはクラウドプロバイダー（AWS / GCP / Azure など）をカテゴリフォルダとし、中にサービス名の md を置く
 - `外部サービス.md` のような汎用名は使わない
 
 3. ユーザーに確認・承認を得る
 
+## Phase 5.5: マイグレーション戦略
+
+スキーマ定義が確定した後、TDD に入る前に実施する。
+
+1. Migration ツール・命名規則・Up/Down 方針をユーザーと確認する
+2. ゼロダウンタイムの要否を確認する
+3. ロールバック方針・既存データの扱いを決める
+4. `docs/バックエンド/03_詳細設計/02_DB・外部サービス/DB/マイグレーション戦略.md` を作る
+5. ユーザーに確認・承認を得る
+
+テンプレート: `templates/03_詳細設計/02_DB・外部サービス/DB/マイグレーション戦略.md`
+
 ## Phase 6: TDD → 実装
 
 `test-driven-development` スキルへ移行する。

package/spec-runner/templates/.claude/skills/simple-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/02_DB/343/203/273/345/244/226/351/203/250/343/202/265/343/203/274/343/203/223/343/202/271/DB//343/203/236/343/202/244/343/202/260/343/203/254/343/203/274/343/202/267/343/203/247/343/203/263/346/210/246/347/225/245.md

@@ -0,0 +1,40 @@
+---
+spec_runner:
+  node_id: detail.db.マイグレーション戦略
+  kind: migration_strategy
+  depends_on:
+    - detail.db.スキーマ定義
+---
+
+# マイグレーション戦略
+
+## ツール
+
+- **Migration ツール**: {Flyway / Alembic / Prisma Migrate / その他}
+- **ファイル命名規則**: {例: V{バージョン}__{説明}.sql}
+
+## Up / Down 方針
+
+- **Up**: {適用時の方針}
+- **Down**: {ロールバック時の方針 / Down 不要の場合はその理由}
+
+## 既存データの扱い
+
+| ケース | 対応方針 |
+|--------|---------|
+| {既存レコードの変換} | {方針} |
+| {seed データ} | {方針} |
+| {データ移行スクリプト} | {方針} |
+
+## ゼロダウンタイム戦略
+
+- **要否**: {必要 / 不要}
+- **方針**: {例: backward compatible な変更を先に適用 → デプロイ → 旧カラム削除}
+
+## ロールバック方針
+
+- {ロールバック手順・条件}
+
+## 適用順序・依存関係
+
+- {Migration ファイル間の依存がある場合に記載}

package/spec-runner/templates/.github/instructions/code-style.instructions.md

@@ -7,6 +7,10 @@ paths: ["src/**", "tests/**"]
 
 > このファイルはテンプレートです。`architecture-skill-development` で言語・フレームワーク・プロジェクト構造に合わせて書き換えてください。
 
+## スキルファースト原則
+
+コードの修正・実装を始める前に、必ず CLAUDE.md の「開発ワークフロー」を確認し、対応するスキルを特定してから着手する。スキルなしで直接コードや設計書を変更してはならない。
+
 ## 命名規則
 
 > 以下の表をプロジェクトの言語・規約に合わせて書き換える。

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

@@ -51,6 +51,19 @@ seed が存在しない場合は「新規に作る」で進める。
 
 `has_frontend: true` の場合は、`frontend-seed` と バックエンド seed の両方を並走させる旨を専用スキルに明記する。
 
+### テンプレートの移行
+
+seed からスキルを作成した場合（リネーム・リネーム＋構成変更）、seed の `templates/` を新しいスキルの `templates/` にそのままコピーする。
+
+```
+# 例: ddd-seed → my-feature の場合
+cp -r .github/skills/ddd-seed/templates/ .github/skills/my-feature/templates/
+```
+
+コピー後、このプロジェクトで不要なテンプレートファイルを削除し、必要なテンプレートファイルを追加してユーザーに承認を得る。プレースホルダー（`{カテゴリ名}` 等）はそのまま残す。
+
+`integrations` に従い `.claude/` / `.github/` 両系で同様に実施する。seed 本体は Phase 6 でアーカイブするまで削除しない。
+
 4. ユーザーに確認・承認を得る
 
 ## Phase 4: 基盤 skill のプロジェクト固有化
@@ -144,10 +157,13 @@ seed が存在しない場合は「新規に作る」で進める。
    - `scripts/scan.js` — **削除しない**。`@analyze-impact` が常時依存しているため
 5. `CLAUDE.md` を更新する
    - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
-   - 作成した project 専用 skill の名前と使いどころを記載する
-   - 例:
+   - **必ず「開発ワークフロー」セクションを設け、各作業でどの skill を使うかを全て明記する。** skill の記載がない CLAUDE.md は未完成とみなす
+   - 以下のフォーマットをベースに、このプロジェクトで使う skill を全て列挙する:
      ```markdown
      ## 開発ワークフロー
+
+     作業を開始するときは必ず対応するスキルを使うこと。スキルなしで直接実装・設計を進めてはならない。
+
      新機能を実装するときは `/feature-development` を使う。
      既存機能を変更するときは `/design-change` を使う。
      テストを書くときは `/test-driven-development` を使う。

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

@@ -124,29 +124,47 @@ docs/バックエンド/03_詳細設計/01_ドメイン/
 
 ### 5-2. ユースケース
 
-シーケンス図は UC ファイルに Mermaid で埋め込む。
+シーケンス図は UC ファイルに Mermaid で埋め込む。カテゴリ（集約・境界コンテキスト）でディレクトリを切る。
 
-テンプレート: `templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md`
+テンプレート: `templates/03_詳細設計/02_ユースケース/{カテゴリ名}/UC-{日本語名}.md`
 
 ```
 docs/バックエンド/03_詳細設計/02_ユースケース/
-  UC-{日本語名}.md
+  {カテゴリ名}/          # 例: 注文/, 在庫/, ユーザー/
+    UC-{日本語名}.md
 ```
 
 ### 5-3. DB・外部サービス（必要時のみ）
 
+テンプレート: `templates/03_詳細設計/03_DB・外部サービス/{プロバイダー名}/{サービス名}.md`
+
 ```
 docs/バックエンド/03_詳細設計/03_DB・外部サービス/
-  スキーマ定義.dbml
+  DB/
+    スキーマ定義.dbml
+    マイグレーション戦略.md
   {プロバイダー名}/      # 例: AWS/, GCP/, Azure/
     {サービス名}.md      # 例: S3.md, DynamoDB.md, Athena.md
 ```
 
+- DB 関連ファイルは `DB/` カテゴリに置く
 - 外部サービスはクラウドプロバイダー（AWS / GCP / Azure など）をカテゴリフォルダとし、中にサービス名の md を置く
 - `外部サービス.md` のような汎用名は使わない
 
 4. ユーザーに確認・承認を得る
 
+## Phase 5.5: マイグレーション戦略
+
+スキーマ定義が確定した後、TDD に入る前に実施する。
+
+1. Migration ツール・命名規則・Up/Down 方針をユーザーと確認する
+2. ゼロダウンタイムの要否を確認する
+3. ロールバック方針・既存データの扱いを決める
+4. `docs/バックエンド/03_詳細設計/03_DB・外部サービス/DB/マイグレーション戦略.md` を作る
+5. ユーザーに確認・承認を得る
+
+テンプレート: `templates/03_詳細設計/03_DB・外部サービス/DB/マイグレーション戦略.md`
+
 ## 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/DB//343/203/236/343/202/244/343/202/260/343/203/254/343/203/274/343/202/267/343/203/247/343/203/263/346/210/246/347/225/245.md

@@ -0,0 +1,40 @@
+---
+spec_runner:
+  node_id: detail.db.マイグレーション戦略
+  kind: migration_strategy
+  depends_on:
+    - detail.db.スキーマ定義
+---
+
+# マイグレーション戦略
+
+## ツール
+
+- **Migration ツール**: {Flyway / Alembic / Prisma Migrate / その他}
+- **ファイル命名規則**: {例: V{バージョン}__{説明}.sql}
+
+## Up / Down 方針
+
+- **Up**: {適用時の方針}
+- **Down**: {ロールバック時の方針 / Down 不要の場合はその理由}
+
+## 既存データの扱い
+
+| ケース | 対応方針 |
+|--------|---------|
+| {既存レコードの変換} | {方針} |
+| {seed データ} | {方針} |
+| {データ移行スクリプト} | {方針} |
+
+## ゼロダウンタイム戦略
+
+- **要否**: {必要 / 不要}
+- **方針**: {例: backward compatible な変更を先に適用 → デプロイ → 旧カラム削除}
+
+## ロールバック方針
+
+- {ロールバック手順・条件}
+
+## 適用順序・依存関係
+
+- {Migration ファイル間の依存がある場合に記載}

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

@@ -130,6 +130,19 @@ docs/バックエンド/04_調査資料/
 
 ヘッダーの `depends_on` / `maps_to` を更新する。ユーザーに最終確認を得る。
 
+## Phase 6.5: マイグレーション戦略（DB 変更がある場合のみ）
+
+Phase 6 でスキーマ定義の変更があった場合に実施する。DB 変更がなければスキップして Phase 7 へ進む。
+
+1. 既存の `DB/マイグレーション戦略.md` を確認し、今回の変更で影響する項目を洗い出す
+2. 変更内容に応じて以下を更新する
+   - Up / Down 方針の変更有無
+   - ゼロダウンタイムの要否（既存データへの影響があるか）
+   - ロールバック方針の変更有無
+   - 既存データの変換が必要かどうか
+3. `DB/マイグレーション戦略.md` を更新する
+4. ユーザーに確認・承認を得る
+
 ## Phase 7: TDD → 実装 → 検証
 
 設計書修正が承認されたら `test-driven-development` スキルへ移行する。

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

@@ -130,11 +130,13 @@ docs/フロントエンド/03_詳細設計/01_画面/
 
 概要設計のコンポーネント一覧をもとに、共通コンポーネントごとに 1 ファイル作成する。
 
+ファイル名は日本語にする（例: `検索バー.md`, `モーダル.md`, `ヘッダー.md`）。
+
 テンプレート: `templates/03_詳細設計/02_コンポーネント/{コンポーネント名}.md`
 
 ```
 docs/フロントエンド/03_詳細設計/02_コンポーネント/
-  {コンポーネント名}.md
+  {日本語コンポーネント名}.md
 ```
 
 ユーザーに確認・承認を得る。

package/spec-runner/templates/.github/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

@@ -5,8 +5,10 @@ spec_runner:
   depends_on:
     - frontend.overview.画面一覧
     - frontend.overview.画面遷移図
+    - frontend.detail.コンポーネント.{コンポーネント名}  # 使用するコンポーネントの数だけ列挙
   maps_to:
     - src/app/{path}/page.tsx
+    - src/components/{コンポーネント名}/  # 使用するコンポーネントの数だけ列挙
 ---
 
 # {画面名}

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

@@ -104,27 +104,47 @@ UC → DB・外部サービス の順に設計する。
 
 ### 5-1. ユースケース
 
-テンプレート: `templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md`
+カテゴリ（機能ドメイン）でディレクトリを切る。
+
+テンプレート: `templates/03_詳細設計/01_ユースケース/{カテゴリ名}/UC-{日本語名}.md`
 
 ```
 docs/バックエンド/03_詳細設計/01_ユースケース/
-  UC-{日本語名}.md
+  {カテゴリ名}/          # 例: 注文/, 在庫/, ユーザー/
+    UC-{日本語名}.md
 ```
 
 ### 5-2. DB・外部サービス（必要時のみ）
 
+テンプレート: `templates/03_詳細設計/02_DB・外部サービス/{プロバイダー名}/{サービス名}.md`
+
 ```
 docs/バックエンド/03_詳細設計/02_DB・外部サービス/
-  スキーマ定義.dbml
+  DB/
+    スキーマ定義.dbml
+    マイグレーション戦略.md
   {プロバイダー名}/      # 例: AWS/, GCP/, Azure/
     {サービス名}.md      # 例: S3.md, DynamoDB.md, Athena.md
 ```
 
+- DB 関連ファイルは `DB/` カテゴリに置く
 - 外部サービスはクラウドプロバイダー（AWS / GCP / Azure など）をカテゴリフォルダとし、中にサービス名の md を置く
 - `外部サービス.md` のような汎用名は使わない
 
 3. ユーザーに確認・承認を得る
 
+## Phase 5.5: マイグレーション戦略
+
+スキーマ定義が確定した後、TDD に入る前に実施する。
+
+1. Migration ツール・命名規則・Up/Down 方針をユーザーと確認する
+2. ゼロダウンタイムの要否を確認する
+3. ロールバック方針・既存データの扱いを決める
+4. `docs/バックエンド/03_詳細設計/02_DB・外部サービス/DB/マイグレーション戦略.md` を作る
+5. ユーザーに確認・承認を得る
+
+テンプレート: `templates/03_詳細設計/02_DB・外部サービス/DB/マイグレーション戦略.md`
+
 ## Phase 6: TDD → 実装
 
 `test-driven-development` スキルへ移行する。

package/spec-runner/templates/.github/skills/simple-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/02_DB/343/203/273/345/244/226/351/203/250/343/202/265/343/203/274/343/203/223/343/202/271/DB//343/203/236/343/202/244/343/202/260/343/203/254/343/203/274/343/202/267/343/203/247/343/203/263/346/210/246/347/225/245.md

@@ -0,0 +1,40 @@
+---
+spec_runner:
+  node_id: detail.db.マイグレーション戦略
+  kind: migration_strategy
+  depends_on:
+    - detail.db.スキーマ定義
+---
+
+# マイグレーション戦略
+
+## ツール
+
+- **Migration ツール**: {Flyway / Alembic / Prisma Migrate / その他}
+- **ファイル命名規則**: {例: V{バージョン}__{説明}.sql}
+
+## Up / Down 方針
+
+- **Up**: {適用時の方針}
+- **Down**: {ロールバック時の方針 / Down 不要の場合はその理由}
+
+## 既存データの扱い
+
+| ケース | 対応方針 |
+|--------|---------|
+| {既存レコードの変換} | {方針} |
+| {seed データ} | {方針} |
+| {データ移行スクリプト} | {方針} |
+
+## ゼロダウンタイム戦略
+
+- **要否**: {必要 / 不要}
+- **方針**: {例: backward compatible な変更を先に適用 → デプロイ → 旧カラム削除}
+
+## ロールバック方針
+
+- {ロールバック手順・条件}
+
+## 適用順序・依存関係
+
+- {Migration ファイル間の依存がある場合に記載}

package/spec-runner/templates/copilot-instructions.md

@@ -0,0 +1,42 @@
+
+
+## spec-runner セットアップ
+
+このプロジェクトは spec-runner を使用しています。
+
+### 開発ワークフロー
+
+設計書は `docs/` に格納されています。実装前に必ず設計書を参照してください。
+
+| 状態 | 判定方法 | 起動するスキル |
+|------|---------|--------------|
+| 新規プロジェクト | `docs/` が存在しないか空 | `architecture-definition` |
+| 既存プロジェクト | `docs/` にファイルがある | `existing-project-to-docs` |
+
+どちらの場合も、そのスキルが完了したら続けて `architecture-skill-development` を起動する。
+
+### 判定の注意
+
+- `docs/` の中身を確認してから判断する（ディレクトリ存在だけで判断しない）
+- ユーザーが「〇〇を作りたい」「〇〇の開発を始めたい」のように要件・作業開始を示す発言をしたら起動する
+- 雑談や質問など、明らかに要件でない場合は起動しない
+
+詳細な指示は `.github/instructions/` の各ファイルを参照してください。
+
+---
+
+## エージェント継続ループ（必須）
+
+**すべての応答の末尾に、必ず `docker ps` を実行すること。**
+
+### ルール
+
+1. **エージェント自身が実行する** — ユーザーに「実行してください」と依頼してはならない。
+2. **出力を確認するまでチャットを終了しない** — `docker ps` の結果が表示されるまで待機する。
+3. **コマンド欄に新しい指示があれば最優先で対応する**
+   - `docker ps` の実行許可ダイアログのコマンド欄にユーザーが追記した内容を、新しい指示として受け取る。
+   - その指示を確認・実装・修正してから、再度 `docker ps` を実行する。
+   - これを繰り返すことで、ユーザーは許可ダイアログ経由で無限に指示を追加できる。
+4. **サブエージェントは `docker ps` を実行しない**
+   - サブエージェントを呼び出す際は、`docker ps` の実行が不要であることを明示的に伝える。
+   - すべてのサブエージェントの処理が完了した後、**親エージェントが** `docker ps` を実行する。