spec-runner 1.4.1 → 1.6.0

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

@@ -5,9 +5,6 @@ description: architecture contract と docs を読み、プロジェクト専用
 
 # architecture-skill-development
 
-`architecture-definition` または `existing-project-to-docs` の後に使う。
-決まったアーキテクチャから、そのプロジェクト専用の skill / rule / template を作る。
-
 ## 全体フロー
 
 ```
@@ -34,7 +31,7 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 ## Phase 3: skill / rule / template へ分解
 
-ファイルを作成する前に `.github/instructions/harness-formats.instructions.md` を読み、フォーマットを確認する。
+ファイルを作成する前に `.claude/skills/harness-engineering/references/harness-format.md` を読み、フォーマットを確認する。
 
 1. 会話フローは skill にする
 2. 常時守る約束は rule にする
@@ -42,60 +39,37 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 
 ### seed の選択
 
-`architecture.yaml` の `style` を読み、使う seed を決める。
+`architecture.yaml` の `style` と `has_frontend` を読み、使う seed を決める。
 
 | style | 使う seed | 説明 |
 |-------|----------|------|
-| `ddd` | `docs-driven-seed` | ドメイン層（集約・値オブジェクト）を持つ DDD 向けフロー |
+| `ddd` | `ddd-seed` | ドメイン層（集約・値オブジェクト）を持つ DDD 向けフロー |
 | `layered` | `simple-seed` | ドメイン層を持たない UC・サービス層中心のフロー |
 
-選んだ seed の SKILL.md をコピーして、このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作ることを目的とする。
+`has_frontend: true` の場合、seed から生成するプロジェクト専用スキルに「UC ファイルに画面レイアウトセクションを含める」旨を明記する。
 
-具体的には:
-- 選んだ seed の SKILL.md をコピーして、project 専用の開発 skill の土台にする
-- フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換える
-- Phase 1（要件定義）は architecture-definition で完了済みのため削除する
-- 元の seed は書き換え完了後にアーカイブ候補とする（Phase 6 で提案する）
+選んだ seed の SKILL.md をコピーし、フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換えたプロジェクト専用 skill を作る（Phase 1 は完了済みのため削除する。元の seed はアーカイブ候補とする）。
 
 4. ユーザーに確認・承認を得る
 
 ## Phase 4: 基盤 skill のプロジェクト固有化
 
 インストール時に配布された基盤 skill のプレースホルダーを、このプロジェクトの実態に書き換える。
+以降の書き換えはすべて `architecture.yaml` の `integrations` に従う（`claude` のみなら `.claude/` だけ、`github` のみなら `.github/` だけ、両方なら対で更新する）。
 
-> 以降の書き換えはすべて `architecture.yaml` の `integrations` に従う。`claude` のみなら `.claude/` だけ、`github` のみなら `.github/` だけ、両方なら対で更新する。
-
-### testing.md の書き換え
+### test-config.md の書き換え
 
-`instructions/testing.instructions.md` はテスト実行コマンドの単一ソースとして `test-driven-development` スキルと `test-runner` エージェントの両方から参照される。`architecture.yaml` の `testing_policy` を参照して書き換える。
+`rules/test-config.md`（GitHub Copilot は `instructions/test-config.instructions.md`）はテスト実行コマンドの単一ソースとして `test-driven-development` スキルと `run-tests` エージェントの両方から参照される。`architecture.yaml` の `testing_policy` を参照して書き換える。
 
 1. **テスト実行コマンド**: `<your-unit-test-command>` / `<your-integration-test-command>` 等を実際のコマンドに書き換える
-
-   例:
-   ```bash
-   # 全テスト
-   docker compose run --rm test pytest
-
-   # 特定ファイル
-   docker compose run --rm test pytest tests/path/to/test_file.py
-
-   # カバレッジ計測
-   docker compose run --rm test pytest --cov=. --cov-report=term-missing
-   ```
-
 2. **テスト構成**: `tests/` のディレクトリ構成が実態と異なる場合は書き換える
 
-上記の `integrations` ルールに従って反映する。
-
-### test-driven-development の書き換え（テストコマンド以外）
+### test-driven-development の書き換え
 
 `architecture.yaml` の `language` を参照して、以下を実際の値に置き換える。
 
-1. **コード例**: 言語・フレームワークに合わせて RED / GREEN の例を書き直す
-2. **fixture / テストデータ**: このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
-3. **モックのルール**: 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
-
-上記の `integrations` ルールに従って反映する。
+1. **fixture / テストデータ**: このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
+2. **モックのルール**: 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
 
 ### 影響範囲チェックリストの書き換え
 
@@ -104,7 +78,7 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 1. 変更カテゴリをプロジェクトの構成要素（モジュール・サービス・ドメインなど）に合わせて追加・削除する
 2. 詳細設計のパスを `architecture.yaml` の `folder_structure` に合わせて書き換える
 
-### coding.md の書き換え
+### code-style.md の書き換え
 
 `architecture.yaml` の `language` と `folder_structure` を参照して、以下を実際の値に置き換える。
 
@@ -114,8 +88,6 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 3. **言語・型固有ルール**: `<your-language-and-type-rules>` を言語・フレームワークに合わせた具体的なルールに書き換える
 4. **プロジェクト構造**: `<your-project-structure>` を `folder_structure` の実際のディレクトリ構成に書き換える
 
-上記の `integrations` ルールに従って反映する。
-
 ### その他の基盤 skill
 
 同様のプレースホルダーや汎用記述が他の skill にあれば、同じ要領で書き換える。
@@ -137,9 +109,9 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 |---|---|
 | `architecture-definition` | 新規プロジェクト初期化専用。アーキテクチャ確定後は不要 |
 | `existing-project-to-docs` | 既存プロジェクト取り込み専用。docs 生成後は不要 |
-| `docs-driven-seed` | Phase 3 で project 専用 skill の種として使い終えたら不要（`style: ddd` のとき）。ただし `templates/01_要件定義/` は `architecture-definition` が参照するため、`architecture-definition` も同時にアーカイブする場合のみ削除する |
-| `simple-seed` | Phase 3 で project 専用 skill の種として使い終えたら不要（`style: layered` のとき） |
-| `architecture-skill-development`（このファイル自身） | project 専用 skill が安定したら不要。ただしアーキテクチャが大きく変わる場合は再利用する可能性があるため、削除ではなくアーカイブを推奨 |
+| `ddd-seed` | style: ddd で seed 使用後は不要。ただし `architecture-definition` も同時アーカイブする場合のみ `templates/01_要件定義/` を削除可 |
+| `simple-seed` | style: layered で seed 使用後は不要 |
+| `architecture-skill-development`（このファイル自身） | project 専用 skill が安定したら不要。アーキテクチャ大変更時は再利用可 |
 
 ### 手順
 
@@ -148,8 +120,8 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
 3. 必要であれば削除前にバックアップ先をユーザーに伝える
 4. `.spec-runner/` の不要ファイルも整理する
    - `intake/current-system-inventory.md` — docs に昇格済みなら削除してよい
-   - `architecture/architecture.yaml` — project 専用 skill が完成し、参照不要になったら削除してよい
-   - `scripts/scan.js` — **削除しない**。`@impact-analyzer` が常時依存しているため
+   - `architecture/architecture.yaml` — **削除しない**。設計変更のたびに最新状態を保つ。プロジェクトの全体像を把握するための正本として使い続ける
+   - `scripts/scan.js` — **削除しない**。`@analyze-impact` が常時依存しているため
 5. `CLAUDE.md` を更新する
    - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
    - 作成した project 専用 skill の名前と使いどころを記載する
@@ -161,10 +133,3 @@ Phase 6: セットアップ専用 skill のアーカイブ提案
      テストを書くときは `/test-driven-development` を使う。
      ```
    - `.claude/` と `.github/` 両系で内容が変わる場合は、それぞれに反映する
