spec-runner 1.1.13 → 1.1.17

package/spec-runner/templates/.github/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/.github/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}
+
+## 判断条件
+
+| 判断ポイント | 条件 | アクション |
+|------------|------|----------|
+| {判断ポイント} | {条件} | {アクション} |
+
+## エラーポリシー
+
+| エラーケース | 発生条件 | 対応 |
+|------------|---------|------|
+| {エラーケース} | {発生条件} | {対応} |
+
+## テスト観点
+
+- {正常系の観点}
+- {異常系の観点}
+- {境界条件の観点}

package/spec-runner/templates/.github/skills/test-driven-development/SKILL.md

@@ -26,13 +26,89 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 テストより先にコードを書いたなら削除して最初からやり直す。
 「参考として残す」も「テストを書きながら適応させる」も不可。
 
+## テスト戦略：テストピラミッド
+
+実装前にどのテスト種別を書くかを決める。迷ったら**単体テストから始める**。
+
+```
+        /\
+       /E2E\        少数・遅い・ユーザーシナリオ全体
+      /------\
+     /  結合   \    中程度・モジュール間連携・外部境界
+    /----------\
+   /    単体    \   多数・高速・関数・クラス単位
+  /______________\
+```
+
+### 単体テスト（Unit）
+
+**対象:** 関数・クラス・モジュールの振る舞い（外部依存なし）
+
+**書くとき:**
+- ビジネスロジック・計算・変換処理
+- エラー処理・バリデーション
+- 状態変化（純粋関数・値オブジェクト）
+
+**外部依存の扱い:** 実際に遅い・副作用がある依存のみモック。それ以外は実物を使う。
+
+**速度目安:** ミリ秒単位。CI で毎回全件実行できる。
+
+### 結合テスト（Integration）
+
+**対象:** 複数モジュールの連携、DB・キャッシュ・外部APIとの境界
+
+**書くとき:**
+- DB へのクエリ・永続化
+- 外部サービス呼び出し（HTTP, メッセージキュー等）
+- 複数の集約をまたぐユースケース
+
+**外部依存の扱い:** 原則として実物を使う（テスト用 DB、テスト環境の外部サービス）。
+動かせない外部サービスのみスタブ／フェイクで代替する。
+
+**速度目安:** 秒単位。PR ごとに実行できる。
+
+### E2E テスト
+
+**対象:** ユーザーが実際に操作するシナリオ全体（UI から DB まで）
+
+**書くとき:**
+- 最重要のユーザーシナリオ（ハッピーパス）
+- リグレッションが致命的な機能（決済・認証等）
+
+**数を絞る:** E2E は維持コストが高い。書く前に「単体＋結合で代替できないか？」を問う。
+
+**速度目安:** 分単位。夜間や本番リリース前など頻度を落として実行。
+
+## テスト種別の選び方
+
+| 実装するもの | まず書くテスト | 追加で書くテスト |
+|---|---|---|
+| ロジック・計算 | 単体 | — |
+| DB 操作 | 結合 | — |
+| API エンドポイント | 結合 | 主要シナリオは E2E |
+| 複数サービスをまたぐフロー | 結合 | — |
+| ユーザー向け主要機能 | 単体＋結合 | E2E（絞る） |
+| バグ修正 | 最小レベルで再現テスト | — |
+
+**バグ修正の場合:** バグを再現できる最も低いレベルのテストを書く。
+単体で再現できるなら単体、DBが絡むなら結合。E2E で初めて再現するバグは、単体・結合に落とし込めないか検討する。
+
 ## テスト実行コマンド
 
 > このスキルはテンプレートとして配布されます。
 > `architecture-skill-development` を使ってプロジェクト固有のコマンドに書き換えてください。
 
 ```bash
-# 全テスト（プロジェクトのテストコマンドに置き換える）
+# 単体テスト（高速・毎回実行）
+<your-unit-test-command>
+
+# 結合テスト
+<your-integration-test-command>
+
+# E2E テスト
+<your-e2e-test-command>
+
+# 全テスト
 <your-test-command>
 
 # 特定ファイル
@@ -46,7 +122,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 ### RED - 失敗するテストを書く
 
-起きてほしいことを示す、最小のテストを1つ書く。
+テスト種別を決めたうえで、起きてほしいことを示す最小のテストを1つ書く。
 
 ```
 // 例（言語・フレームワークはプロジェクトに合わせる）
