spec-runner 1.1.10 → 1.1.16

package/spec-runner/templates/.github/instructions/coding.instructions.md

@@ -23,6 +23,7 @@ applyTo: "src/**,tests/**"
 - **言語**: 日本語
 - **docstring**: モジュール先頭に1行で概要を書く。関数・クラスには原則不要（名前で意図が伝わる場合）
 - **インラインコメント**: ビジネスロジックの「なぜ」を説明する場合のみ。処理内容の「何」は書かない
+- **変更履歴コメント禁止**: `# 新機能追加`, `# ここを修正`, `# v2 で変更` のような変更経緯はコードに書かない。git の commit message で管理する
 
 ```python
 # 良い例
@@ -88,6 +89,16 @@ truncated_json = '[{"account_name": "売掛金", ...'
 
 - **英語コメント禁止**: `Arrange` / `Act` / `Assert` 等の英語は使わない
 
+## 後方互換ハックの禁止
+
+使われなくなったコードは完全に削除する。互換性維持のための温存は行わない。
+
+禁止パターン:
+- 未使用の引数・変数を `_` プレフィックスで残す（`_old_param`）
+- 削除した型・関数を `from x import Y` で再公開する
+- `# removed`, `# deprecated`, `# 旧実装` コメントとともにコードを残す
+- 後方互換用のラッパー関数・エイリアスを追加する
+
 ## 検索ルール
 
 - コードの検索・置換は `src/` と `tests/` の両方を対象にする

package/spec-runner/templates/.github/instructions/design-docs.instructions.md

@@ -19,44 +19,61 @@ applyTo: "docs/**"
 - **`docs/**` の全設計書に frontmatter を付ける**
 - 正本の必須項目は `spec_runner.node_id` / `spec_runner.kind` / `spec_runner.depends_on` / `spec_runner.maps_to`
 - `depends_on` はまず文字列配列でよい。依存理由が必要な場合のみオブジェクト形式を使う
-- `maps_to` には見直し対象となる `src/` / `tests/` / IaC / 設定ファイルを列挙する
+- `maps_to` には見直し対象となる `src/` / `tests/` / IaC / 設定ファイルを列挙する。**必ず設定する（空にしない）**
 - `modules` / `source_files` などの拡張項目を足す場合でも、`maps_to` と矛盾させない
 
 ```yaml
 ---
 spec_runner:
-  node_id: detail.src.agents.reconciliation.agent
+  node_id: detail.usecase.注文確定
   kind: detailed_design
   depends_on:
-    - overview.system_context
-    - use_case.reconciliation.list
+    - overview.use_case_list
+    - detail.domain.注文
   maps_to:
-    - src/agents/reconciliation/agent.py
-    - tests/agents/reconciliation/test_agent.py
+    - src/application/order/confirm.py
+    - src/domain/order/aggregate.py
+    - tests/application/order/test_confirm.py
 ---
 ```
 
+### node_id 体系
+
+| 対象 | node_id 形式 | 例 |
+|------|-------------|-----|
+| 要件定義 | `requirement.{名前}` | `requirement.要件定義` |
+| システム全体俯瞰 | `overview.system_context` | — |
+| ドメインモデル | `overview.domain_model` | — |
+| ユースケース一覧 | `overview.use_case_list` | — |
+| ADR | `overview.adr.{slug}` | `overview.adr.0404-ドメイン-注文集約` |
+| ドメイン詳細設計 | `detail.domain.{ドメイン名}` | `detail.domain.注文` |
+| UC 詳細設計 | `detail.usecase.{UC名}` | `detail.usecase.注文確定` |
+| DB・外部サービス | `detail.db.{名前}` | `detail.db.スキーマ定義` |
+
 ## 命名規則
 
 | 対象 | 規則 | 例 |
 |------|------|-----|
