spec-runner 1.1.13 → 1.1.17

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

@@ -15,14 +15,13 @@ Phase 1: 入力の確認
 Phase 2: 反復フローの抽出
 Phase 3: skill / rule / template へ分解
 Phase 4: 基盤 skill のプロジェクト固有化
-Phase 5: Claude / Copilot テンプレートへ反映
-Phase 6: 一貫性の検証
-Phase 7: セットアップ専用 skill のアーカイブ提案
+Phase 5: 一貫性の検証
+Phase 6: セットアップ専用 skill のアーカイブ提案
 ```
 
 ## Phase 1: 入力の確認
 
-1. `docs/01_要件定義/**`, `docs/02_概要設計/**`, `docs/03_詳細設計/**` を読む
+1. `docs/01_要件定義/**` を読む
 2. `.spec-runner/architecture/architecture.yaml` を読む
 3. 固定化すべき判断と project 固有判断を切り分ける
 
@@ -35,22 +34,30 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 
 ## Phase 3: skill / rule / template へ分解
 
+ファイルを作成する前に **`.github/instructions/harness-formats.instructions.md`** を読み、フォーマットを確認する。
+
 1. 会話フローは skill にする
 2. 常時守る約束は rule にする
 3. 毎回コピーする設計書は template にする
 
-### plugin-development を種として使う
+### seed の選択
+
+`architecture.yaml` の `style` を読み、使う seed を決める。
+
+| style | 使う seed | 説明 |
+|-------|----------|------|
+| `ddd` | `docs-driven-seed` | ドメイン層（集約・値オブジェクト）を持つ DDD 向けフロー |
+| `layered` | `simple-seed` | ドメイン層を持たない UC・サービス層中心のフロー |
 
-新規開発フローの skill を作る場合は、`plugin-development` を種として使う。
-`plugin-development` はプラグイン型アーキテクチャ向けの reference workflow であり、
-そのまま使うのではなく、**このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作る**ことを目的とする。
+選んだ seed の SKILL.md をコピーして、**このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作る**ことを目的とする。
 
 具体的には:
-- `.claude/skills/plugin-development/SKILL.md` をコピーして、project 専用の開発 skill の土台にする
+- 選んだ seed の SKILL.md をコピーして、project 専用の開発 skill の土台にする
 - フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換える
-- 元の `plugin-development` は書き換え完了後にアーカイブ候補とする（Phase 7 で提案する）
+- **Phase 1（要件定義）は architecture-definition で完了済みのため削除する**
+- 元の seed は書き換え完了後にアーカイブ候補とする（Phase 6 で提案する）
 
-ユーザーに確認・承認を得る
+4. ユーザーに確認・承認を得る
 
 ## Phase 4: 基盤 skill のプロジェクト固有化
 
@@ -86,19 +93,14 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 
 同様のプレースホルダーや汎用記述が他の skill にあれば、同じ要領で書き換える。
 
-ユーザーに確認・承認を得る
-
-## Phase 5: Claude / Copilot テンプレートへ反映
-
-1. `.claude/` と `.github/` の両方へ反映する
-2. path や naming がずれないよう対応ファイルを揃える
+5. ユーザーに確認・承認を得る
 
-## Phase 6: 一貫性の検証
+## Phase 5: 一貫性の検証
 
 1. 既存 skill / rule / agent と矛盾しないか確認する
 2. `harness-engineering` が必要な改善点を洗い出す
 
-## Phase 7: セットアップ専用 skill のアーカイブ提案
+## Phase 6: セットアップ専用 skill のアーカイブ提案
 
 セットアップ時にしか使わない skill は、開発ループに入ると不要になる。
 **ユーザーの承認を得てから** 整理する。絶対に自動で削除・移動しない。
@@ -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,7 +119,10 @@ Phase 7: セットアップ専用 skill のアーカイブ提案
 1. 上記の候補をユーザーに提示し、整理してよいか確認する
 2. 承認を得た skill を `.claude/skills/` と `.github/skills/` から削除する
 3. 必要であれば削除前にバックアップ先をユーザーに伝える
-4. `CLAUDE.md` を更新する
+4. `.spec-runner/` の不要ファイルも整理する
+   - `intake/current-system-inventory.md` — docs に昇格済みなら削除してよい
+   - `architecture/architecture.yaml` — project 専用 skill が完成し、参照不要になったら削除してよい
+5. `CLAUDE.md` を更新する
    - 「初回自動起動」セクション（spec-runner インストール時に生成されたもの）を削除する
    - 作成した project 専用 skill の名前と使いどころを記載する
    - 例:

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

@@ -41,16 +41,17 @@ Phase 6: TDD → 実装 → 検証
 3. 各案について概要・メリット・デメリット・適合性を示す
 4. ユーザーが案を決定する
 5. テンプレート `templates/90_ADR/ADRテンプレート.md` をコピーして生成する
-6. ファイル名は `mmdd-{日本語タイトル}.md` 形式にする（例: `0404-キャッシュ戦略の変更.md`）
+6. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
+7. ユーザーに確認・承認を得る
 
 ### 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 +63,7 @@ MVP では `docs/02_概要設計/90_ADR/` に集約する。
 
 ## Phase 4: 概要設計の修正
 
-1. `ユースケース一覧.md` / `システム全体俯瞰.md` / UC 個別文書 / ADR を必要順に修正する
+1. `ユースケース一覧.md` / `システム全体俯瞰.md` / `ドメインモデル.md` / ADR を必要順に修正する
 2. 修正完了ごとにチェックリストを更新する
 3. 全概要設計の修正完了後、ユーザーに確認・承認を得る
 
@@ -73,10 +74,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

@@ -2,9 +2,6 @@
 spec_runner:
   node_id: adr.{decision_slug}
   kind: adr
-  depends_on:
-    - overview.system_context
-  maps_to: []
 ---
 
 # {決定内容のタイトル}
@@ -21,35 +18,6 @@ spec_runner:
 | 要件 | {実現する必要があること} |
 | 制約 | {技術的・ビジネス的制約} |
 
-## 選択肢
-
-### 案1: {案1の名前}
-
-- 概要: {何をするか}
-- メリット:
-  - {メリット}
-- デメリット:
-  - {デメリット}
-- 適合性: {このプロジェクトにどう合うか}
-
-### 案2: {案2の名前}
-
-- 概要: {何をするか}
-- メリット:
-  - {メリット}
-- デメリット:
-  - {デメリット}
-- 適合性: {このプロジェクトにどう合うか}
-
-### 案3: {案3の名前}
-
-- 概要: {何をするか}
-- メリット:
-  - {メリット}
-- デメリット:
-  - {デメリット}
-- 適合性: {このプロジェクトにどう合うか}
-
 ## 決定
 
 **採用案**: {案名}

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

@@ -0,0 +1,127 @@
+---
+name: docs-driven-seed
+description: UC/DDD 駆動の docs 正本開発フローの種。新規プロジェクトの初期テンプレートとして使い、architecture-skill-development でプロジェクト専用スキルに育てる。
+---
+
+# docs-driven-seed
+
+**DDD（ドメイン駆動設計）を採用するプロジェクト向け**の docs 正本開発フロー参照実装（種）。
+`architecture.yaml` の `style: ddd` のときに使う。レイヤード / CRUD 中心のプロジェクトは `simple-seed` を使う。
+
+**このスキルをそのまま使い続けない。`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: 要件定義
+
+`architecture-definition` で完了済み。`docs/01_要件定義/` が存在することを確認して次へ進む。
+
+## 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. ユーザーに確認・承認を得る
+
+### 出力
+
+テンプレート: `templates/02_概要設計/ユースケース一覧.md` / `templates/02_概要設計/ドメインモデル.md` / `templates/02_概要設計/システム全体俯瞰.md`
+
+```
+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
+```
+
+4. ユーザーに確認・承認を得る
+
+## 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/01_/350/246/201/344/273/266/345/256/232/347/276/251//343/203/246/343/203/223/343/202/255/343/202/277/343/202/271/350/250/200/350/252/236/350/276/236/346/233/270.md

@@ -0,0 +1,15 @@
+---
+spec_runner:
+  node_id: requirement.ユビキタス言語辞書
+  kind: requirement
+  depends_on:
+    - requirement.要件定義
+  maps_to:
+    - docs/03_詳細設計/01_ドメイン/
+---
+
+# ユビキタス言語辞書
+
+| 用語 | 定義 | 補足 |
+|------|------|------|
+| {用語} | {定義} | {補足} |

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/01_/350/246/201/344/273/266/345/256/232/347/276/251//350/246/201/344/273/266/345/256/232/347/276/251.md

@@ -0,0 +1,34 @@
+---
+spec_runner:
+  node_id: requirement.要件定義
+  kind: requirement
+  depends_on: []
+  maps_to:
+    - docs/02_概要設計/
+---
+
+# 要件定義
+
+## 解決すべき課題・提供価値
+
+- {課題}
+- {提供価値}
+
+## 対象ユーザー
+
+- {ユーザー種別}: {説明}
+
+## 非機能要件
+
+| 項目 | 内容 |
+|------|------|
+| {パフォーマンス} | {要件} |
+| {セキュリティ} | {要件} |
+
+## スコープ外
+
+- {スコープ外の機能・要件}
+
+## 技術・ビジネス制約
+
+- {制約}

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/202/267/343/202/271/343/203/206/343/203/240/345/205/250/344/275/223/344/277/257/347/236/260.md

@@ -0,0 +1,33 @@
+---
+spec_runner:
+  node_id: overview.system_context
+  kind: overview_design
+  depends_on:
+    - overview.domain_model
+  maps_to:
+    - src/
+---
+
+# システム全体俯瞰
+
+## コンポーネント全体図
+
+```mermaid
+graph LR
+  User([ユーザー])
+  subgraph システム
+    {フロントエンド}
+    {バックエンド}
+  end
+  Ext([{外部サービス}])
+
+  User --> {フロントエンド}
+  {フロントエンド} --> {バックエンド}
+  {バックエンド} --> Ext
+```
+
+## 外部インターフェース
+
+| 外部システム | 方向 | プロトコル | 概要 |
+|------------|------|----------|------|
+| {外部システム名} | 受信 / 送信 | {HTTP / gRPC など} | {概要} |

package/spec-runner/templates/.github/skills/docs-driven-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/203/211/343/203/241/343/202/244/343/203/263/343/203/242/343/203/207/343/203/253.md

@@ -0,0 +1,32 @@
+---
+spec_runner:
+  node_id: overview.domain_model
+  kind: overview_design
+  depends_on:
+    - overview.use_case_list
+  maps_to:
+    - docs/03_詳細設計/01_ドメイン/
+---
+
+# ドメインモデル
+
+集約と境界コンテキストの概念モデル。DBスキーマ・永続化の詳細はここに書かない。
+
+## 境界コンテキスト
+
+```mermaid
+graph LR
+  subgraph {コンテキストA}
+    {集約A}
+  end
+  subgraph {コンテキストB}
+    {集約B}
+  end
+  {コンテキストA} -->|下流| {コンテキストB}
+```
+
+## 集約一覧
+
+| 境界コンテキスト | 集約 | 責務 |
+|----------------|------|------|
+| {コンテキスト名} | {集約名} | {責務} |

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

@@ -0,0 +1,15 @@
+---
+spec_runner:
+  node_id: overview.use_case_list
+  kind: overview_design
+  depends_on:
+    - requirement.要件定義
+  maps_to:
+    - docs/03_詳細設計/02_ユースケース/
+---
+
+# ユースケース一覧
+
+| UC ID | UC名 | 種別 | 概要 |
+|-------|------|------|------|
+| UC-{番号} | {UC名} | Command / Query | {概要} |

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,56 @@
+---
+spec_runner:
+  node_id: detail.domain.{ドメイン名}
+  kind: detailed_design
+  depends_on:
+    - overview.domain_model
+  maps_to:
+    - src/domain/{ドメイン名}/
+---
+
+# {ドメイン名} ドメイン詳細設計
+
+## 責務
+
+- {このドメインが扱うビジネス概念}
+- {このドメインの不変条件・制約}
+
+## 集約
+
+```mermaid
+classDiagram
+  class {集約ルート} {
+    +{ID型} id
+    +{値オブジェクト} {フィールド名}
+    +{操作}() {戻り値型}
+  }
+  class {エンティティ} {
+    +{ID型} id
+  }
+  class {値オブジェクト} {
+    +{型} {フィールド名}
+  }
+  {集約ルート} "1" --> "0..*" {エンティティ} : 含む
+  {集約ルート} --> {値オブジェクト} : 持つ
+```
+
+| 集約 | 責務 | ルートエンティティ |
+|------|------|----------------|
+| {集約名} | {責務} | {ルートエンティティ名} |
+
+## 値オブジェクト
+
+| 値オブジェクト | 制約・ルール |
+|--------------|------------|
+| {名前} | {制約} |
+
+## ドメインルール
+
+- {ルール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. 片系だけでなく、対応するテンプレートも揃えて更新する
@@ -91,6 +93,8 @@ Phase 4: 影響範囲の反映確認
 - Claude / Copilot の対応ファイルに反映漏れがないか
 - 今回限りのノイズをルール化していないか
 - skill 名・起動条件・使いどころを変更した場合、`CLAUDE.md` の記述と一致しているか
+- `CLAUDE.md` が肥大化していないか（20行超えたら `instructions/` や `skills/` へ移動を検討する）
+- docs 構造・命名規則・node_id 体系に影響する変更の場合、`design-docs.instructions.md` と整合しているか
 
 ## 原則