-
-## 原則
-
-- 固定の architecture pack を増やしすぎない
-- project 専用 skill を先に考える
-- docs と architecture contract の両方を入力にする
-- skill の削除・移動はユーザー承認なしに行わない

package/spec-runner/templates/{.claude/skills/docs-driven-seed → .github/skills/ddd-seed}/SKILL.md

@@ -1,12 +1,21 @@
 ---
-name: docs-driven-seed
+name: ddd-seed
 description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジェクトの初期テンプレートとして使い、architecture-skill-development でプロジェクト専用スキルに育てる。
 ---
 
-# docs-driven-seed
+# ddd-seed
 
-> DDD を採用するプロジェクト向けの docs 正本開発フロー（種）。`architecture.yaml` の `style: ddd` で使う。レイヤード / CRUD 中心は `simple-seed` を使う。
-> このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てる。
+## 前提: architecture.yaml の読み込み
+
+開始前に `.spec-runner/architecture/architecture.yaml` を読み、以下を確認する:
+
+| キー | 用途 |
+|------|------|
+| `style` | このスキル（`ddd`）が適切かを確認 |
+| `has_frontend` | `true` なら UC ファイルに「画面レイアウト」セクションを含める |
+| `folder_structure` | `maps_to` パスの基準として参照する |
+
+設計フェーズで新たな方針・コンポーネントが確定したら、都度 architecture.yaml を最新状態に保つ。
 
 ## 全体フロー
 