-| `docs/01_要件定義` | 日本語 | `要件定義.md` |
-| `docs/02_概要設計` | 日本語 | `ユースケース一覧.md`, `システム全体俯瞰.md` |
-| `docs/02_概要設計/ユースケース` | `UC-{日本語名}.md` | `UC-差異一覧表示.md` |
-| `docs/02_概要設計/90_ADR` | `ADR-0001-{slug}.md` | `ADR-0001-detailed-design-mirrors-src.md` |
-| `docs/03_詳細設計/src/**` | `src/` に合わせた英語 `snake_case` | `agent.md`, `domain.md`, `skill.md` |
-| `docs/03_詳細設計/infrastructure/**` | 対応先に合わせる。例外で置く場合も `maps_to` 必須 | `database.md`, `schema.dbml` |
+| `docs/01_要件定義` | 日本語 | `要件定義.md`, `ユビキタス言語辞書.md` |
+| `docs/02_概要設計` | 日本語 | `ユースケース一覧.md`, `システム全体俯瞰.md`, `ドメインモデル.md` |
+| `docs/02_概要設計/90_ADR/{対象}/` | `mmdd-{日本語タイトル}.md` | `0404-注文集約の設計.md` |
+| `{対象}` の選択肢 | `全体` / `ドメイン` / `UC` / `DB` | — |
+| `docs/03_詳細設計/01_ドメイン` | 日本語 | `注文.md`, `在庫.md` |
+| `docs/03_詳細設計/02_ユースケース` | `UC-{日本語名}.md` | `UC-注文確定.md` |
+| `docs/03_詳細設計/03_DB・外部サービス` | 日本語 | `スキーマ定義.dbml`, `外部サービス.md` |
 
 ## ADR
 
 - **ADR は必ず 3 案を比較してから採用案を決める**
-- ADR は原則 `docs/02_概要設計/90_ADR/` に置く
-- ドメインローカル ADR が必要な場合だけ `docs/02_概要設計/<ドメイン>/90_ADR/` を使う
+- ADR は `docs/02_概要設計/90_ADR/{対象}/` で管理する（`全体` / `ドメイン` / `UC` / `DB`）
+- ファイル名は `mmdd-{日本語タイトル}.md`。対象はフォルダで表す
 - ADR は理由の記録であり、詳細設計の代わりにしない
+- 廃止 UC の理由も ADR に記録する（UC ファイル本体は削除）
 
 ## 文書品質
 
 - **概要設計では「何をするか」を書き、コード片・DDL・クラス定義は持ち込まない**
-- **詳細設計では `src/` に対応する責務・入出力・判断条件・テスト観点を書く**
-- **`docs/03_詳細設計` は原則 `src/` ミラーにする。例外文書は `maps_to` で根拠を残す**
+- **詳細設計ではドメインルール・UC の責務・入出力・判断条件・テスト観点を書く。コード・プロンプト本文は書かない**
+- **`maps_to` を唯一の src 対応として使う。パス推定に頼らない**
 - **Markdown に HTML タグ（details, summary, br など）を使わない**
+- **`概要.md` のような汎用的な名前のファイルは作らない。内容を具体的に示す名前（`要件定義.md`、`ユースケース一覧.md`、`システム全体俯瞰.md` など）を使う**

package/spec-runner/templates/.github/instructions/harness-formats.instructions.md