@@ -93,7 +169,7 @@ test("ある入力に対して期待する出力を返す", () => {
 `@test-runner` エージェントに委任して実行する。
 
 - テストが通る
-- **他のテストも全て通る**
+- **同種のテストが全て通る**（単体なら単体全件、結合なら結合全件）
 - 出力がクリーン（エラー、警告なし）
 - **カバレッジの未カバー行を確認** — 新規コードが未カバーなら追加テストを書く
 
@@ -122,18 +198,34 @@ GREEN / REFACTORフェーズで書く実装コードにもビジネスロジッ
 
 ## テスト構成
 
-テストファイルは `src/` と同じディレクトリ構造を `tests/` に鏡写しにする。
+```
+tests/
+  unit/        # 単体テスト（src/ と同じ構造を鏡写し）
+  integration/ # 結合テスト
+  e2e/         # E2E テスト
+```
+
+テストファイルは `src/` と同じディレクトリ構造を各テスト種別のディレクトリ内に鏡写しにする。
 
 ## fixture / テストデータの活用
 
 - テストごとに独立した状態を持つ
 - テストデータ生成にはヘルパ関数を定義して一貫性を保つ
 - 外部サービス（API・メール・ストレージ等）は必要な場合のみモックする
+- 結合テスト用のシードデータは `tests/integration/fixtures/` に置く
 
 ## モックのルール
 
 モックは分離の手段であり、テスト対象ではない。
 
+**テスト種別ごとのモック方針:**
+
+| テスト種別 | 原則 |
+|---|---|
+| 単体 | 外部 I/O（DB・HTTP・ファイル）のみモック可。ビジネスロジックはモックしない |
+| 結合 | 実物の外部依存を使う。動かせない外部サービスのみスタブ可 |
+| E2E | モックしない。全て実物 |
+
 **モック前の自問:**
 1. 「実メソッドにはどんな副作用があるか？」
 2. 「このテストはその副作用に依存しているか？」
@@ -168,6 +260,8 @@ GREEN / REFACTORフェーズで書く実装コードにもビジネスロジッ
 | テスト前にコードを書いた | コードを削除し、TDDで最初からやり直す |
 | テストが最初から通る | 既存挙動をテストしている。テストを修正する |
 | なぜ失敗したか説明できない | テストが正しいか再検討する |
+| 全部 E2E で書いた | ピラミッドが逆転している。単体・結合に落とし込む |
+| 全部モックだらけ | 結合が強すぎる。または結合テストを書くべき |
 
 **どれか1つでも当てはまるなら: コードを削除し、TDDで最初からやり直す。**
 
@@ -180,14 +274,15 @@ GREEN / REFACTORフェーズで書く実装コードにもビジネスロジッ
 
 完了宣言の前に:
 
+- [ ] 実装前にテスト種別（単体・結合・E2E）を決めた
 - [ ] 新規関数／メソッドにテストがある
 - [ ] 各テストは実装前に失敗するのを見た
 - [ ] 期待通りの理由で失敗した（機能不足であり誤字ではない）
 - [ ] 通す最小コードを書いた
-- [ ] 全テストが通る
+- [ ] 同種のテストが全件通る
 - [ ] 出力がクリーン（エラー、警告なし）
 - [ ] カバレッジを確認し、新規コードの未カバー行がない
-- [ ] 実コード中心（不可避な場合のみモック）
+- [ ] モック方針がテスト種別に合っている
 - [ ] エッジケースとエラーをカバーした
 
 すべてにチェックできないならTDDを飛ばしている。やり直すこと。
@@ -197,9 +292,11 @@ GREEN / REFACTORフェーズで書く実装コードにもビジネスロジッ
 | 問題 | 解決 |
 |------|------|
 | どうテストすべきか分からない | 望むAPIを書き、まずアサーションを書く。ユーザーに相談する |
+| どのテスト種別か迷う | 単体から始める。単体で書けないなら結合を検討する |
 | テストが複雑すぎる | 設計が複雑すぎる。インターフェースを簡素化する |
-| 何でもモック必須 | 結合が強すぎる。依存性注入を使う |
+| 何でもモック必須 | 結合が強すぎる。依存性注入を使う。または結合テストで書く |
 | セットアップが巨大 | fixtureやテストユーティリティに抽出する。それでも大きいなら設計を簡素化する |
+| E2E が遅すぎる | 単体・結合に落とし込めるか検討する |
 
 ## 最終ルール
 

package/spec-runner/templates/.spec-runner/scripts/scan.js

@@ -0,0 +1,156 @@
+#!/usr/bin/env node
+'use strict';
+
+/**
+ * spec-runner scan
+ *
+ * docs/**\/*.md の frontmatter（spec_runner: セクション）を静的解析し、
+ * 依存グラフを .spec-runner/scan/graph.json にキャッシュする。
+ *
+ * 出力:
+ *   .spec-runner/scan/graph.json
+ *
+ * 使い方:
+ *   node .spec-runner/scripts/scan.js
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+const ROOT = process.cwd();
+const DOCS_DIR = path.join(ROOT, 'docs');
+const OUTPUT_DIR = path.join(ROOT, '.spec-runner', 'scan');
+const OUTPUT_FILE = path.join(OUTPUT_DIR, 'graph.json');
+
+// ── ファイル収集 ────────────────────────────────────────────────────────────
+
+function findMdFiles(dir) {
+  if (!fs.existsSync(dir)) return [];
+  const results = [];
+  for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
+    const full = path.join(dir, entry.name);
+    if (entry.isDirectory()) results.push(...findMdFiles(full));
+    else if (entry.name.endsWith('.md')) results.push(full);
+  }
+  return results;
+}
+
+// ── frontmatter パーサー ────────────────────────────────────────────────────
+
+function parseSpecRunnerFrontmatter(content) {
+  const fmMatch = content.match(/^---\n([\s\S]*?)\n---/);
+  if (!fmMatch) return null;
+
+  const fm = fmMatch[1];
+  if (!fm.includes('spec_runner:')) return null;
+
+  // spec_runner: セクションを抽出（次のトップレベルキーまで）
+  const srMatch = fm.match(/spec_runner:\n([\s\S]*?)(?=\n\S|$)/);
+  if (!srMatch) return null;
+  const srBlock = srMatch[1];
+
+  const nodeIdMatch = srBlock.match(/^\s+node_id:\s*(.+)$/m);
+  if (!nodeIdMatch) return null;
+
+  const kindMatch = srBlock.match(/^\s+kind:\s*(.+)$/m);
+
+  return {
+    node_id: nodeIdMatch[1].trim(),
+    kind: kindMatch ? kindMatch[1].trim() : null,
+    depends_on: parseYamlList(srBlock, 'depends_on'),
+    maps_to: parseYamlList(srBlock, 'maps_to'),
+  };
+}
+
+function parseYamlList(block, key) {
+  const re = new RegExp(`^([ \\t]+)${key}:\\s*(.*)$`, 'm');
+  const keyMatch = block.match(re);
+  if (!keyMatch) return [];
+
+  const inlineVal = keyMatch[2].trim();
+
+  // インライン配列: [a, b, c]
+  if (inlineVal.startsWith('[')) {
+    return inlineVal.replace(/[\[\]]/g, '').split(',').map(s => s.trim()).filter(Boolean);
+  }
+
+  // マルチライン配列: - item
+  const keyIndex = block.indexOf(keyMatch[0]);
+  const afterKey = block.slice(keyIndex + keyMatch[0].length);
+  const items = [];
+  for (const line of afterKey.split('\n')) {
+    const itemMatch = line.match(/^\s+-\s+(.+)$/);
+    if (itemMatch) {
+      items.push(itemMatch[1].trim());
+    } else if (line.trim() !== '') {
+      break; // 別のキーが始まったら終了
+    }
+  }
+  return items;
+}
+
+// ── メイン ──────────────────────────────────────────────────────────────────
+
+function main() {
+  const files = findMdFiles(DOCS_DIR);
+
+  const graph = {
+    generated_at: new Date().toISOString(),
+    nodes: {},         // node_id → { file, kind, depends_on, maps_to }
+    reverse_index: {}, // node_id → [依存元 node_id のリスト]（影響範囲検索用）
+    missing_maps_to: [], // { source, node_id, missing } 存在しないファイル参照
+  };
+
+  for (const file of files) {
+    let content;
+    try {
+      content = fs.readFileSync(file, 'utf8');
+    } catch {
+      continue;
+    }
+
+    const fm = parseSpecRunnerFrontmatter(content);
+    if (!fm) continue;
+
+    const relPath = path.relative(ROOT, file);
+    const { node_id, kind, depends_on, maps_to } = fm;
+
+    graph.nodes[node_id] = { file: relPath, kind, depends_on, maps_to };
+
+    // リバースインデックスを構築（A が B に depends_on → reverse_index[B].push(A)）
+    for (const dep of depends_on) {
+      if (!graph.reverse_index[dep]) graph.reverse_index[dep] = [];
+      graph.reverse_index[dep].push(node_id);
+    }
+
+    // maps_to の実在チェック
+    for (const mapped of maps_to) {
+      const mappedPath = path.join(ROOT, mapped);
+      // 末尾スラッシュ付きはディレクトリ
+      const exists = mapped.endsWith('/')
+        ? fs.existsSync(mappedPath)
+        : fs.existsSync(mappedPath);
+      if (!exists) {
+        graph.missing_maps_to.push({ source: relPath, node_id, missing: mapped });
+      }
+    }
+  }
+
+  fs.mkdirSync(OUTPUT_DIR, { recursive: true });
+  fs.writeFileSync(OUTPUT_FILE, JSON.stringify(graph, null, 2));
+
+  const nodeCount = Object.keys(graph.nodes).length;
+  const rel = path.relative(ROOT, OUTPUT_FILE);
+  console.log(`spec-runner scan: ${nodeCount} nodes indexed → ${rel}`);
+
+  if (graph.missing_maps_to.length > 0) {
+    console.warn(`\nmaps_to integrity: ${graph.missing_maps_to.length} missing reference(s)`);
+    for (const m of graph.missing_maps_to) {
+      console.warn(`  MISSING  ${m.missing}`);
+      console.warn(`           in ${m.source} (${m.node_id})`);
+    }
+    process.exit(1);
+  }
+}
+
+main();

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

@@ -1,173 +0,0 @@
----
-name: plugin-development
-description: プラグイン型アーキテクチャ向けの reference workflow。docs を正本にし、概要設計から `src/` ミラーの詳細設計、TDD、実装へ進める。
----
-
-# plugin-development
-
-プラグイン型アーキテクチャ向けの新規開発フロー。
-`architecture-definition` や `architecture-skill-development` が未整備な段階でも使える reference implementation として扱う。
-
-## 全体フロー
-
-```
-Phase 1: 要件定義
-Phase 2: 概要設計
-Phase 3: ADR（必要時のみ）
-Phase 4: 詳細設計
-Phase 5: TDD → 実装
-```
-
-## 前提ルール
-
-- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
-- `docs/03_詳細設計/src/**` は原則として `src/` をミラーする
-- `docs/03_詳細設計/infrastructure/**` は例外文書として扱い、必ず `maps_to` で対応先を明示する
-- ユーザー承認なしに次フェーズへ進めない
-
-## Phase 1: 要件定義
-
-### 手順
-
-1. 以下をユーザーにヒアリングする
-   - 解決すべき課題
-   - 提供価値
-   - 対象ユーザー
-   - 非機能要件
-   - スコープ外
-   - 技術・ビジネス制約
-2. テンプレート `templates/01_要件定義/概要テンプレート.md` をコピーして `docs/01_要件定義/要件定義.md` を作る
-3. frontmatter の `node_id` / `kind` / `depends_on` / `maps_to` を埋める
-4. ユーザーに確認・承認を得る
-
-### 出力
-
-```text
-docs/
-  01_要件定義/
-    要件定義.md
-```
-
-## Phase 2: 概要設計
-
-### 2-1. ユースケース一覧
-
-1. Phase 1 の要件定義からユースケースを洗い出す
-2. Query / Command を意識して一覧化する
-3. テンプレート `templates/02_概要設計/ユースケース一覧テンプレート.md` をコピーして作る
-4. 必要なら `docs/02_概要設計/ユースケース/` 配下に個別 UC も作る
-5. ユーザーに確認・承認を得る
-
-### 2-2. システム全体俯瞰
-
-1. ユースケース一覧から責務境界、主要コンポーネント、外部 IF を整理する
-2. テンプレート `templates/02_概要設計/システム全体俯瞰テンプレート.md` をコピーして作る
-3. 必要なら `ドメイン責務マップ.md` / `外部IF一覧.md` / `非機能・運用方針.md` を追加する
-4. ユーザーに確認・承認を得る
-
-### 出力
-
-```text
-docs/
-  02_概要設計/
-    ユースケース一覧.md
-    システム全体俯瞰.md
-    ユースケース/
-      UC-*.md
-    90_ADR/
-```
-
-## Phase 3: ADR（必要時のみ）
-
-1. 実装方針に意思決定が必要な場合だけ ADR を作る
-2. **必ず 3 案を比較する**
-3. テンプレート `templates/02_概要設計/90_ADR/ADRテンプレート.md` をコピーして生成する
-4. 配置先は `docs/02_概要設計/90_ADR/mmdd-{日本語タイトル}.md` を原則とする
-5. 採用案を概要設計へ反映してから次へ進む
-
-## Phase 4: 詳細設計
-
-**各ドキュメントは `src/` と決定的に対応づける。**
-
-### 4-1. エージェント
-
-テンプレート:
-- `templates/03_詳細設計/src/agents/{agent_name}/agent.md`
-- `templates/03_詳細設計/src/agents/{agent_name}/domain.md`
-- `templates/03_詳細設計/src/agents/{agent_name}/prompts.md`
-- `templates/03_詳細設計/src/agents/{agent_name}/config.md`
-
-出力:
-
-```text
-docs/
-  03_詳細設計/
-    src/
-      agents/
-        {agent_name}/
-          agent.md
-          domain.md
-          prompts.md
-          config.md
-```
-
-### 4-2. プラグイン
-
-テンプレート:
-- `templates/03_詳細設計/src/plugins/skills/{skill_name}/skill.md`
-- `templates/03_詳細設計/src/plugins/tools/{tool_name}/tool.md`
-
-出力:
-
-```text
-docs/
-  03_詳細設計/
-    src/
-      plugins/
-        skills/
-          {skill_name}/
-            skill.md
-        tools/
-          {tool_name}/
-            tool.md
-```
-
-### 4-3. インフラ補助設計
-
-`src` ミラーだけでは表現しきれない DB / IaC / 運用構成だけ、例外として補助設計を置く。
-
-テンプレート:
-- `templates/03_詳細設計/infrastructure/database.md`
-- `templates/03_詳細設計/infrastructure/schema.dbml`
-- `templates/03_詳細設計/infrastructure/aws.md`
-- `templates/03_詳細設計/infrastructure/sequence/シーケンス図テンプレート.md`
-
-出力:
-
-```text
-docs/
-  03_詳細設計/
-    infrastructure/
-      database.md
-      schema.dbml
-      aws.md
-      sequence/
-```
-
-ユーザーに確認・承認を得る
-
-## Phase 5: TDD → 実装
-
-詳細設計が承認されたら `test-driven-development` スキルへ移行する。
-
-### 実装完了後のレビュー
-
-- `@design-reviewer` — frontmatter と `maps_to` を起点に設計書⇔実装の整合性チェック
-- `@code-reviewer` — コーディング規約への適合チェック
-
-## 原則
-
-- **ユースケースは途中で止めずに洗い出す**
-- **詳細設計は `src/` ミラーを優先する**
-- **補助設計を置く場合も `maps_to` で対応先を残す**
-- **`plugin-development` を最終形とみなさず、project 専用 skill の種として扱う**