@@ -20,10 +29,11 @@ Phase 5: TDD → 実装
 
 ## 前提ルール
 
-- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- docs は正本とし、各ドキュメントに `spec_runner`ヘッダーを付ける
 - 詳細設計は `01_ドメイン/` `02_ユースケース/` `03_DB・外部サービス/` の 3 層で構成する
-- UC がドメインを使う。ドメインの中に UC は入れない
+- ドメインを先に設計し、UC はドメインを参照する形で書く。ドメインの中に UC は入れない
 - `maps_to` は必ず設定する。パス推定に頼らない
+- 実装ファイルのパスは UC ドキュメント本文に書かない。`maps_to` ヘッダーで管理する
 - ユーザー承認なしに次フェーズへ進めない
 
 ## Phase 1: 要件定義
@@ -94,6 +104,8 @@ docs/03_詳細設計/01_ドメイン/
 
 テンプレート: `templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md`
 
+> `has_frontend: true` の場合は各 UC ファイルに「画面レイアウト」セクションを含める。`false` なら削除する。
+
 ```
 docs/03_詳細設計/02_ユースケース/
   UC-{日本語名}.md
@@ -112,13 +124,3 @@ docs/03_詳細設計/03_DB・外部サービス/
 ## Phase 5: TDD → 実装
 
 `test-driven-development` スキルへ移行する。
-
-### 実装完了後
-
-- `@design-reviewer` — 設計書⇔実装の整合性チェック
-- `@code-reviewer` — コーディング規約への適合チェック
-
-## 原則
-
-- ドメインを先に設計し、UC はドメインを参照する形で書く
-- `maps_to` は必ず設定する。パス推定に頼らない

package/spec-runner/templates/.github/skills/{docs-driven-seed → ddd-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

@@ -10,6 +10,16 @@ spec_runner:
 
 # ユースケース一覧
 
+<!-- カテゴリは機能領域や画面単位で分ける。例: 認証、ユーザー管理、商品管理 など -->
+
+## {カテゴリ名}
+
+| UC ID | UC名 | 種別 | 概要 |
+|-------|------|------|------|
+| UC-{番号} | {UC名} | Command / Query | {概要} |
+
+## {カテゴリ名}
+
 | UC ID | UC名 | 種別 | 概要 |
 |-------|------|------|------|
 | UC-{番号} | {UC名} | Command / Query | {概要} |

package/spec-runner/templates/.github/skills/{docs-driven-seed → ddd-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

@@ -48,6 +48,21 @@ sequenceDiagram
 |------------|---------|------|
 | {エラーケース} | {発生条件} | {対応} |
 
+## 画面レイアウト
+
+> `has_frontend: true` のときのみ記載する。不要なら削除する。
+
+- 画面名: {画面名}
+- 遷移元: {前の画面 or -}
+- 遷移先: {次の画面 or -}
+
+```
+{画面レイアウト概要 — ASCII art / Markdown テーブルで表現}
+```
+
+- 主要 UI 要素:
+  - {入力フォーム・ボタン・一覧表示など}
+
 ## テスト観点
 
 - {正常系の観点}

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

@@ -5,11 +5,23 @@ description: 既存機能の変更を docs 正本で進めるフローガイド
 
 # design-change
 
-既存機能の変更・修正を設計書駆動で進めるフローガイド。フェーズは順番通りに進める。ユーザーの承認なしに先へ進めない。
+フェーズは順番通りに進める。ユーザーの承認なしに先へ進めない。
 
 影響範囲のチェックリストは `references/影響範囲チェックリスト.md` を参照する。
 ADR テンプレートは `templates/90_ADR/ADRテンプレート.md` を使用する。
 
+## 前提: architecture.yaml の読み込み
+
+開始前に `.spec-runner/architecture/architecture.yaml` を読み、以下を確認する:
+
+| キー | 用途 |
+|------|------|
+| `style` | Phase 4/5 のフォルダパス・設計順序を決定 |
+| `has_frontend` | UC 修正時に「画面レイアウト」セクションの要否を判断 |
+| `folder_structure` | 影響ドキュメントのパス確認に使用 |
+
+設計変更によって方針・構成に変化があった場合は、architecture.yaml も合わせて更新する。
+
 ## 全体フロー
 
 ```