@@ -0,0 +1,84 @@
+---
+applyTo: "**"
+---
+
+# ハーネスファイルフォーマット
+
+`harness-engineering` や `architecture-skill-development` で rules / agents / skills を作成・修正するときは、このフォーマットに従う。
+
+## rule ファイル（`.github/instructions/*.instructions.md`）
+
+```markdown
+---
+applyTo: "対象パス/**"   # 省略すると "**"（全ファイルに適用）
+---
+
+# ルール名
+
+本文...
+```
+
+- 対応する `.claude/rules/{name}.md` も同時に作成・更新する
+
+## agent ファイル（`.github/agents/*.agent.md`）
+
+```markdown
+---
+name: agent-name
+description: いつ・何のために呼ぶかを具体的に書く（トリガー型）
+tools: Read, Grep, Glob          # 必要最小限のツールだけ付与
+model: sonnet
+---
+
+# エージェント名
+
+本文...
+```
+
+- `description` はトリガー型で書く（「〇〇のときに自動で呼ぶ」形式）
+- `tools` は最小権限原則。読み取りのみなら `Read, Grep, Glob`
+- 対応する `.claude/agents/{name}.md` も同時に作成・更新する
+
+## skill ファイル（`.github/skills/{name}/SKILL.md`）
+
+```markdown
+---
+name: skill-name
+description: このスキルの目的と使うタイミング（1〜2行）
+---
+
+# スキル名
+
+本文...
+```
+
+- 対応する `.claude/skills/{name}/SKILL.md` も同時に作成・更新する
+
+## CLAUDE.md
+
+CLAUDE.md は**全会話で常にコンテキストに読み込まれる**。書くほどコストが増えるため、最小に保つ。
+
+### 書いてよいもの
+
+- よく使う skill の名前と起動タイミング（開発ワークフローの入口）
+- プロジェクト全体に常時適用すべき制約（例: 言語、承認フロー）
+
+### 書いてはいけないもの（代わりの置き場所）
+
+| 内容 | 正しい置き場所 |
+|------|--------------|
+| コーディング規約の詳細 | `.github/instructions/coding.instructions.md` |
+| フォーマット定義・手順 | `.github/instructions/*.instructions.md` |
+| スキルの詳細フロー | `.github/skills/*/SKILL.md` |
+| 過去の決定・背景 | `docs/02_概要設計/90_ADR/` |
+
+### 目安
+
+- 20行を超えたら見直しを検討する
+- 新しい内容を追加する前に「instructions / skills に移せないか」を先に考える
+
+## 共通原則
+
+- `.claude/` と `.github/` は常に対で更新する（片系だけ更新しない）
+- `description` は「何をするか」より「**いつ・なぜ使うか**」を優先して書く
+- 新規作成時は既存ファイルを参考にフォーマットを確認してから作る

package/spec-runner/templates/.github/instructions/sub-agent-delegation.instructions.md

@@ -0,0 +1,37 @@
+---
+applyTo: "**"
+---
+
+# サブエージェント委任ルール
+
+**メインエージェントは判断・対話・ファイル編集に集中する。検証・調査・実行は積極的にサブエージェントへ委任する。**
+
+## 委任する場面と委任先
+
+| 場面 | 委任先 | タイミング |
+|------|--------|-----------|
+| 設計書⇔実装の整合性確認 | `@design-reviewer` | 設計書を変更したとき、フェーズレビュー時 |
+| コーディング規約チェック | `@code-reviewer` | 実装・修正が完了したとき |
+| テスト実行＋失敗分析 | `@test-runner` | 実装・修正が完了したとき |
+| 変更の影響範囲調査 | `@impact-analyzer` | design-change で影響範囲を洗うとき |
+
+## 並行起動
+
+独立して動けるエージェントは同時に起動する。
+
+例: 実装完了後 → `@test-runner` と `@code-reviewer` を**同時に**起動し、両方の結果を待ってからユーザーへ報告する。
+
+## メインエージェントが自分でやること
+
+サブエージェントは会話の文脈を持たない。以下はメインエージェントが担う:
+
+- ユーザーとの対話・意思決定・承認の受け取り
+- フェーズの進行管理・次のアクションの判断
+- ファイルの作成・編集
+- サブエージェントの結果を解釈してユーザーへ伝える
+
+## 原則
+
+- ファイルの検索・調査はスケールに関わらずサブエージェントに任せる（メインのコンテキスト節約）
+- 検証タスクをメインエージェントが自分でやらない
+- サブエージェントの報告はポイントを絞ってユーザーへ伝える（生の出力をそのまま貼らない）

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

@@ -28,14 +28,14 @@ Phase 5: 次の skill へ引き渡し
 ## Phase 2: 概要設計の骨格作成
 
 1. `docs/02_概要設計/ユースケース一覧.md` を作る
-2. `docs/02_概要設計/システム全体俯瞰.md` を作る
-3. 必要に応じて `ユースケース/`、`外部IF一覧.md`、`非機能・運用方針.md` を追加する
+2. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を作る
+3. `docs/02_概要設計/システム全体俯瞰.md` を作る
 4. ユーザーに確認・承認を得る
 
 ## Phase 3: アーキテクチャ判断の明文化
 
 1. ドメイン分割、責務境界、実装単位、インフラ方針を整理する
