spec-runner 1.1.7 → 1.1.8

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

@@ -0,0 +1,126 @@
+---
+name: architecture-skill-development
+description: architecture contract と docs を読み、プロジェクト専用の skill / rule / template を育てるフロー。
+---
+
+# architecture-skill-development
+
+`architecture-definition` または `existing-project-to-docs` の後に使う。
+決まったアーキテクチャから、そのプロジェクト専用の skill / rule / template を作る。
+
+## 全体フロー
+
+```
+Phase 1: 入力の確認
+Phase 2: 反復フローの抽出
+Phase 3: skill / rule / template へ分解
+Phase 4: 基盤 skill のプロジェクト固有化
+Phase 5: Claude / Copilot テンプレートへ反映
+Phase 6: 一貫性の検証
+Phase 7: セットアップ専用 skill のアーカイブ提案
+```
+
+## Phase 1: 入力の確認
+
+1. `docs/01_要件定義/**`, `docs/02_概要設計/**`, `docs/03_詳細設計/**` を読む
+2. `.spec-runner/architecture/architecture.yaml` を読む
+3. 固定化すべき判断と project 固有判断を切り分ける
+
+## Phase 2: 反復フローの抽出
+
+1. よく繰り返す作業を抽出する
+2. どこにユーザー承認が必要かを決める
+3. 影響調査や TDD など共通 skill をどうつなぐか決める
+4. ユーザーに確認・承認を得る
+
+## Phase 3: skill / rule / template へ分解
+
+1. 会話フローは skill にする
+2. 常時守る約束は rule にする
+3. 毎回コピーする設計書は template にする
+
+### plugin-development を種として使う
+
+新規開発フローの skill を作る場合は、`plugin-development` を種として使う。
+`plugin-development` はプラグイン型アーキテクチャ向けの reference workflow であり、
+そのまま使うのではなく、**このプロジェクトのアーキテクチャに合わせて書き換えた project 専用 skill を作る**ことを目的とする。
+
+具体的には:
+- `.claude/skills/plugin-development/SKILL.md` をコピーして、project 専用の開発 skill の土台にする
+- フェーズ構成・テンプレートパス・用語をこのプロジェクトの実態に合わせて書き換える
+- 元の `plugin-development` は書き換え完了後にアーカイブ候補とする（Phase 7 で提案する）
+
+ユーザーに確認・承認を得る
+
+## Phase 4: 基盤 skill のプロジェクト固有化
+
+インストール時に配布された基盤 skill のプレースホルダーを、このプロジェクトの実態に書き換える。
+
+### test-driven-development の書き換え
+
+`architecture.yaml` の `testing_policy` と `language` を参照して、以下を実際の値に置き換える。
+
+1. **テスト実行コマンド** — `<your-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. **コード例** — 言語・フレームワークに合わせて RED / GREEN の例を書き直す
+
+3. **fixture / テストデータ** — このプロジェクトの実際のクラス名・DB 接続方法・ヘルパ関数パターンを記述する
+
+4. **モックのルール** — 使用する外部サービスとモック手段（ライブラリ名など）を具体化する
+
+書き換えは `.claude/skills/test-driven-development/SKILL.md` と `.github/skills/test-driven-development/SKILL.md` の両方に反映する。
+
+### その他の基盤 skill
+
+同様のプレースホルダーや汎用記述が他の skill にあれば、同じ要領で書き換える。
+
+ユーザーに確認・承認を得る
+
+## Phase 5: Claude / Copilot テンプレートへ反映
+
+1. `.claude/` と `.github/` の両方へ反映する
+2. path や naming がずれないよう対応ファイルを揃える
+
+## Phase 6: 一貫性の検証
+
+1. 既存 skill / rule / agent と矛盾しないか確認する
+2. `harness-engineering` が必要な改善点を洗い出す
+
+## Phase 7: セットアップ専用 skill のアーカイブ提案
+
+セットアップ時にしか使わない skill は、開発ループに入ると不要になる。
+**ユーザーの承認を得てから** 整理する。絶対に自動で削除・移動しない。
+
+### アーカイブ候補
+
+| skill | 理由 |
+|---|---|
+| `architecture-definition` | 新規プロジェクト初期化専用。アーキテクチャ確定後は不要 |
+| `existing-project-to-docs` | 既存プロジェクト取り込み専用。docs 生成後は不要 |
+| `plugin-development` | Phase 3 で project 専用 skill の種として使い終えたら不要 |
+| `architecture-skill-development`（このファイル自身） | project 専用 skill が安定したら不要。ただしアーキテクチャが大きく変わる場合は再利用する可能性があるため、削除ではなくアーカイブを推奨 |
+
+### 手順
+
+1. 上記の候補をユーザーに提示し、整理してよいか確認する
+2. 承認を得た skill を `.claude/skills/` と `.github/skills/` から削除する
+3. 必要であれば削除前にバックアップ先をユーザーに伝える
+
+## 原則
+
+- 固定の architecture pack を増やしすぎない
+- project 専用 skill を先に考える
+- docs と architecture contract の両方を入力にする
+- **skill の削除・移動はユーザー承認なしに行わない**

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

@@ -0,0 +1,83 @@
+---
+name: commit
+description: 変更を Conventional Commits 形式でコミットする。
+---
+
+# commit
+
+変更を Conventional Commits 形式でコミットする。
+
+## 手順
+
+1. `git status` と `git diff --cached`（ステージ済み）または `git diff`（未ステージ）で変更内容を確認する
+2. `git log --oneline -10` で直近のコミット履歴を確認する
+3. 変更内容に基づいてコミットメッセージを生成する
+4. 未ステージの場合は適切なファイルを `git add` する
+5. **機密情報チェック**: `git diff --cached` の内容を確認し、以下のパターンが含まれていないか検査する
+   - API キー、シークレットキー、パスワード、トークン、秘密鍵、接続文字列
+   - `.env` ファイルの内容、認証情報ファイル（`credentials.json` 等）
+   - 検出した場合はコミットを中止し、ユーザーに報告する
+6. コミットを実行する
+
+## コミットメッセージ形式
+
+```
+<type>: <summary>
+
+<body（任意）>
+```
+
+### type（必須）
+
+| type | 用途 |
+|------|------|
+| `feat` | 新機能・新規ファイル追加 |
+| `fix` | バグ修正 |
+| `docs` | ドキュメントのみの変更 |
+| `refactor` | リファクタリング（機能変更なし） |
+| `test` | テストの追加・修正 |
+| `chore` | ビルド・設定・CI 等の変更 |
+| `style` | フォーマット・命名変更（動作変更なし） |
+
+### summary（必須）
+
+- 日本語で書く
+- 末尾に句点（。）をつけない
+- 命令形ではなく体言止め or 「〜を追加」「〜を修正」形式
+- 50 文字以内を目安
+
+### body（任意）
+
+- 変更が大きい場合のみ記載
+- 「なぜ」この変更をしたかを書く（「何を」は diff で分かる）
+- チーム運用で必要な場合のみ `Co-Authored-By` を追加する
+
+## 例
+
+```
+feat: 突合チェックエージェントを追加
+```
+
+```
+docs: 要件定義・概要設計を追加
+```
+
+```
+chore: Docker 構成を追加
+```
+
+```
+feat: スキル 4 種とツール 3 種を追加
+
+売掛金・役員報酬・汎用残高・租税公課チェックスキル、
+科目別集計・仕訳検索・3 ソース比較ツール
+```
+
+```
+fix: 科目名正規化で建設業科目が漏れていた問題を修正
+```
+
+## 原則
+
+- `git add .` や `git add -A` は使わない（ファイル名を明示する）
+- 1 コミットに複数の論理的変更を混ぜない

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

@@ -0,0 +1,94 @@
+---
+name: design-change
+description: 既存機能の変更を docs 正本で進めるフローガイド。軽い影響調査、ADR、概要設計、詳細設計、TDD を順に進める。
+---
+
+# design-change
+
+既存機能の変更・修正を設計書駆動で進めるフローガイド。
+**フェーズを必ず順番通りに進める。ユーザーの承認なしにフェーズを先に進めない。**
+
+影響範囲のチェックリストは `references/影響範囲チェックリスト.md` を参照する。
+ADR テンプレートは `templates/90_ADR/ADRテンプレート.md` を使用する。
+
+## 全体フロー
+
+```
+Phase 1: 変更要求の整理と軽い影響調査
+Phase 2: ADR 作成（必要時）
+Phase 3: 影響ドキュメントの確定
+Phase 4: 概要設計の修正
+Phase 5: 詳細設計の修正
+Phase 6: TDD → 実装 → 検証
+```
+
+## Phase 1: 変更要求の整理と軽い影響調査
+
+1. 以下をユーザーにヒアリングする
+   - 変更の背景・課題
+   - 変更の目的・期待する結果
+   - 影響を受ける機能カテゴリ
+   - 技術的・ビジネス的制約
+2. 変更起点となる docs を特定する
+3. frontmatter の `depends_on` / `maps_to` を使って影響候補を軽く洗う
+4. 変更が影響するドメインと成果物を一覧化する
+5. ユーザーに確認・承認を得る
+
+## Phase 2: ADR 作成（必要時）
+
+1. アーキテクチャ、責務境界、保存方式、外部 IF などの意思決定が必要か判定する
+2. 必要な場合は **3 案を提示する**
+3. 各案について概要・メリット・デメリット・適合性を示す
+4. ユーザーが案を決定する
+5. テンプレート `templates/90_ADR/ADRテンプレート.md` をコピーして生成する
+6. ファイル名は `ADR-0001-{slug}.md` 形式にする
+
+### ADR 配置ルール
+
+| 変更スコープ | 配置先 |
+|------------|--------|
+| 横断的な決定 | `docs/02_概要設計/90_ADR/` |
+| 特定ドメイン寄りの決定 | `docs/02_概要設計/<ドメイン>/90_ADR/` |
+
+MVP では `docs/02_概要設計/90_ADR/` に集約する。
+
+## Phase 3: 影響ドキュメントの確定
+
+1. `references/影響範囲チェックリスト.md` を読み、変更に応じた影響ドキュメントを網羅的に洗い出す
+2. frontmatter の `depends_on` / `maps_to` を使って候補を絞る
+3. 修正が必要なファイルをチェックリスト形式で提示する
+4. `@design-reviewer` エージェントに委任して、現時点の設計書⇔実装の乖離も合わせて確認する
+5. ユーザーに確認・承認を得る
+
+## Phase 4: 概要設計の修正
+
+1. `ユースケース一覧.md` / `システム全体俯瞰.md` / UC 個別文書 / ADR を必要順に修正する
+2. 修正完了ごとにチェックリストを更新する
+3. 全概要設計の修正完了後、ユーザーに確認・承認を得る
+
+### 修正時の注意
+
+- 変更理由は ADR または本文で追えるようにする
+- 概要設計では「何をするか」に留める
+
+## Phase 5: 詳細設計の修正
+
+1. `docs/03_詳細設計/src/**` を `src/` ミラーで修正する
+2. 補助設計が必要な場合だけ `docs/03_詳細設計/infrastructure/**` を修正する
+3. frontmatter の `depends_on` / `maps_to` を更新する
+4. ユーザーに最終確認を得る
+
+## 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

@@ -0,0 +1,66 @@
+# 影響範囲チェックリスト
+
+design-change の Phase 3（影響ドキュメントの特定）で参照する。
+変更の種類に応じて、修正が必要なドキュメントを網羅的に特定する。
+
+## 変更種別ごとのチェック項目
+
+### エージェントの追加・変更・削除
+
+| ドキュメント | パス | チェック |
+|------------|------|------|
+| ユースケース一覧 | `docs/02_概要設計/ユースケース一覧.md` | エージェントが担当する UC の追加・修正・削除を反映 |
+| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | エージェント構成・責務分割への影響 |
+| エージェント設計 | `docs/03_詳細設計/src/agents/{agent_name}/agent.md` | オーケストレーション、利用プラグイン、I/O の変更 |
+| ドメイン設計 | `docs/03_詳細設計/src/agents/{agent_name}/domain.md` | エンティティ・値オブジェクト・不変条件の変更 |
+| プロンプト設計 | `docs/03_詳細設計/src/agents/{agent_name}/prompts.md` | プロンプト構成・指示内容の変更 |
+| 設定 | `docs/03_詳細設計/src/agents/{agent_name}/config.md` | 設定パラメータ・閾値の変更 |
+
+### ドメインモデル（エンティティ・値オブジェクト）の変更
+
+| ドキュメント | パス | チェック |
+|------------|------|------|
+| ドメイン設計 | `docs/03_詳細設計/src/agents/{agent_name}/domain.md` | フィールド・ルール・不変条件の変更 |
+| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | 責務境界や共有概念への影響 |
+| プロンプト設計 | `docs/03_詳細設計/src/agents/{agent_name}/prompts.md` | ドメイン変更がプロンプトに影響する場合 |
+| データベース設計 | `docs/03_詳細設計/infrastructure/database.md` | テーブル構造・保存方針への影響 |
+| スキーマ定義 | `docs/03_詳細設計/infrastructure/schema.dbml` | カラム・型・制約の変更 |
+| スキル設計 | `docs/03_詳細設計/src/plugins/skills/{skill_name}/skill.md` | スキルの入出力・判定ロジックへの影響 |
+| ツール設計 | `docs/03_詳細設計/src/plugins/tools/{tool_name}/tool.md` | ツールの入出力への影響 |
+
+### プラグイン（スキル・ツール）の追加・変更・削除
+
+| ドキュメント | パス | チェック |
+|------------|------|------|
+| スキル設計 | `docs/03_詳細設計/src/plugins/skills/{skill_name}/skill.md` | スキルの追加・修正・削除 |
+| ツール設計 | `docs/03_詳細設計/src/plugins/tools/{tool_name}/tool.md` | ツールの追加・修正・削除 |
+| エージェント設計 | `docs/03_詳細設計/src/agents/{agent_name}/agent.md` | 利用プラグイン一覧と呼び出し順の更新 |
+| ユースケース一覧 | `docs/02_概要設計/ユースケース一覧.md` | 対応する UC がある場合 |
+| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | プラグイン構成の変更が全体構造に影響する場合 |
+
+### データベーススキーマの変更
+
+| ドキュメント | パス | チェック |
+|------------|------|------|
+| データベース設計 | `docs/03_詳細設計/infrastructure/database.md` | テーブル定義・インデックス・リレーション |
+| スキーマ定義 | `docs/03_詳細設計/infrastructure/schema.dbml` | dbml ファイルの更新 |
+| ドメイン設計 | `docs/03_詳細設計/src/agents/{agent_name}/domain.md` | ドメインモデルへの影響 |
+| エージェント設計 | `docs/03_詳細設計/src/agents/{agent_name}/agent.md` | 保存フローやトランザクションへの影響 |
+
+### アーキテクチャ・設計方針の変更
+
+| ドキュメント | パス | チェック |
+|------------|------|------|
+| ADR | `docs/02_概要設計/90_ADR/` | 横断的な決定 |
+| ADR（ドメインローカル） | `docs/02_概要設計/<ドメイン>/90_ADR/` | 特定ドメインの決定 |
+| システム全体俯瞰 | `docs/02_概要設計/システム全体俯瞰.md` | 技術方針・全体構成の変更 |
+| 要件定義 | `docs/01_要件定義/要件定義.md` | 要件レベルの変更がある場合 |
+| 詳細設計一式 | `docs/03_詳細設計/src/**` | 方針変更の具体反映 |
+
+## 二次影響の確認観点
+
+- **ユースケース一覧 ↔ エージェント設計**: 一覧に記載の UC がエージェントとプラグインでカバーされているか
+- **システム全体俯瞰 ↔ 詳細設計**: 責務分割が `docs/03_詳細設計/src/**` に落ちているか
+- **ドメイン設計 ↔ DBスキーマ**: ドメインのフィールドが DB カラムと対応しているか
+- **schema.dbml ↔ database.md**: dbml と設計書の内容が一致しているか
+- **frontmatter ↔ 実ファイル**: `depends_on` と `maps_to` が現状に追随しているか

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

@@ -0,0 +1,81 @@
+---
+spec_runner:
+  node_id: adr.{decision_slug}
+  kind: adr
+  depends_on:
+    - overview.system_context
+  maps_to: []
+---
+
+# ADR-0001 {決定内容のタイトル}
+
+**ステータス**: 提案 / 採用 / 廃止 / 置換
+**日付**: YYYY-MM-DD
+**決定者**: {名前}
+
+## コンテキスト
+
+| 項目 | 内容 |
+|------|------|
+| 現在の状況 | {問題・課題} |
+| 要件 | {実現する必要があること} |
+| 制約 | {技術的・ビジネス的制約} |
+
+## 選択肢
+
+### 案1: {案1の名前}
+
+- 概要: {何をするか}
+- メリット:
+  - {メリット}
+- デメリット:
+  - {デメリット}
+- 適合性: {このプロジェクトにどう合うか}
+
+### 案2: {案2の名前}
+
+- 概要: {何をするか}
+- メリット:
+  - {メリット}
+- デメリット:
+  - {デメリット}
+- 適合性: {このプロジェクトにどう合うか}
+
+### 案3: {案3の名前}
+
+- 概要: {何をするか}
+- メリット:
+  - {メリット}
+- デメリット:
+  - {デメリット}
+- 適合性: {このプロジェクトにどう合うか}
+
+## 決定
+
+**採用案**: {案名}
+
+### 採用理由
+
+- {理由1}
+- {理由2}
+
+### 実装方針
+
+1. {方針1}
+2. {方針2}
+3. {方針3}
+
+## 影響
+
+| カテゴリ | 項目 | 内容 |
+|----------|------|------|
+| システム | 新規追加 | {コンポーネント} |
+| システム | 変更 | {コンポーネント} |
+| パフォーマンス | 処理速度 | {変化} |
+| コスト | 追加コスト | {影響} |
+| 制約 | 将来課題 | {課題} |
+
+### 反映が必要な文書
+
+- `docs/02_概要設計/{対象文書}.md`
+- `docs/03_詳細設計/src/{対象パス}.md`

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

@@ -0,0 +1,57 @@
+---
+name: existing-project-to-docs
+description: 既存プロジェクトを読み解き、docs の draft と architecture contract を起こすリバース設計フロー。
+---
+
+# existing-project-to-docs
+
+既存コードから docs を起こすフロー。
+コード、テスト、設定、インフラ定義を読み、`docs/` と `.spec-runner/` の最初の土台を作る。
+
+## 全体フロー
+
+```
+Phase 1: 現状把握
+Phase 2: 要件とユースケースの抽出
+Phase 3: 概要設計の draft 化
+Phase 4: 詳細設計の draft 化
+Phase 5: architecture contract 化
+```
+
+## Phase 1: 現状把握
+
+1. `src/`、`tests/`、設定ファイル、README、IaC を読む
+2. 現状システムの入口、主要フロー、外部依存を一覧化する
+3. `.spec-runner/intake/current-system-inventory.md` を作る
+4. ユーザーに確認・承認を得る
+
+## Phase 2: 要件とユースケースの抽出
+
+1. 既存機能からユースケースを逆算する
+2. `docs/01_要件定義/要件定義.md` と `docs/02_概要設計/ユースケース一覧.md` の draft を作る
+3. ユーザーに確認・承認を得る
+
+## Phase 3: 概要設計の draft 化
+
+1. `docs/02_概要設計/システム全体俯瞰.md` を作る
+2. 必要なら ADR 候補も洗い出す
+3. ユーザーに確認・承認を得る
+
+## Phase 4: 詳細設計の draft 化
+
+1. `docs/03_詳細設計/src/**` を `src/` ミラーで作る
+2. `maps_to` に対応コードとテストを入れる
+3. 補助設計が必要なら `docs/03_詳細設計/infrastructure/**` を作る
+4. ユーザーに確認・承認を得る
+
+## Phase 5: architecture contract 化
+
+1. `.spec-runner/architecture/architecture.yaml` を作る
+2. 現状構造を project 専用 skill へ渡せる粒度に整える
+3. `architecture-skill-development` へ引き渡す
+
+## 原則
+
+- 既存コードを正として観測し、推測は明示する
+- docs は最初から完璧を目指さず、draft として起こす
+- `maps_to` と `depends_on` を使って後続変更に耐える形へ整える

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

@@ -0,0 +1,100 @@
+---
+name: harness-engineering
+description: AI 開発運用の skills・rules・agents・テンプレートを改善・保守するためのメタスキル。別の作業を進めた結果、繰り返し発生する手戻り、ルール不足、責務の曖昧さ、テンプレートの重複が見つかったときに使用する。通常の機能実装やアプリコードの TDD には使わない。
+---
+
+# harness-engineering
+
+skills・rules・agents・テンプレートを改善するためのメタスキル。
+**主目的の作業を先に進め、再利用価値のある改善が必要なときだけ使う。**
+
+## 使うタイミング
+
+以下のいずれかに当てはまるときに使う。
+
+1. 同じ補足説明や修正が繰り返し必要になった
+2. 複数の skill / rule / agent の責務が曖昧で、手戻りや重複が発生した
+3. 既存の skill / rule / agent が不足しており、品質または作業速度を継続的に落としている
+4. ユーザーが skill / rule / agent 自体の改善を求めた
+
+## 使わないタイミング
+
+- 1 回限りの例外対応
+- 通常の機能実装やバグ修正
+- アプリケーションコードに対する TDD
+- 単なる言い回しの微調整で済む変更
+
+**TDD はこのスキルの対象ではない。**
+TDD は `test-driven-development` スキルに従い、対象プロダクトのコード品質を上げるために行う。
+
+## 全体フロー
+
+```
+Phase 1: 問題の抽出
+Phase 2: 対応方針の決定
+Phase 3: skill / rule / agent / template の修正
+Phase 4: 影響範囲の反映確認
+```
+
+## Phase 1: 問題の抽出
+
+### 手順
+
+1. 今回の作業で何が詰まり、どこに無駄が出たかを整理する
+2. その問題が一時的なものか、再発しうる構造的な問題かを判定する
+3. 改善対象を特定する
+   - skill
+   - rule
+   - agent
+   - template
+
+### 出力
+
+- 問題の要約
+- 再発条件
+- 変更対象の候補一覧
+
+## Phase 2: 対応方針の決定
+
+1. 最小変更で解決できる対象を選ぶ
+2. 新しい skill を増やすべきか、既存 skill / rule / agent の修正で十分かを判断する
+3. Claude / Copilot の両テンプレートに影響するか確認する
+
+### 判断原則
+
+- まず既存の資産を直す
+- 新しい skill は、繰り返し使う独立したワークフローがある場合だけ追加する
+- 一時的な事情を恒久ルールにしない
+
+## Phase 3: skill / rule / agent / template の修正
+
+1. 対象ファイルを特定する
+2. 意図が変わらない最小差分で修正する
+3. 片系だけでなく、対応するテンプレートも揃えて更新する
+   - `.claude/`
+   - `.github/`
+4. references や templates を参照している場合、必要な範囲だけ更新する
+
+### 修正時の注意
+
+- 役割の重複を増やさない
+- 既存スキルの主要フローを壊さない
+- ユーザー承認が前提のフローは勝手に短絡しない
+- アプリコード向けの TDD ルールを、このスキルの改善目的と混同しない
+
+## Phase 4: 影響範囲の反映確認
+
+### 確認項目
+
+- 問題の原因に対して、変更箇所が直接効いているか
+- 関連する skill / rule / agent / template の記述が矛盾していないか
+- Claude / Copilot の対応ファイルに反映漏れがないか
+- 今回限りのノイズをルール化していないか
+
+## 原則
+
+- **ハーネス改善は常時実行しない。必要なときだけ行う**
+- **主目的の作業を優先する**
+- **最小変更で改善する**
+- **新しい skill の追加は慎重に行う**
+- **TDD の責務を skill 改善と混同しない**