@@ -23,15 +35,16 @@ Phase 6: TDD → 実装 → 検証
 
 ## Phase 1: 変更要求の整理と軽い影響調査
 
-1. 以下をユーザーにヒアリングする
+1. 曖昧な前提があれば `spec-probe` スキルで先に整理する
+2. 以下をユーザーにヒアリングする
    - 変更の背景・課題
    - 変更の目的・期待する結果
    - 影響を受ける機能カテゴリ
    - 技術的・ビジネス的制約
-2. 変更起点となる docs を特定する
-3. `@impact-analyzer` に委任して `depends_on` / `maps_to` を辿る影響ファイルを洗い出す
-4. 変更が影響するドメインと成果物を一覧化する
-5. ユーザーに確認・承認を得る
+3. 変更起点となる docs を特定する
+4. `@analyze-impact` に委任して `depends_on` / `maps_to` を辿る影響ファイルを洗い出す
+5. 変更が影響するドメインと成果物を一覧化する
+6. ユーザーに確認・承認を得る
 
 ## Phase 2: ADR 作成（必要時）
 
@@ -55,23 +68,20 @@ Phase 6: TDD → 実装 → 検証
 ## Phase 3: 影響ドキュメントの確定
 
 1. `references/影響範囲チェックリスト.md` を読み、変更に応じた影響ドキュメントを網羅的に洗い出す
-2. frontmatter の `depends_on` / `maps_to` を使って候補を絞る
+2.ヘッダーの `depends_on` / `maps_to` を使って候補を絞る
 3. 修正が必要なファイルをチェックリスト形式で提示する
-4. `@design-reviewer` エージェントに委任して、現時点の設計書⇔実装の乖離も合わせて確認する
+4. `@review-design` エージェントに委任して、現時点の設計書⇔実装の乖離も合わせて確認する
 5. ユーザーに確認・承認を得る
 
 ## Phase 4: 概要設計の修正
 
+概要設計では「何をするか」に留める。変更理由は ADR または本文で追えるようにする。
+
 1. `ユースケース一覧.md` / `システム全体俯瞰.md` / ADR を必要順に修正する
 2. `style: ddd` の場合: `ドメインモデル.md` も必要に応じて修正する
 3. 修正完了ごとにチェックリストを更新する
 4. 全概要設計の修正完了後、ユーザーに確認・承認を得る
 
-### 修正時の注意
-
-- 変更理由は ADR または本文で追えるようにする
-- 概要設計では「何をするか」に留める
-
 ## Phase 5: 詳細設計の修正
 
 `style: ddd` の場合:
@@ -85,19 +95,8 @@ Phase 6: TDD → 実装 → 検証
 1. `docs/03_詳細設計/01_ユースケース/**` の UC 設計を修正する
 2. DB・外部サービスの変更がある場合は `docs/03_詳細設計/02_DB・外部サービス/**` を修正する
 
-frontmatter の `depends_on` / `maps_to` を更新する。ユーザーに最終確認を得る。
+ヘッダー の `depends_on` / `maps_to` を更新する。ユーザーに最終確認を得る。
 
 ## Phase 6: TDD → 実装 → 検証
 
 設計書修正が承認されたら `test-driven-development` スキルへ移行する。