-2. 必要なら `docs/02_概要設計/90_ADR/` に ADR を作る
+2. 必要なら対象フォルダに ADR を作る（`90_ADR/全体/` / `ドメイン/` / `UC/` / `DB/`）
 3. ユーザーに確認・承認を得る
 
 ## Phase 4: architecture contract 作成

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

@@ -35,20 +35,22 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 
 ## Phase 3: skill / rule / template へ分解
 
+ファイルを作成する前に **`.github/instructions/harness-formats.instructions.md`** を読み、フォーマットを確認する。
+
 1. 会話フローは skill にする
 2. 常時守る約束は rule にする
 3. 毎回コピーする設計書は template にする
 
-### plugin-development を種として使う
+### docs-driven-seed を種として使う
 
-新規開発フローの skill を作る場合は、`plugin-development` を種として使う。
-`plugin-development` はプラグイン型アーキテクチャ向けの reference workflow であり、
+新規開発フローの skill を作る場合は、`docs-driven-seed` を種として使う。
+`docs-driven-seed` は UC/DDD 駆動の docs 正本開発フローの参照実装であり、
 そのまま使うのではなく、**このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作る**ことを目的とする。
 
 具体的には:
-- `.claude/skills/plugin-development/SKILL.md` をコピーして、project 専用の開発 skill の土台にする
+- `.claude/skills/docs-driven-seed/SKILL.md` をコピーして、project 専用の開発 skill の土台にする
 - フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換える
-- 元の `plugin-development` は書き換え完了後にアーカイブ候補とする（Phase 7 で提案する）
+- 元の `docs-driven-seed` は書き換え完了後にアーカイブ候補とする（Phase 7 で提案する）
 
 ユーザーに確認・承認を得る
 
@@ -109,7 +111,7 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 |---|---|
 | `architecture-definition` | 新規プロジェクト初期化専用。アーキテクチャ確定後は不要 |
 | `existing-project-to-docs` | 既存プロジェクト取り込み専用。docs 生成後は不要 |
-| `plugin-development` | Phase 3 で project 専用 skill の種として使い終えたら不要 |
+| `docs-driven-seed` | Phase 3 で project 専用 skill の種として使い終えたら不要 |
 | `architecture-skill-development`（このファイル自身） | project 専用 skill が安定したら不要。ただしアーキテクチャが大きく変わる場合は再利用する可能性があるため、削除ではなくアーカイブを推奨 |
 
 ### 手順
@@ -117,6 +119,20 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 1. 上記の候補をユーザーに提示し、整理してよいか確認する
 2. 承認を得た skill を `.claude/skills/` と `.github/skills/` から削除する
 3. 必要であれば削除前にバックアップ先をユーザーに伝える
+4. `.spec-runner/` の不要ファイルも整理する
+   - `intake/current-system-inventory.md` — docs に昇格済みなら削除してよい
+   - `architecture/architecture.yaml` — project 専用 skill が完成し、参照不要になったら削除してよい
+5. `CLAUDE.md` を更新する
+   - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
+   - 作成した project 専用 skill の名前と使いどころを記載する
+   - 例:
+     ```markdown
+     ## 開発ワークフロー
+     新機能を実装するときは `/feature-development` を使う。
+     既存機能を変更するときは `/design-change` を使う。
+     テストを書くときは `/test-driven-development` を使う。
+     ```
+   - `.claude/` と `.github/` 両系で内容が変わる場合は、それぞれに反映する
 
 ## 原則
 

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

@@ -30,7 +30,7 @@ Phase 6: TDD → 実装 → 検証
    - 影響を受ける機能カテゴリ
    - 技術的・ビジネス的制約
 2. 変更起点となる docs を特定する
-3. frontmatter の `depends_on` / `maps_to` を使って影響候補を軽く洗う
+3. `@impact-analyzer` に委任して `depends_on` / `maps_to` を辿る影響ファイルを洗い出す
 4. 変更が影響するドメインと成果物を一覧化する
 5. ユーザーに確認・承認を得る
 
