spec-runner 1.7.0 → 1.8.0

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

@@ -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/.github/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/.github/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/.github/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/design-change/references//345/275/261/351/237/277/347/257/204/345/233/262/343/203/201/343/202/247/343/203/203/343/202/257/343/203/252/343/202/271/343/203/210.md

@@ -1,59 +0,0 @@
-# 影響範囲チェックリスト
-
-> このファイルはテンプレートです。`architecture-skill-development` でプロジェクトの変更カテゴリと詳細設計パスに合わせて書き換えてください。
-
-design-change の Phase 3（影響ドキュメントの確定）で参照する。
-変更の種類に応じて、修正が必要なドキュメントを網羅的に特定する。
-
-## 変更種別ごとのチェック項目
-
-### ユースケース（UC）の追加・変更・削除
-
-| ドキュメント | パス | チェック |
-|------------|------|------|
-| ユースケース一覧 | `docs/02_概要設計/ユースケース一覧.md` | UC の追加・修正・削除を反映 |
-| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | 責務分割・外部 IF への影響 |
-| UC 詳細設計 | `docs/03_詳細設計/<UC詳細設計パス>/UC-{日本語名}.md` | シーケンス・入出力・判断条件の変更 |
-| DB・外部サービス | `docs/03_詳細設計/<DB・外部サービスパス>/` | UC が利用するスキーマ・外部 IF への影響 |
-
-### ドメイン設計の変更（style: ddd のみ）
-
-| ドキュメント | パス | チェック |
-|------------|------|------|
-| ドメインモデル | `docs/02_概要設計/ドメインモデル.md` | 集約・境界コンテキストへの影響 |
-| ドメイン詳細設計 | `docs/03_詳細設計/<ドメイン詳細設計パス>/{ドメイン名}.md` | エンティティ・値オブジェクト・不変条件の変更 |
-| UC 詳細設計 | `docs/03_詳細設計/<UC詳細設計パス>/UC-{日本語名}.md` | ドメイン変更が UC フローに影響する場合 |
-| DB・外部サービス | `docs/03_詳細設計/<DB・外部サービスパス>/` | スキーマ・保存方針への影響 |
-
-### DB・外部サービスの変更
-
-| ドキュメント | パス | チェック |
-|------------|------|------|
-| DB・外部サービス | `docs/03_詳細設計/<DB・外部サービスパス>/` | テーブル定義・外部 API 仕様の変更 |
-| UC 詳細設計 | `docs/03_詳細設計/<UC詳細設計パス>/UC-{日本語名}.md` | 保存フロー・外部呼び出しへの影響 |
-| ドメイン詳細設計 | `docs/03_詳細設計/<ドメイン詳細設計パス>/{ドメイン名}.md` | ドメインモデルへの影響（style: ddd のみ） |
-
-### アーキテクチャ・設計方針の変更
-
-| ドキュメント | パス | チェック |
-|------------|------|------|
-| ADR | `docs/02_概要設計/90_ADR/全体/` | 横断的な決定を記録 |
-| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | 技術方針・全体構成の変更 |
-| 要件定義 | `docs/01_要件定義/要件定義.md` | 要件レベルの変更がある場合 |
-| 詳細設計一式 | `docs/03_詳細設計/**` | 方針変更の具体反映 |
-
-### 要件の変更
-
-| ドキュメント | パス | チェック |
-|------------|------|------|
-| 要件定義 | `docs/01_要件定義/要件定義.md` | 要件・スコープの変更 |
-| ユビキタス言語辞書 | `docs/01_要件定義/ユビキタス言語辞書.md` | 用語の追加・変更 |
-| ユースケース一覧 | `docs/02_概要設計/ユースケース一覧.md` | 要件変更に伴う UC の追加・削除 |
-| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | スコープ変更による構成への影響 |
-
-## 二次影響の確認観点
-
-- **ユースケース一覧 ↔ 詳細設計**: 一覧に記載の UC が詳細設計でカバーされているか
-- **システム全体俯瞰 ↔ 詳細設計**: 責務分割が詳細設計に落ちているか
-- **ドメイン設計 ↔ DB スキーマ**: ドメインのフィールドが DB カラムと対応しているか（style: ddd のみ）
-- **ヘッダー ↔ 実ファイル**: `depends_on` と `maps_to` が現状に追随しているか

package/spec-runner/templates/.claude/skills/spec-probe/SKILL.md

@@ -1,12 +0,0 @@
----
-name: spec-probe
-description: 設計・要件の前提を一問一答で深掘りする。設計レビュー・要件定義・ADR 前に使う。
----
-
-計画・設計・要件のあらゆる側面について、共通理解に達するまで容赦なくインタビューする。
-決定ツリーの各分岐を辿り、依存関係のある判断を一つずつ解決する。
-各質問に対して、推奨する答えも提示する。
-
-質問は一度に一つだけ行う。
-
-コードベースを読めば答えられる質問は、質問する代わりにコードを読む。