-
-### 実装完了後のレビュー
-
-- `@design-reviewer` — frontmatter と `maps_to` を起点に設計書⇔実装の整合性チェック
-- `@code-reviewer` — コーディング規約への適合チェック
-
-## 原則
-
-- 影響候補の洗い出しを ADR より先に行う
-- 概要設計を先に直し、そのあと詳細設計を直す
-- frontmatter の更新を後回しにしない

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

@@ -56,4 +56,4 @@ design-change の Phase 3（影響ドキュメントの確定）で参照する
 - **ユースケース一覧 ↔ 詳細設計**: 一覧に記載の UC が詳細設計でカバーされているか
 - **システム全体俯瞰 ↔ 詳細設計**: 責務分割が詳細設計に落ちているか
 - **ドメイン設計 ↔ DB スキーマ**: ドメインのフィールドが DB カラムと対応しているか（style: ddd のみ）
-- **frontmatter ↔ 実ファイル**: `depends_on` と `maps_to` が現状に追随しているか
+- **ヘッダー ↔ 実ファイル**: `depends_on` と `maps_to` が現状に追随しているか

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

@@ -5,9 +5,6 @@ description: 既存プロジェクトを読み解き、docs の正本と archite
 
 # existing-project-to-docs
 
-既存コードから docs を起こすフロー。
-コード、テスト、設定、インフラ定義を読み、`docs/` と `.spec-runner/` の最初の土台を作る。
-
 ## 全体フロー
 
 ```
@@ -21,9 +18,10 @@ Phase 5: architecture contract 化
 
 ## 前提ルール
 
-- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- docs は正本とし、各ドキュメントに `spec_runner`ヘッダーを付ける
 - `maps_to` は必ず設定する。パス推定に頼らない
 - 既存コードを正として観測する。推測する場合は明示する
+- `depends_on` を使って後続変更に耐える形へ整える
 - ユーザー承認なしに次フェーズへ進めない
 - `style: ddd` の場合: UC がドメインを使う。ドメインの中に UC を入れない
 - `style: ddd` の場合: 詳細設計は `01_ドメイン/` `02_ユースケース/` `03_DB・外部サービス/` の 3 層で構成する
@@ -50,25 +48,25 @@ Phase 5: architecture contract 化
 
 ## Phase 2: 要件とユースケースの抽出
 
-要件定義テンプレートは `simple-seed` に存在しないため、`style` に関わらず `docs-driven-seed` のテンプレートを使う。
+要件定義テンプレートは `simple-seed` に存在しないため、`style` に関わらず `ddd-seed` のテンプレートを使う。
 
 1. `current-system-inventory.md` を起点に、既存機能からユースケースを逆算する
-2. `.github/skills/docs-driven-seed/templates/01_要件定義/要件定義.md` を使い `docs/01_要件定義/要件定義.md` を作る
-3. `.github/skills/docs-driven-seed/templates/02_概要設計/ユースケース一覧.md` を使い `docs/02_概要設計/ユースケース一覧.md` を作る
-4. ドメイン用語が識別できたら `.github/skills/docs-driven-seed/templates/01_要件定義/ユビキタス言語辞書.md` を使い `docs/01_要件定義/ユビキタス言語辞書.md` を作る
+2. `.claude/skills/ddd-seed/templates/01_要件定義/要件定義.md` を使い `docs/01_要件定義/要件定義.md` を作る
+3. `.claude/skills/ddd-seed/templates/02_概要設計/ユースケース一覧.md` を使い `docs/02_概要設計/ユースケース一覧.md` を作る
+4. ドメイン用語が識別できたら `.claude/skills/ddd-seed/templates/01_要件定義/ユビキタス言語辞書.md` を使い `docs/01_要件定義/ユビキタス言語辞書.md` を作る
 5. ユーザーに確認・承認を得る
 
 ## Phase 3: 概要設計
 
 `style: ddd` の場合:
 
-1. `.github/skills/docs-driven-seed/templates/02_概要設計/システム全体俯瞰.md` を使い `docs/02_概要設計/システム全体俯瞰.md` を作る
-2. `.github/skills/docs-driven-seed/templates/02_概要設計/ドメインモデル.md` を使い `docs/02_概要設計/ドメインモデル.md` を作る
+1. `.claude/skills/ddd-seed/templates/02_概要設計/システム全体俯瞰.md` を使い `docs/02_概要設計/システム全体俯瞰.md` を作る
+2. `.claude/skills/ddd-seed/templates/02_概要設計/ドメインモデル.md` を使い `docs/02_概要設計/ドメインモデル.md` を作る
 3. 必要なら ADR を作る（作成ルールは下記）
 
 `style: layered` の場合:
 
-1. `.github/skills/simple-seed/templates/02_概要設計/システム全体俯瞰.md` を使い `docs/02_概要設計/システム全体俯瞰.md` を作る
+1. `.claude/skills/simple-seed/templates/02_概要設計/システム全体俯瞰.md` を使い `docs/02_概要設計/システム全体俯瞰.md` を作る
 2. 必要なら ADR を作る（作成ルールは下記）
 
 ### ADR 作成ルール（必要時のみ）
@@ -101,13 +99,13 @@ Phase 5: architecture contract 化
 
 `style: ddd` の場合（ドメイン → UC → DB・外部サービス の順に設計する）:
 
-1. `.github/skills/docs-driven-seed/templates/03_詳細設計/01_ドメイン/{ドメイン名}.md` を使い、ドメインごとにビジネスルール・集約を整理し `docs/03_詳細設計/01_ドメイン/{ドメイン名}.md` を作る
-2. `.github/skills/docs-driven-seed/templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を使い、UC ごとに `docs/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を作る（シーケンス図は Mermaid で埋め込む）
+1. `.claude/skills/ddd-seed/templates/03_詳細設計/01_ドメイン/{ドメイン名}.md` を使い、ドメインごとにビジネスルール・集約を整理し `docs/03_詳細設計/01_ドメイン/{ドメイン名}.md` を作る
+2. `.claude/skills/ddd-seed/templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を使い、UC ごとに `docs/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を作る（シーケンス図は Mermaid で埋め込む）
 3. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/03_DB・外部サービス/` を作る
 
 `style: layered` の場合（UC → DB・外部サービス の順に設計する）:
 