@@ -41,16 +41,16 @@ Phase 6: TDD → 実装 → 検証
 3. 各案について概要・メリット・デメリット・適合性を示す
 4. ユーザーが案を決定する
 5. テンプレート `templates/90_ADR/ADRテンプレート.md` をコピーして生成する
-6. ファイル名は `ADR-0001-{slug}.md` 形式にする
+6. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
 
 ### ADR 配置ルール
 
-| 変更スコープ | 配置先 |
-|------------|--------|
-| 横断的な決定 | `docs/02_概要設計/90_ADR/` |
-| 特定ドメイン寄りの決定 | `docs/02_概要設計/<ドメイン>/90_ADR/` |
-
-MVP では `docs/02_概要設計/90_ADR/` に集約する。
+| 対象 | 配置先 |
+|------|--------|
+| システム横断の決定 | `docs/02_概要設計/90_ADR/全体/` |
+| ドメイン設計の決定 | `docs/02_概要設計/90_ADR/ドメイン/` |
+| UC フローの決定 | `docs/02_概要設計/90_ADR/UC/` |
+| DB・外部サービスの決定 | `docs/02_概要設計/90_ADR/DB/` |
 
 ## Phase 3: 影響ドキュメントの確定
 
@@ -62,7 +62,7 @@ MVP では `docs/02_概要設計/90_ADR/` に集約する。
 
 ## Phase 4: 概要設計の修正
 
-1. `ユースケース一覧.md` / `システム全体俯瞰.md` / UC 個別文書 / ADR を必要順に修正する
+1. `ユースケース一覧.md` / `システム全体俯瞰.md` / `ドメインモデル.md` / ADR を必要順に修正する
 2. 修正完了ごとにチェックリストを更新する
 3. 全概要設計の修正完了後、ユーザーに確認・承認を得る
 
@@ -73,10 +73,11 @@ MVP では `docs/02_概要設計/90_ADR/` に集約する。
 
 ## Phase 5: 詳細設計の修正
 
-1. `docs/03_詳細設計/src/**` を `src/` ミラーで修正する
-2. 補助設計が必要な場合だけ `docs/03_詳細設計/infrastructure/**` を修正する
-3. frontmatter の `depends_on` / `maps_to` を更新する
-4. ユーザーに最終確認を得る
+1. `docs/03_詳細設計/01_ドメイン/**` のドメイン設計を修正する
+2. `docs/03_詳細設計/02_ユースケース/**` の UC 設計を修正する
+3. DB・外部サービスの変更がある場合は `docs/03_詳細設計/03_DB・外部サービス/**` を修正する
+4. frontmatter の `depends_on` / `maps_to` を更新する
+5. ユーザーに最終確認を得る
 
 ## Phase 6: TDD → 実装 → 検証
 

package/spec-runner/templates/.github/skills/design-change/templates/90_ADR/ADR/343/203/206/343/203/263/343/203/227/343/203/254/343/203/274/343/203/210.md

@@ -7,7 +7,7 @@ spec_runner:
   maps_to: []
 ---
 
-# ADR-0001 {決定内容のタイトル}
+# {決定内容のタイトル}
 
 **ステータス**: 提案 / 採用 / 廃止 / 置換
 **日付**: YYYY-MM-DD

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