package/spec-runner/templates/.github/skills/design-change/references//345/275/261/351/237/277/347/257/204/345/233/262/343/203/201/343/202/247/343/203/203/343/202/257/343/203/252/343/202/271/343/203/210.md

@@ -1,59 +0,0 @@
-# 影響範囲チェックリスト
-
-> このファイルはテンプレートです。`architecture-skill-development` でプロジェクトの変更カテゴリと詳細設計パスに合わせて書き換えてください。
-
-design-change の Phase 3（影響ドキュメントの確定）で参照する。
-変更の種類に応じて、修正が必要なドキュメントを網羅的に特定する。
-
-## 変更種別ごとのチェック項目
-
-### ユースケース（UC）の追加・変更・削除
-
-| ドキュメント | パス | チェック |
-|------------|------|------|
-| ユースケース一覧 | `docs/02_概要設計/ユースケース一覧.md` | UC の追加・修正・削除を反映 |
-| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | 責務分割・外部 IF への影響 |
-| UC 詳細設計 | `docs/03_詳細設計/<UC詳細設計パス>/UC-{日本語名}.md` | シーケンス・入出力・判断条件の変更 |
-| DB・外部サービス | `docs/03_詳細設計/<DB・外部サービスパス>/` | UC が利用するスキーマ・外部 IF への影響 |
-
-### ドメイン設計の変更（style: ddd のみ）
-
-| ドキュメント | パス | チェック |
-|------------|------|------|
-| ドメインモデル | `docs/02_概要設計/ドメインモデル.md` | 集約・境界コンテキストへの影響 |
-| ドメイン詳細設計 | `docs/03_詳細設計/<ドメイン詳細設計パス>/{ドメイン名}.md` | エンティティ・値オブジェクト・不変条件の変更 |
-| UC 詳細設計 | `docs/03_詳細設計/<UC詳細設計パス>/UC-{日本語名}.md` | ドメイン変更が UC フローに影響する場合 |
-| DB・外部サービス | `docs/03_詳細設計/<DB・外部サービスパス>/` | スキーマ・保存方針への影響 |
-
-### DB・外部サービスの変更
-
-| ドキュメント | パス | チェック |
-|------------|------|------|
-| DB・外部サービス | `docs/03_詳細設計/<DB・外部サービスパス>/` | テーブル定義・外部 API 仕様の変更 |
-| UC 詳細設計 | `docs/03_詳細設計/<UC詳細設計パス>/UC-{日本語名}.md` | 保存フロー・外部呼び出しへの影響 |
-| ドメイン詳細設計 | `docs/03_詳細設計/<ドメイン詳細設計パス>/{ドメイン名}.md` | ドメインモデルへの影響（style: ddd のみ） |
-
-### アーキテクチャ・設計方針の変更
-
-| ドキュメント | パス | チェック |
-|------------|------|------|
-| ADR | `docs/02_概要設計/90_ADR/全体/` | 横断的な決定を記録 |
-| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | 技術方針・全体構成の変更 |
-| 要件定義 | `docs/01_要件定義/要件定義.md` | 要件レベルの変更がある場合 |
-| 詳細設計一式 | `docs/03_詳細設計/**` | 方針変更の具体反映 |
-
-### 要件の変更
-
-| ドキュメント | パス | チェック |
-|------------|------|------|
-| 要件定義 | `docs/01_要件定義/要件定義.md` | 要件・スコープの変更 |
-| ユビキタス言語辞書 | `docs/01_要件定義/ユビキタス言語辞書.md` | 用語の追加・変更 |
-| ユースケース一覧 | `docs/02_概要設計/ユースケース一覧.md` | 要件変更に伴う UC の追加・削除 |
-| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | スコープ変更による構成への影響 |
-
-## 二次影響の確認観点
-
-- **ユースケース一覧 ↔ 詳細設計**: 一覧に記載の UC が詳細設計でカバーされているか
-- **システム全体俯瞰 ↔ 詳細設計**: 責務分割が詳細設計に落ちているか
-- **ドメイン設計 ↔ DB スキーマ**: ドメインのフィールドが DB カラムと対応しているか（style: ddd のみ）
-- **ヘッダー ↔ 実ファイル**: `depends_on` と `maps_to` が現状に追随しているか

package/spec-runner/templates/.github/skills/spec-probe/SKILL.md

@@ -1,12 +0,0 @@
----
-name: spec-probe
-description: 設計・要件の前提を一問一答で深掘りする。設計レビュー・要件定義・ADR 前に使う。
----
-
-計画・設計・要件のあらゆる側面について、共通理解に達するまで容赦なくインタビューする。
-決定ツリーの各分岐を辿り、依存関係のある判断を一つずつ解決する。
-各質問に対して、推奨する答えも提示する。
-
-質問は一度に一つだけ行う。
-
-コードベースを読めば答えられる質問は、質問する代わりにコードを読む。