-1. `.github/skills/simple-seed/templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を使い、UC ごとに `docs/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を作る
+1. `.claude/skills/simple-seed/templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を使い、UC ごとに `docs/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を作る
 2. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/02_DB・外部サービス/` を作る
 
 各ファイルの `maps_to` に対応コードとテストを必ず入れる。ユーザーに確認・承認を得る。
@@ -118,9 +116,3 @@ Phase 5: architecture contract 化
 2. 現状構造を project 専用 skill へ渡せる粒度に整える
 3. `architecture-skill-development` へ引き渡す
 
-## 原則
-
-- docs は正本。draft であっても `spec_runner` frontmatter とテンプレートを使う
-- `maps_to` は必ず設定する。パス推定に頼らない
-- 既存コードを正として観測する。推測する場合は明示する
-- `depends_on` を使って後続変更に耐える形へ整える

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

@@ -5,8 +5,6 @@ description: skills・rules・agents・テンプレートを改善・保守す
 
 # harness-engineering
 
-skills・rules・agents・テンプレートを改善するためのメタスキル。主目的の作業を先に進め、再利用価値のある改善が必要なときだけ使う。
-
 ## 使うタイミング
 
 以下のいずれかに当てはまるときに使う。
@@ -23,8 +21,6 @@ skills・rules・agents・テンプレートを改善するためのメタスキ
 - アプリケーションコードに対する TDD
 - 単なる言い回しの微調整で済む変更
 
-TDD はこのスキルの対象ではない。TDD は `test-driven-development` スキルに従い、対象プロダクトのコード品質を上げるために行う。
-
 ## 全体フロー
 
 ```
@@ -36,68 +32,33 @@ Phase 4: 影響範囲の反映確認
 
 ## Phase 1: 問題の抽出
 
-### 手順
-
 1. 今回の作業で何が詰まり、どこに無駄が出たかを整理する
 2. その問題が一時的なものか、再発しうる構造的な問題かを判定する
-3. 改善対象を特定する
-   - skill
-   - rule
-   - agent
-   - template
+3. 改善対象を特定する（skill / rule / agent / template）
 
-### 出力
-
-- 問題の要約
-- 再発条件
-- 変更対象の候補一覧
+**出力:** 問題の要約・再発条件・変更対象の候補一覧
 
 ## Phase 2: 対応方針の決定
 