@@ -0,0 +1,140 @@
+---
+name: docs-driven-seed
+description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジェクトの初期テンプレートとして使い、architecture-skill-development でプロジェクト専用スキルに育てる。
+---
+
+# docs-driven-seed
+
+UC/DDD 駆動の docs 正本開発フローの**参照実装（種）**。
+プロジェクト固有のスキルに育てる前の出発点として使う。
+
+**このスキルをそのまま使い続けない。`architecture-skill-development` で自プロジェクト専用スキルに育てることを前提とする。**
+
+## 全体フロー
+
+```
+Phase 1: 要件定義
+Phase 2: 概要設計（ユースケース + ドメインモデル）
+Phase 3: ADR（必要時のみ）
+Phase 4: 詳細設計（ドメイン → UC → DB・外部サービス）
+Phase 5: TDD → 実装
+```
+
+## 前提ルール
+
+- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- 詳細設計は `01_ドメイン/` `02_ユースケース/` `03_DB・外部サービス/` の 3 層で構成する
+- UC がドメインを使う。ドメインの中に UC は入れない
+- `maps_to` は必ず設定する。パス推定に頼らない
+- ユーザー承認なしに次フェーズへ進めない
+
+## Phase 1: 要件定義
+
+1. 以下をユーザーにヒアリングする
+   - 解決すべき課題・提供価値
+   - 対象ユーザー
+   - 非機能要件・スコープ外
+   - 技術・ビジネス制約
+2. `docs/01_要件定義/要件定義.md` を作る
+3. ドメイン用語が出てきたら `docs/01_要件定義/ユビキタス言語辞書.md` に随時追記する
+4. ユーザーに確認・承認を得る
+
+### 出力
+
+```
+docs/01_要件定義/
+  要件定義.md
+  ユビキタス言語辞書.md
+```
+
+## Phase 2: 概要設計
+
+### 2-1. ユースケース一覧
+
+1. 要件定義からユースケースを洗い出す（Query / Command を意識）
+2. `docs/02_概要設計/ユースケース一覧.md` を作る
+3. ユーザーに確認・承認を得る
+
+### 2-2. ドメインモデル + システム全体俯瞰
+
+1. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を作る
+2. コンポーネント全体図・外部 IF を整理し `docs/02_概要設計/システム全体俯瞰.md` を作る
+3. ユーザーに確認・承認を得る
+
+### 出力
+
+```
+docs/02_概要設計/
+  ユースケース一覧.md
+  ドメインモデル.md
+  システム全体俯瞰.md
+  90_ADR/
+    全体/
+    ドメイン/
+    UC/
+    DB/
+```
+
+## Phase 3: ADR（必要時のみ）
+
+1. 設計判断が必要な場合だけ ADR を作る
+2. **必ず 3 案を比較する**
+3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
+
+| 対象 | 配置先 |
+|------|--------|
+| システム横断の決定 | `90_ADR/全体/` |
+| ドメイン設計の決定 | `90_ADR/ドメイン/` |
+| UC フローの決定 | `90_ADR/UC/` |
+| DB・外部サービスの決定 | `90_ADR/DB/` |
+
+4. 採用案を概要設計へ反映してから次へ進む
+
+## Phase 4: 詳細設計
+
+**ドメイン → UC → DB・外部サービス の順に設計する。**
+
+### 4-1. ドメイン
+
+テンプレート: `templates/03_詳細設計/01_ドメイン/{ドメイン名}.md`
+
+```
+docs/03_詳細設計/01_ドメイン/
+  {ドメイン名}.md
+```
+
+### 4-2. ユースケース
+
+シーケンス図は UC ファイルに Mermaid で埋め込む。
+
+テンプレート: `templates/03_詳細設計/02_ユースケース/UC-{日本語名}.md`
+
+```
+docs/03_詳細設計/02_ユースケース/
+  UC-{日本語名}.md
+```
+
+### 4-3. DB・外部サービス（必要時のみ）
+
+```
+docs/03_詳細設計/03_DB・外部サービス/
+  スキーマ定義.dbml
+  外部サービス.md
+```
+
+ユーザーに確認・承認を得る
+
+## Phase 5: TDD → 実装
+
+`test-driven-development` スキルへ移行する。
+
+### 実装完了後
+
+- `@design-reviewer` — 設計書⇔実装の整合性チェック
+- `@code-reviewer` — コーディング規約への適合チェック
+
+## 原則
+
+- **このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てることを前提とする**
+- **ドメインを先に設計し、UC はドメインを参照する形で書く**
+- **`maps_to` は必ず設定する。パス推定に頼らない**

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/01_/343/203/211/343/203/241/343/202/244/343/203/263/{/343/203/211/343/203/241/343/202/244/343/203/263/345/220/215}.md

@@ -0,0 +1,39 @@
+---
+spec_runner:
+  node_id: detail.domain.{ドメイン名}
+  kind: detailed_design
+  depends_on:
+    - overview.domain_model
+  maps_to:
+    - src/domain/{ドメイン名}/
+---
+
+# {ドメイン名} ドメイン詳細設計
+
+## 責務
+
+- {このドメインが扱うビジネス概念}
+- {このドメインの不変条件・制約}
+
+## 集約
+
+| 集約 | 責務 | ルートエンティティ |
+|------|------|----------------|
+| {集約名} | {責務} | {ルートエンティティ名} |
+
+## 値オブジェクト
+
+| 値オブジェクト | 制約・ルール |
+|--------------|------------|
+| {名前} | {制約} |
+
+## ドメインルール
+
+- {ルール1}
+- {ルール2}
+
+## テスト観点
+
+- {正常系の観点}
+- {ルール違反の観点}
+- {境界条件の観点}

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

@@ -0,0 +1,55 @@
+---
+spec_runner:
+  node_id: detail.usecase.{UC名}
+  kind: detailed_design
+  depends_on:
+    - overview.use_case_list
+    - detail.domain.{ドメイン名}
+  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/existing-project-to-docs/SKILL.md

@@ -27,22 +27,25 @@ Phase 5: architecture contract 化
 
 ## Phase 2: 要件とユースケースの抽出
 
-1. 既存機能からユースケースを逆算する
+1. `current-system-inventory.md` を起点に、既存機能からユースケースを逆算する
 2. `docs/01_要件定義/要件定義.md` と `docs/02_概要設計/ユースケース一覧.md` の draft を作る
-3. ユーザーに確認・承認を得る
+3. ドメイン用語が識別できたら `docs/01_要件定義/ユビキタス言語辞書.md` も draft する
+4. ユーザーに確認・承認を得る
 
 ## Phase 3: 概要設計の draft 化
 
-1. `docs/02_概要設計/システム全体俯瞰.md` を作る
-2. 必要なら ADR 候補も洗い出す
-3. ユーザーに確認・承認を得る
+1. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を draft する
+2. `docs/02_概要設計/システム全体俯瞰.md` を作る
+3. 必要なら ADR 候補も洗い出す（配置先は `90_ADR/全体/` / `ドメイン/` / `UC/` / `DB/`）
+4. ユーザーに確認・承認を得る
 
 ## Phase 4: 詳細設計の draft 化
 
-1. `docs/03_詳細設計/src/**` を `src/` ミラーで作る
-2. `maps_to` に対応コードとテストを入れる
-3. 補助設計が必要なら `docs/03_詳細設計/infrastructure/**` を作る
-4. ユーザーに確認・承認を得る
+1. ドメインごとにビジネスルール・集約を整理し `docs/03_詳細設計/01_ドメイン/{ドメイン名}.md` を draft する
+2. UC ごとに `docs/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を draft する
+3. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/03_DB・外部サービス/` を作る
+4. 各ファイルの `maps_to` に対応コードとテストを入れる
+5. ユーザーに確認・承認を得る
 
 ## Phase 5: architecture contract 化
 

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

@@ -68,6 +68,8 @@ Phase 4: 影響範囲の反映確認
 
 ## Phase 3: skill / rule / agent / template の修正
 
+ファイルを作成・修正する前に **`.github/instructions/harness-formats.instructions.md`** を読み、フォーマットを確認する。
+
 1. 対象ファイルを特定する
 2. 意図が変わらない最小差分で修正する
 3. 片系だけでなく、対応するテンプレートも揃えて更新する
@@ -90,6 +92,9 @@ Phase 4: 影響範囲の反映確認
 - 関連する skill / rule / agent / template の記述が矛盾していないか
 - Claude / Copilot の対応ファイルに反映漏れがないか
 - 今回限りのノイズをルール化していないか
+- skill 名・起動条件・使いどころを変更した場合、`CLAUDE.md` の記述と一致しているか
+- `CLAUDE.md` が肥大化していないか（20行超えたら `instructions/` や `skills/` へ移動を検討する）
+- docs 構造・命名規則・node_id 体系に影響する変更の場合、`design-docs.instructions.md` と整合しているか
 
 ## 原則