-1. 最小変更で解決できる対象を選ぶ
+1. 最小変更で解決できる対象を選ぶ（まず既存の資産を直す。新しい skill は繰り返し使う独立したワークフローがある場合だけ追加する）
 2. 新しい skill を増やすべきか、既存 skill / rule / agent の修正で十分かを判断する
 3. Claude / Copilot の両テンプレートに影響するか確認する
 
-### 判断原則
-
-- まず既存の資産を直す
-- 新しい skill は、繰り返し使う独立したワークフローがある場合だけ追加する
-- 一時的な事情を恒久ルールにしない
-
 ## Phase 3: skill / rule / agent / template の修正
 
-ファイルを作成・修正する前に `.github/instructions/harness-formats.instructions.md` を読み、フォーマットを確認する。
+ファイルを作成・修正する前に `.claude/skills/harness-engineering/references/harness-format.md` を読み、フォーマットを確認する。
 
 1. 対象ファイルを特定する
-2. 意図が変わらない最小差分で修正する
-3. 片系だけでなく、対応するテンプレートも揃えて更新する
-   - `.claude/`
-   - `.github/`
+2. 意図が変わらない最小差分で修正する（役割の重複を増やさない。既存スキルの主要フローを壊さない。ユーザー承認が前提のフローは勝手に短絡しない）
+3. `.claude/` と `.github/` を対で更新する
 4. references や templates を参照している場合、必要な範囲だけ更新する
 
-### 修正時の注意
-
-- 役割の重複を増やさない
-- 既存スキルの主要フローを壊さない
-- ユーザー承認が前提のフローは勝手に短絡しない
-- アプリコード向けの TDD ルールを、このスキルの改善目的と混同しない
-
 ## Phase 4: 影響範囲の反映確認
 
-### 確認項目
-
 - 問題の原因に対して、変更箇所が直接効いているか
 - 関連する skill / rule / agent / template の記述が矛盾していないか
 - Claude / Copilot の対応ファイルに反映漏れがないか
 - 今回限りのノイズをルール化していないか
 - skill 名・起動条件・使いどころを変更した場合、`CLAUDE.md` の記述と一致しているか
-- `CLAUDE.md` が肥大化していないか（20 行超えたら `instructions/` や `skills/` へ移動を検討する）
-- docs 構造・命名規則・node_id 体系に影響する変更の場合、`design-docs.instructions.md` と整合しているか
-
-## 原則
-
-- ハーネス改善は常時実行しない。必要なときだけ行う
-- 主目的の作業を優先する
-- 最小変更で改善する
-- 新しい skill の追加は慎重に行う
-- TDD の責務を skill 改善と混同しない
+- `CLAUDE.md` が肥大化していないか（20行超えたら `rules/` や `skills/` へ移動を検討する）
+- docs 構造・命名規則・node_id 体系に影響する変更の場合、`design-docs.md` と整合しているか

package/spec-runner/templates/.github/{instructions/harness-formats.instructions.md → skills/harness-engineering/references/harness-format.md}

@@ -4,8 +4,6 @@ applyTo: "**"
 
 # ハーネスファイルフォーマット
 
-`harness-engineering` や `architecture-skill-development` で rules / agents / skills を作成・修正するときは、このフォーマットに従う。
-
 ## rule ファイル（`.github/instructions/*.instructions.md`）
 
 ```markdown
@@ -67,7 +65,7 @@ CLAUDE.md は全会話で常にコンテキストに読み込まれる。書く
 
 | 内容 | 正しい置き場所 |
 |------|--------------|
-| コーディング規約の詳細 | `.github/instructions/coding.instructions.md` |
+| コーディング規約の詳細 | `.github/instructions/code-style.instructions.md` |
 | フォーマット定義・手順 | `.github/instructions/*.instructions.md` |
 | スキルの詳細フロー | `.github/skills/*/SKILL.md` |
 | 過去の決定・背景 | `docs/02_概要設計/90_ADR/` |
@@ -85,3 +83,11 @@ CLAUDE.md は全会話で常にコンテキストに読み込まれる。書く
   - 両方 → `.claude/` と `.github/` を対で更新する
 - `description` は「何をするか」より「いつ・なぜ使うか」を優先して書く
 - 新規作成時は既存ファイルを参考にフォーマットを確認してから作る
+
+## 書き方の原則
+
+- H1 は用途を示す。description の言い換えは書かない
+- H1 直下に説明文を置かない。description に書いたことを本文で繰り返さない
+- `（読み取り専用）` のような付記は H1 に入れない。tools の構成で表現する
+- agent のテンプレート注記（「このファイルはテンプレートです」）は agent ファイルに書かない。test-config.md に書く
+- agent の書き順: ヘッダー → H1 → 前提・入力（必要な場合のみ） → 手順 → 報告フォーマット

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

@@ -5,8 +5,17 @@ description: レイヤードアーキテクチャ / CRUD 中心のプロジェ
 
 # simple-seed
 
-> レイヤードアーキテクチャ / CRUD 中心のプロジェクト向けの docs 正本開発フロー（種）。`architecture.yaml` の `style: layered` で使う。DDD が必要なプロジェクトは `docs-driven-seed` を使う。
-> このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てる。
+## 前提: architecture.yaml の読み込み
+
+開始前に `.spec-runner/architecture/architecture.yaml` を読み、以下を確認する:
+
+| キー | 用途 |
+|------|------|
+| `style` | このスキル（`layered`）が適切かを確認 |
+| `has_frontend` | `true` なら UC ファイルに「画面レイアウト」セクションを含める |
+| `folder_structure` | `maps_to` パスの基準として参照する |
+
+設計フェーズで新たな方針・コンポーネントが確定したら、都度 architecture.yaml を最新状態に保つ。
 
 ## 全体フロー
 
@@ -20,9 +29,10 @@ Phase 5: TDD → 実装
 
 ## 前提ルール
 
-- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- docs は正本とし、各ドキュメントに `spec_runner`ヘッダーを付ける
 - 詳細設計は `01_ユースケース/` `02_DB・外部サービス/` の 2 層で構成する
 - `maps_to` は必ず設定する。パス推定に頼らない
+- 実装ファイルのパスは UC ドキュメント本文に書かない。`maps_to` ヘッダーで管理する
 - ユーザー承認なしに次フェーズへ進めない
 
 ## Phase 1: 要件定義
@@ -72,6 +82,8 @@ UC → DB・外部サービス の順に設計する。
 
 テンプレート: `templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md`
 
+> `has_frontend: true` の場合は各 UC ファイルに「画面レイアウト」セクションを含める。`false` なら削除する。
+
 ```
 docs/03_詳細設計/01_ユースケース/
   UC-{日本語名}.md
@@ -91,12 +103,6 @@ docs/03_詳細設計/02_DB・外部サービス/
 
 `test-driven-development` スキルへ移行する。
 
-### 実装完了後
-
-- `@design-reviewer` — 設計書⇔実装の整合性チェック
-- `@code-reviewer` — コーディング規約への適合チェック
-
 ## 原則
 
 - ドメイン層は持たない。ビジネスロジックは UC / サービス層で表現する
-- `maps_to` は必ず設定する。パス推定に頼らない

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

@@ -10,6 +10,16 @@ spec_runner:
 
 # ユースケース一覧
 
+<!-- カテゴリは機能領域や画面単位で分ける。例: 認証、ユーザー管理、商品管理 など -->
+
+## {カテゴリ名}
+
+| UC ID | UC名 | 種別 | 概要 |
+|-------|------|------|------|
+| UC-{番号} | {UC名} | Command / Query | {概要} |
+
+## {カテゴリ名}
+
 | UC ID | UC名 | 種別 | 概要 |
 |-------|------|------|------|
 | UC-{番号} | {UC名} | Command / Query | {概要} |

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

@@ -46,6 +46,21 @@ sequenceDiagram
 |------------|---------|------|
 | {エラーケース} | {発生条件} | {対応} |
 
+## 画面レイアウト
+
+> `has_frontend: true` のときのみ記載する。不要なら削除する。
+
+- 画面名: {画面名}
+- 遷移元: {前の画面 or -}
+- 遷移先: {次の画面 or -}
+
+```
+{画面レイアウト概要 — ASCII art / Markdown テーブルで表現}
+```
+
+- 主要 UI 要素:
+  - {入力フォーム・ボタン・一覧表示など}
+
 ## テスト観点
 
 - {正常系の観点}