@takuma-hirai/hirai-method 0.1.0

package/.claude/commands/lint-rules.md

@@ -0,0 +1,400 @@
+---
+name: lint-rules
+description: "コーディングルールチェック - 現在のブランチで新規作成されたファイルに対してコーディングルール・リスク・非機能要件をチェック"
+category: quality
+complexity: standard
+model: sonnet
+mcp-servers: []
+---
+
+# /lint-rules - コーディングルールチェック（拡張版）
+
+## 概要
+
+現在のブランチで新規作成されたファイルに対して、以下の3カテゴリのチェックを実施するコマンドです。
+
+| カテゴリ | チェック内容 | ルールファイル |
+|---------|------------|---------------|
+| **A. コーディングルール** | 命名規則、ドキュメント規則、セキュリティ | `apex-naming.md`, `apex-documentation.md`, `security-checklist.md` |
+| **B. リスクチェック** | トリガー連鎖、フロー影響、デプロイ影響 | `risk-checklist.md` |
+| **C. 非機能要件** | ガバナ制限、バルク処理、パフォーマンス | `nfr-checklist.md` |
+
+## 使用方法
+
+```
+/lint-rules
+```
+
+または特定のカテゴリのみをチェック:
+
+```
+/lint-rules [category]
+# 例: /lint-rules code     # コーディングルールのみ
+# 例: /lint-rules risk     # リスクチェックのみ
+# 例: /lint-rules nfr      # 非機能要件のみ
+```
+
+## リスクレベル定義
+
+| レベル | ラベル | 説明 | 対応 |
+|--------|--------|------|------|
+| 🔴 | **Critical** | 本番環境に重大な影響、ガバナ制限超過の可能性 | 必須対応 |
+| 🟠 | **High** | 一部機能に影響、パフォーマンス低下の可能性 | 要検討 |
+| 🟡 | **Medium** | 軽微な影響、最適化の余地あり | 推奨対応 |
+
+## 実行フロー
+
+### 1. 新規ファイル一覧の取得
+
+```bash
+# デフォルトブランチ（develop）との差分で新規追加されたファイルを取得
+git diff --name-status develop...HEAD | grep '^A' | cut -f2
+```
+
+### 2. チェックルールの読み込み
+
+`.ai/rules/` 配下の全ルールファイルを読み込む:
+
+| ルールファイル | 対象 |
+|---------------|------|
+| `apex-naming.md` | Apex 命名規則 |
+| `apex-documentation.md` | Apex ドキュメンテーション規則 |
+| `security-checklist.md` | セキュリティチェックリスト |
+| `risk-checklist.md` | リスクチェックリスト |
+| `nfr-checklist.md` | 非機能要件チェックリスト |
+
+### 3. 設計書の読み込み（リスクチェック用）
+
+リスクチェックでは以下のドキュメントも参照:
+
+- `doc/detailed-design/objects/` - オブジェクト設計書
+- `doc/detailed-design/trigger/` - トリガー設計書
+- `doc/detailed-design/flow/` - フロー設計書
+
+### 4. ファイル種別によるルール適用
+
+| ファイル種別 | コードルール | リスク | NFR |
+|-------------|-------------|--------|-----|
+| `*.cls` (Apex クラス) | ✅ | ✅ | ✅ |
+| `*.trigger` (Apex トリガー) | ✅ | ✅ | ✅ |
+| `*.js` (LWC JavaScript) | ✅ セキュリティのみ | - | - |
+| `*.html` (LWC HTML) | ✅ セキュリティのみ | - | - |
+| `*.flow-meta.xml` (フロー) | - | ✅ | - |
+| `*.object-meta.xml` (オブジェクト) | - | ✅ | - |
+| `*.field-meta.xml` (項目) | - | ✅ | - |
+
+---
+
+## A. コーディングルールチェック
+
+### A.1 apex-naming.md からのチェック項目
+
+**クラス名:**
+- [ ] PascalCase になっているか
+- [ ] 適切なサフィックス（Controller, Service, Handler, TriggerHandler, Batch, Scheduler, Queueable, Action, Api, RestResource, Selector, Domain, Factory, Exception, Mock, Test, Utils/Helper）が付いているか
+- [ ] 40文字以内か
+- [ ] 小文字始まりでないか
+
+**メソッド名:**
+- [ ] camelCase になっているか
+- [ ] 動詞から始まっているか（get, find, query, create, insert, update, upsert, delete, send, validate, convert, parse, build, process, handle, execute, schedule）
+- [ ] Boolean メソッドは is/has/can/should で始まっているか
+
+**TriggerHandler メソッド名:**
+- [ ] handleBeforeInsert, handleBeforeUpdate 等の命名パターンに従っているか
+
+**Trigger 名:**
+- [ ] `[ObjectApiName]Trigger` パターンに従っているか
+
+**テストクラス:**
+- [ ] `[テスト対象クラス名]Test` パターンに従っているか
+- [ ] テストメソッド名が `test[メソッド名]_[シナリオ]` パターンに従っているか
+
+**変数・定数:**
+- [ ] ローカル変数/メンバ変数/パラメータが camelCase になっているか
+- [ ] 定数が SCREAMING_SNAKE_CASE になっているか
+
+### A.2 apex-documentation.md からのチェック項目
+
+**クラスレベル:**
+- [ ] クラス先頭にドキュメンテーションコメント（`/** ... */`）があるか
+- [ ] `@description` でクラスの説明が記載されているか
+- [ ] `@see` で詳細設計書へのリンクが記載されているか
+- [ ] リンク先パスが `doc/detailed-design/` 形式になっているか
+
+**メソッドレベル:**
+- [ ] すべての `public`/`global` メソッドにドキュメンテーションコメントがあるか
+- [ ] `@description` でメソッドの説明が記載されているか
+- [ ] 引数がある場合、すべての引数に `@param` が記載されているか
+- [ ] 戻り値がある場合（void 以外）、`@return` が記載されているか
+
+### A.3 security-checklist.md からのチェック項目
+
+**SOQL/SOSLインジェクション:**
+- [ ] 動的 SOQL でユーザー入力を `String.escapeSingleQuotes()` でエスケープしているか
+- [ ] バインド変数 `:variable` を使用しているか
+- [ ] `Database.query()` にユーザー入力を直接使用していないか
+
+**XSS:**
+- [ ] Visualforce で `escape="false"` を不用意に使用していないか
+- [ ] LWC で innerHTML を直接操作していないか
+
+**アクセス制御:**
+- [ ] `with sharing` を適切に使用しているか
+- [ ] CRUD チェック（`isCreateable()`, `isUpdateable()`, `isDeletable()`）を実装しているか
+- [ ] FLS チェックを実装しているか
+
+**その他:**
+- [ ] 機密情報をログ出力していないか
+- [ ] 例外メッセージに機密情報を含めていないか
+
+---
+
+## B. リスクチェック
+
+### B.1 トリガー連鎖リスク
+
+| # | チェック項目 | リスクレベル |
+|---|-------------|-------------|
+| 1 | 同一オブジェクトに既存トリガーが存在するか | 🔴 Critical |
+| 2 | トリガーから他オブジェクトの DML → 他トリガー呼び出しの可能性 | 🔴 Critical |
+| 3 | 再帰呼び出し防止機構（Static フラグ）があるか | 🟠 High |
+| 4 | トリガーの実行順序に依存する処理があるか | 🟠 High |
+
+### B.2 フロー影響リスク
+
+| # | チェック項目 | リスクレベル |
+|---|-------------|-------------|
+| 1 | 同一オブジェクトにレコードトリガーフローが存在するか | 🔴 Critical |
+| 2 | Apex トリガーとフローが同じ項目を更新していないか | 🔴 Critical |
+| 3 | フローの Before/After 設定との競合がないか | 🟠 High |
+
+### B.3 デプロイ影響リスク
+
+| # | チェック項目 | リスクレベル |
+|---|-------------|-------------|
+| 1 | 既存データへの影響（必須項目追加等） | 🔴 Critical |
+| 2 | 入力規則の追加・変更 | 🟠 High |
+| 3 | 数式項目・積み上げ集計項目の変更 | 🟠 High |
+| 4 | Apex テストが 75% 以上を維持しているか | 🔴 Critical |
+
+---
+
+## C. 非機能要件チェック（NFR）
+
+### C.1 ガバナ制限チェック
+
+| # | チェック項目 | リスクレベル | 検出パターン |
+|---|-------------|-------------|-------------|
+| 1 | ループ内での SOQL クエリ | 🔴 Critical | `for.*{[^}]*\[SELECT` |
+| 2 | ループ内での DML 操作 | 🔴 Critical | `for.*{[^}]*(insert\|update\|delete)` |
+| 3 | ネストされたループ内での処理 | 🟠 High | 二重ループ検出 |
+| 4 | 無制限の SOQL（LIMIT なし） | 🟠 High | `SELECT.*FROM.*(?!LIMIT)` |
+| 5 | Future メソッドの連続呼び出し | 🔴 Critical | ループ内 @future |
+
+### C.2 バルク処理対応チェック
+
+| # | チェック項目 | リスクレベル |
+|---|-------------|-------------|
+| 1 | SOQL クエリがバルク対応（IN 演算子使用）しているか | 🔴 Critical |
+| 2 | DML 操作がバルク対応（リスト操作）しているか | 🔴 Critical |
+| 3 | Map/Set を使用してルックアップしているか | 🟠 High |
+| 4 | Trigger.new/old をコレクション処理しているか | 🔴 Critical |
+| 5 | 200 レコードでテストしているか | 🟠 High |
+
+### C.3 パフォーマンス指標チェック
+
+| # | チェック項目 | リスクレベル |
+|---|-------------|-------------|
+| 1 | SELECT で必要な項目のみ取得しているか | 🟡 Medium |
+| 2 | WHERE 句でインデックス可能項目を使用しているか | 🟠 High |
+| 3 | 大量のオブジェクトをヒープに保持していないか | 🟠 High |
+| 4 | Describe コールをキャッシュしているか | 🟠 High |
+| 5 | 正規表現の Pattern をキャッシュしているか | 🟡 Medium |
+
+### C.4 org全体の日次リソース予算チェック
+
+org全体で共有される日次ガバナ制限に影響する処理が含まれる場合、予算管理シートとの整合性を確認する。
+
+管理シート: https://docs.google.com/spreadsheets/d/1nQTqOUhGNTxLCg-RJJvS_9PIP8rOCwH9LyrnpxWEpkg/
+
+| # | チェック項目 | リスクレベル | 検出パターン | 管理シート |
+|---|-------------|-------------|-------------|------------|
+| 1 | 非同期処理（Batch/Queueable/Future/Scheduled）の日次実行予算 | 🔴 Critical | `Database.Batchable`, `Queueable`, `@future`, `Schedulable` の実装 | [非同期実行予算（gid=1338771297）](https://docs.google.com/spreadsheets/d/1nQTqOUhGNTxLCg-RJJvS_9PIP8rOCwH9LyrnpxWEpkg/edit?gid=1338771297#gid=1338771297) |
+| 2 | API実行（REST/SOAP/外部Callout）の日次実行予算 | 🔴 Critical | `HttpRequest`, `HttpCalloutMock`, `WebServiceCallout`, 外部API呼び出し | [API実行予算（gid=1408277633）](https://docs.google.com/spreadsheets/d/1nQTqOUhGNTxLCg-RJJvS_9PIP8rOCwH9LyrnpxWEpkg/edit?gid=1408277633#gid=1408277633) |
+
+**確認観点:**
+- **DailyAsyncApexExecutions**: 非同期処理が新規追加・変更される場合、既存の消費量と合わせて日次上限内に収まるか確認。超過するとバッチ・Queueable等が実行不可になる。
+- **DailyApiRequests**: API実行が新規追加・変更される場合、既存の消費量と合わせて日次上限内に収まるか確認。超過するとSalesforceが停止する可能性がある。
+- 非機能要件（日次予算）が未定義の場合は 🔴 Critical として報告し、早急な定義を求める。
+
+### C.5 プラットフォーム・インフラ管理チェック
+
+GAS・オンプレミス・拡張機能の開発が含まれる場合、対応する管理シートへの登録状況を確認する。
+
+| # | チェック項目 | リスクレベル | 管理シート |
+|---|-------------|-------------|------------|
+| 1 | GAS（Google Apps Script）開発が管理シートに登録されているか | 🟠 High | [GAS管理（gid=274510541）](https://docs.google.com/spreadsheets/d/1nQTqOUhGNTxLCg-RJJvS_9PIP8rOCwH9LyrnpxWEpkg/edit?gid=274510541#gid=274510541) |
+| 2 | オンプレミス（Windowsサーバー）処理が管理シートに登録されているか | 🟠 High | [オンプレミス管理（gid=1085039133）](https://docs.google.com/spreadsheets/d/1nQTqOUhGNTxLCg-RJJvS_9PIP8rOCwH9LyrnpxWEpkg/edit?gid=1085039133#gid=1085039133) |
+| 3 | 拡張機能（Chrome拡張等）が管理シートに登録されているか | 🟠 High | [拡張機能管理（gid=1621667722）](https://docs.google.com/spreadsheets/d/1nQTqOUhGNTxLCg-RJJvS_9PIP8rOCwH9LyrnpxWEpkg/edit?gid=1621667722#gid=1621667722) |
+
+---
+
+## 出力形式
+
+### サマリー
+
+```
+========================================
+コーディングルールチェック結果（拡張版）
+========================================
+チェック対象ファイル数: X 件
+========================================
+
+## サマリー
+
+| カテゴリ | Critical | High | Medium | 合計 |
+|---------|----------|------|--------|------|
+| A. コーディングルール | X | X | X | X |
+| B. リスクチェック | X | X | X | X |
+| C. 非機能要件 | X | X | X | X |
+| **合計** | **X** | **X** | **X** | **X** |
+
+========================================
+```
+
+### 詳細レポート
+
+```markdown
+## A. コーディングルール違反
+
+### 1. force-app/main/default/classes/ExampleClass.cls
+
+| # | ルール | カテゴリ | 行番号 | リスク | 違反内容 | 修正提案 |
+|---|--------|----------|--------|--------|----------|----------|
+| 1 | apex-naming | クラス名 | 1 | 🟠 High | 小文字始まりのクラス名 | `ExampleClass` に変更 |
+| 2 | security | SOQL | 25 | 🔴 Critical | エスケープなしの動的SOQL | `String.escapeSingleQuotes()` を使用 |
+
+---
+
+## B. リスクチェック結果
+
+### トリガー連鎖リスク
+
+| # | 対象 | リスク | 詳細 | 対応策 |
+|---|------|--------|------|--------|
+| 1 | AccountTrigger | 🔴 Critical | Contact への DML が ContactTrigger を呼び出す可能性 | 再帰防止フラグを追加 |
+
+### フロー影響リスク
+
+| # | 対象 | リスク | 詳細 | 対応策 |
+|---|------|--------|------|--------|
+| 1 | Account_After_Update Flow | 🟠 High | 同じ Status__c 項目を更新 | 実行順序を確認 |
+
+### デプロイ影響リスク
+
+| # | 対象 | リスク | 詳細 | 対応策 |
+|---|------|--------|------|--------|
+| 1 | RequiredField__c | 🔴 Critical | 必須項目追加（デフォルト値なし） | デフォルト値を設定 |
+
+---
+
+## C. 非機能要件チェック結果
+
+### ガバナ制限
+
+| # | ファイル | 行番号 | リスク | 指摘内容 | 修正提案 |
+|---|----------|--------|--------|----------|----------|
+| 1 | ExampleService.cls | 45 | 🔴 Critical | ループ内 SOQL | ループ外でバルク取得 |
+
+### バルク処理対応
+
+| # | ファイル | リスク | 指摘内容 | 修正提案 |
+|---|----------|--------|----------|----------|
+| 1 | AccountTriggerHandler.cls | 🟠 High | Map 未使用のネストループ | Map でルックアップを最適化 |
+
+### パフォーマンス指標
+
+| # | ファイル | 行番号 | リスク | 指摘内容 | 修正提案 |
+|---|----------|--------|--------|----------|----------|
+| 1 | ReportService.cls | 78 | 🟡 Medium | SELECT * 相当のクエリ | 必要項目のみ取得 |
+
+---
+
+## 総合判定
+
+### リリース判定チェックリスト
+
+- [ ] Critical 指摘: X 件 → すべて対応必須
+- [ ] High 指摘: X 件 → リリース判断時に検討
+- [ ] Medium 指摘: X 件 → 可能であれば対応
+
+### 判定結果
+
+- [ ] ✅ リリース可能（Critical なし）
+- [ ] ⚠️ 条件付きリリース可能（Critical 対応後）
+- [ ] ❌ リリース不可（Critical 未解決）
+```
+
+### 違反なしの場合
+
+```
+========================================
+コーディングルールチェック結果（拡張版）
+========================================
+チェック対象ファイル数: X 件
+========================================
+
+## サマリー
+
+| カテゴリ | Critical | High | Medium | 合計 |
+|---------|----------|------|--------|------|
+| A. コーディングルール | 0 | 0 | 0 | 0 |
+| B. リスクチェック | 0 | 0 | 0 | 0 |
+| C. 非機能要件 | 0 | 0 | 0 | 0 |
+| **合計** | **0** | **0** | **0** | **0** |
+
+========================================
+✅ すべてのファイルがチェックに合格しました！
+リリース判定: リリース可能
+========================================
+```
+
+---
+
+## 実行例
+
+```bash
+# Claude Code CLI でコマンド実行（全チェック）
+claude "/lint-rules"
+
+# コーディングルールのみ
+claude "/lint-rules code"
+
+# リスクチェックのみ
+claude "/lint-rules risk"
+
+# 非機能要件のみ
+claude "/lint-rules nfr"
+```
+
+---
+
+## 関連ドキュメント
+
+- `.ai/rules/apex-naming.md` - Apex 命名規則
+- `.ai/rules/apex-documentation.md` - Apex ドキュメンテーション規則
+- `.ai/rules/security-checklist.md` - セキュリティチェックリスト
+- `.ai/rules/risk-checklist.md` - リスクチェックリスト
+- `.ai/rules/nfr-checklist.md` - 非機能要件チェックリスト
+- `.ai/instructions/review.md` - コードレビュー指示
+- `doc/detailed-design/` - 設計書（リスク分析で参照）
+
+---
+
+## 更新履歴
+
+| 日付 | 更新者 | 内容 |
+|------|--------|------|
+| 2026-01-16 | - | 初版作成 |
+| 2026-02-05 | - | リスクチェック・非機能要件チェック機能を追加 |

package/.claude/commands/mode.md

@@ -0,0 +1,58 @@
+---
+description: HIRAI メソッドの動作モードを切替える (normal / loop / asana on|off)
+---
+
+# /mode — 動作モード切替
+
+引数:
+- `normal` または `loop` — 動作モード (確認スタイル) 切替
+- `asana on` または `asana off` — Asana 連携 ON/OFF 切替
+
+## 動作
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください。
+
+### サブコマンド: `normal` / `loop` (動作モード)
+
+1. **引数の検証**:
+   - 引数が `normal` または `loop` であることを確認
+   - 不正な引数の場合、使い方を表示して終了
+2. **設定ファイル更新**: `.claude/mode.yml` の `mode:` 行を新しい値に書き換える
+   - 既存の他のキー / コメントは保持
+   - sed や Edit ツールで `mode: <旧値>` → `mode: <新値>` を 1 箇所だけ置換
+3. **確認出力**: 「Mode switched to **{新値}**」をユーザに報告
+4. **次セッションへの注意**:
+   - 設定変更は本セッションでは即座には適用されない（hook は次の UserPromptSubmit から効く）
+   - ただし、本ターン以降の応答は新モードのルールに従って行うこと
+5. **Loop モードへの切替時**:
+   - 直ちに Loop モードの動作ルール (`.claude/rules/modes.md` 参照) を遵守
+   - ユーザ確認を取らず推奨方法で実装を継続
+6. **Normal モードへの切替時**:
+   - 重要分岐でユーザ確認を取る通常動作に戻る
+
+### サブコマンド: `asana on` / `asana off` (Asana 連携 mode)
+
+1. **引数の検証**:
+   - 第 1 引数が `asana`、第 2 引数が `on` または `off` であることを確認
+   - `on` → `asana_enabled: true`、`off` → `asana_enabled: false`
+2. **設定ファイル更新**: `.claude/mode.yml` の `asana_enabled:` 行を書き換える
+   - 既存値が無い場合は新規追加、ある場合は置換
+3. **確認出力**: 「Asana 連携: **on / off** に設定しました」
+4. **on 時**: `/work-init`, `work-session-check.sh`, Asana/Slack MCP 関連機能が有効化
+5. **off 時**: 上記機能は no-op、ハーネスは Asana 抜きで動作
+
+## 使い方
+
+```
+/mode loop          # Loop モードに切替
+/mode normal        # Normal モードに切替
+/mode asana on      # Asana 連携を有効化
+/mode asana off     # Asana 連携を無効化
+```
+
+## 関連
+
+- `.claude/rules/modes.md` — モードルール詳細
+- `.claude/hooks/mode-session-start.sh` — SessionStart で現モード表示
+- `.claude/hooks/mode-enforce.sh` — UserPromptSubmit で Loop ルール強制
+- `.claude/hooks/mode-asana-prompt.sh` — SessionStart で asana_enabled 未設定時に user ヒアリング

package/.claude/commands/modify-feature.md

@@ -0,0 +1,209 @@
+---
+description: 既存機能修正の 10-stage workflow を起動する (ブランチ確定→既存設計回収→pre-test→改修→TDD→レビュー→merge)
+args: <slug>
+related: [/test-design, /design-review, /start-task, /module-review, /system-review, /finish-task]
+---
+
+# /modify-feature — 既存機能修正 10-stage workflow オーケストレータ
+
+既存機能の修正を **10 stage** で自動進行する workflow command。新規開発 (`/new-feature`) と異なり、要件定義 / detailed-design / task-creation の段が省略され、代わりに **recover-design** (既存設計回収) / **pre-test** (修正前 baseline) / **retest-design** (差分反映 test-design) が入る。
+
+stage 名は `.claude/harness-config.yml` の `workflow_stages_modify` (`HC_WORKFLOW_STAGES_MODIFY`) と完全一致する 10 要素の配列。`workflow-guard.sh` が `.claude/.workflow-state/<slug>.json` の `current_stage` を参照して進行を検証する。
+
+## 前提
+
+- 修正対象機能の slug が既存 `docs/tasks/task-<id>-<slug>.md` または `docs/draft/<slug>.md` と紐付くこと
+- 修正前の状態で **既存テストが全 PASS**(`pre-test` stage の baseline)
+- `git status` がクリーン (uncommitted changes は事前に commit / stash)
+
+## 使い方
+
+```
+/modify-feature <slug>
+```
+
+## 引数
+
+- `<slug>` — kebab-case、既存 task / draft の slug と一致
+  - validation: `^[a-z0-9][a-z0-9-]{2,48}$`(git-workflow.md branch 規約準拠)
+  - path traversal 防止のため `.` `/` `..` を含む値は reject
+
+## 動作
+
+10 stage を順次進める。各 stage 完了で `.claude/.workflow-state/<slug>.json` の `current_stage` / `completed_stages` を更新。
+
+### Stage 1: `branch-decision`
+
+修正対象機能の影響範囲を特定し、修正ブランチ命名を決定する。
+
+1. `git grep` / `Glob` で `<slug>` 関連ファイル (`src/**` `tests/**` `docs/**`) を抽出 → 影響範囲を user に提示
+2. 修正の性質を判定して branch type を提案(git-workflow.md 規約準拠):
+   - bug 修正 → `fix/<slug>`(または `fix/<slug>-<short-desc>`)
+   - 内部構造改善 → `refactor/<slug>`
+   - 機能追加(既存機能内) → `feat/<slug>`
+   - hot fix → `hotfix/<slug>`
+3. user に branch 名を提示し承認を得る(Loop モード時は AI 推奨を即採用)
+4. State 初期化: `.claude/.workflow-state/<slug>.json` を `workflow_type=modify`, `current_stage=branch-decision` で生成 → 完了で `completed_stages` に追加
+
+### Stage 2: `checkout`
+
+決定した branch に切替える。
+
+1. 既存 branch なら `git switch <branch>`、新規なら `git switch -c <branch>`
+2. branch 命名 regex (`^(feat|fix|refactor|docs|test|chore|perf|ci|hotfix)/[a-z0-9][a-z0-9-]{2,48}$`) を検証 → 不適合なら BLOCK
+3. State 更新: `current_stage=checkout` → 完了で `completed_stages` 追加
+
+### Stage 3: `recover-design`
+
+既存設計を回収する。
+
+1. **既存 task 探索**: `Glob` で `docs/tasks/task-*-<slug>.md` を検索 → 見つかったら Read で内容を取得
+2. **既存 draft 探索**: `docs/draft/<slug>.md` を Read
+3. **設計の充足度判定**:
+   - 両方存在 + §1〜9 が埋まっている → 既存設計を採用、次 stage へ
+   - draft なし or 不完全 → **reverse-engineer**: 該当コード (`src/**`) を Read して `_DRAFT_TEMPLATE.md` から新規 `docs/draft/<slug>.md` を起こす(現状実装を §3 詳細設計に転記)
+4. **Skip ルール**: 既存設計が完備で diff が小さい(例: 単一関数の bug fix)場合、user 承認のうえ `recover-design` を `skip_log` に記録して短縮可
+5. State 更新: `current_stage=recover-design` → 完了で `completed_stages` 追加
+
+### Stage 4: `pre-test`
+
+**修正前**の全テストを実行し green baseline を確認する。
+
+1. `npm run test`(または stack に応じた test runner)を実行
+2. **failing test があれば BLOCK**: 「修正前の test が既に fail。本 workflow 開始不可。先に別タスクとして該当 test を修正せよ」と user に提示し中断
+3. baseline test 数 + PASS 数を State に記録(後の `full-test` stage との regression 比較用)
+4. State 更新: `current_stage=pre-test` → 完了で `completed_stages` 追加
+
+### Stage 5: `redesign`
+
+`docs/draft/<slug>.md` に変更点を追記する(既存設計に diff を載せる)。
+
+1. user から修正内容のヒアリング(または `/new-feature` 時の本タスクからの転記)
+2. draft の §3 詳細設計に「変更前 / 変更後」の差分セクションを追記
+3. 関連 §2 基本設計 / §6 リスク も影響があれば更新
+4. State 更新: `current_stage=redesign` → 完了で `completed_stages` 追加
+
+### Stage 6: `retest-design`
+
+`/test-design <slug>` を再実行 (W1)。既存テスト + 修正部の新規テスト観点を MECE で出し直す。
+
+1. 既存 `docs/draft/<slug>.test-design.md` があれば backup (`<slug>.test-design.md.bak`) して再生成
+2. `/test-design <slug>` を起動 → tdd-guide / test-automator / qa-expert を並列 fan-out
+3. 20 カテゴリの採用 / 不採用を user スコープ決定 (差分部のみ新規採用も可)
+4. **Skip ルール**: 変更影響が `tests/` 内のみ(test refactor 等)で production code (`src/**`) 変更がない場合、user 承認 + `skip_log` 記録で skip 可
+5. State 更新: `current_stage=retest-design` → 完了で `completed_stages` 追加
+
+### Stage 7: `tdd`
+
+TDD red-green-refactor。修正部の新規テストを **書いてから** 実装する。
+
+1. retest-design で採用された新規 test を `tests/` に追加 (RED)
+2. production code (`src/**`) を最小変更で修正 → 新規 test を PASS させる (GREEN)
+3. リファクタリング (REFACTOR) — 既存挙動を変えない範囲で
+4. モジュール単位の段階的 commit を推奨(Loop モード遵守事項 §5)
+5. State 更新: `current_stage=tdd` → 完了で `completed_stages` 追加
+
+#### Wave Pre-check
+
+Wave / sub-task 分解後、各 Wave 着手前にメインが以下を **subagent dispatch の前** に必ず実施する (2026-05-21 TM 修正での no-op 重複起動を防ぐため):
+
+1. メインが `git log --all --grep <finding>` で既存 commit を確認 (別 repo は `git -C <abs path> log --all --grep <finding>`)
+2. 解消済 finding は task ファイルの Wave 表から「[no-op、commit <sha>]」とマーク
+3. 未解消 finding のみ subagent dispatch
+4. subagent prompt に「事前確認 step」を明示 (現状ファイルを Read → 解消済なら no-op 報告)
+
+省略時のリスク: 既存 commit で解消済の finding に対して subagent を起動し、token / 時間の二重消費 + Wave 再計画コストが発生する。modify-feature では gap-review report 起点の修正で特に発生しやすい (report 作成時点から本実装着手までに別 commit で解消されている場合)。
+
+### Stage 8: `module-review`
+
+`/module-review <module>` を実行 (W3)。3 観点 (持続可能性 / 汎用性 / 非冗長化) レビュー。
+
+1. 修正対象モジュールを引数に `/module-review` を起動
+2. 並列 reviewer (code-reviewer + refactoring-specialist + 言語別 reviewer) fan-out
+3. `pending_findings.module_review` に findings 配列を記録
+4. **CRITICAL / HIGH findings が残っている間は次 stage 進行不可** (workflow-guard で block)
+5. user が修正対応 → findings を resolve → 全テスト再 PASS
+6. State 更新: `current_stage=module-review` → 完了で `completed_stages` 追加
+
+### Stage 9: `full-test`
+
+全テスト green 確認 (既存 regression なし + 新規 test pass)。
+
+1. `npm run test` を全体実行
+2. **regression 検出**: `pre-test` stage で記録した baseline PASS 数と比較。既存 test が新たに fail していたら BLOCK
+3. 新規 test が全 PASS していることを確認
+4. State 更新: `current_stage=full-test` → 完了で `completed_stages` 追加
+
+### Stage 10: `system-review`
+
+`/system-review` を実行 (W3)。マージ前最終整合性確認。
+
+1. `/system-review` を起動 → architect-reviewer + code-reviewer + refactoring-specialist を並列 fan-out
+2. モジュール間整合性 / 既存コードとの統合面の重複・乖離を検出
+3. `pending_findings.system_review` に findings 配列を記録
+4. **CRITICAL / HIGH findings が残っている間は merge 不可** (workflow-guard で block)
+5. pass で merge 可 → user 確認のうえ `git push` → `/finish-task <id>` を案内
+6. State 更新: `current_stage=system-review` → 完了で `completed_stages` 追加 → 全 stage 完了
+
+## State 管理
+
+- ファイル: `.claude/.workflow-state/<slug>.json`
+- schema: `.claude/.workflow-state/SCHEMA.md`
+- 主要フィールド:
+  - `workflow_type`: `"modify"` 固定
+  - `current_stage`: 現在進行中の stage 名 (上記 10 stage 名のいずれか)
+  - `completed_stages`: 完了済 stage の配列 (順序保持)
+  - `pending_findings.module_review` / `pending_findings.system_review`: 未解決 findings
+  - `skip_log`: skip された stage の audit ログ (stage / reason / user_approved_at)
+- 全 timestamp は ISO-8601 UTC 秒精度、`Z` suffix
+
+## Skip ルール
+
+| Stage | Skip 可否 | 条件 |
+|---|---|---|
+| `recover-design` | 短縮可 | 既存設計が完備 (`docs/draft/<slug>.md` §1〜9 充足) で diff が小さい (単一関数 bug fix 等)。user 承認 + `skip_log` 必須 |
+| `retest-design` | skip 可 | 変更影響が `tests/` 内のみで production code (`src/**`) 変更なし。user 承認 + `skip_log` 必須 |
+| 上記以外 | skip 不可 | branch-decision / checkout / pre-test / redesign / tdd / module-review / full-test / system-review は workflow-guard が block |
+
+skip 時は必ず `skip_log` に `{stage, reason, user_approved_at}` を記録すること (`workflow-guard.sh` が grep 検証)。
+
+## workflow-guard.sh との連携
+
+- **PreToolUse(Bash) `/finish-task` 検知**: `workflow-guard.sh` は `/finish-task <id>` 実行直前に `.claude/.workflow-state/<slug>.json` を読み、以下を検証:
+  - `current_stage == "system-review"` かつ全 stage が `completed_stages` に含まれること
+  - `pending_findings.module_review` / `system_review` に CRITICAL / HIGH が **残っていない** こと
+  - 未完了の必須 stage を skip している場合、`skip_log` に対応エントリと `user_approved_at` があること
+- 違反時は BLOCK + 「先に stage N を完了せよ」(または「未対応 findings を解決せよ」) と提示
+- bypass: `ECC_WORKFLOW_GUARD=off` (緊急時のみ)
+
+## /new-feature との差分
+
+| 観点 | `/new-feature` (14 stage) | `/modify-feature` (10 stage) |
+|---|---|---|
+| 要件定義 | あり (Step 1: requirements) | **なし** (既存機能のため省略) |
+| 基本設計 | あり (Step 2: basic-design) | recover-design で既存を回収 |
+| 詳細設計 | あり (Step 3: detailed-design) | redesign で diff を追記 |
+| テスト設計 | test-design (Step 4) | retest-design (Stage 6) |
+| design-review | あり (Step 5) | **なし** (既存設計の差分のみのため省略) |
+| user-approval | あり (Step 6) | branch-decision の branch 承認に統合 |
+| task-creation | あり (Step 7: /new-task) | **なし** (既存 task を流用) |
+| TDD | あり (Step 8) | tdd (Stage 7) |
+| module-review | あり (Step 9) | module-review (Stage 8) |
+| local-test | あり (Step 10) | full-test (Stage 9) — pre-test baseline 比較あり |
+| system-review | あり (Step 11) | system-review (Stage 10) |
+| CI/CD | あり (Step 12) | **なし** (既存 pipeline 流用) |
+| scenario-test | あり (Step 13) | **なし** (regression test で代替) |
+| 完了 | finish (Step 14) | `/finish-task` で完了 |
+| **追加 stage** | — | **branch-decision** / **checkout** / **recover-design** / **pre-test** / **retest-design** |
+
+## 関連
+
+- `/test-design <slug>` — Stage 6 retest-design で起動 (W1)
+- `/design-review <slug>` — modify では Stage 5 redesign 内で必要に応じ起動 (W2)
+- `/start-task <id>` — task 単位の branch 切替 (modify-feature の checkout と相補)
+- `/module-review <module>` — Stage 8 で起動 (W3)
+- `/system-review` — Stage 10 で起動 (W3)
+- `/finish-task <id>` — 全 stage 完了後の最終クローズ (workflow-guard が state JSON を検証)
+- state schema: `.claude/.workflow-state/SCHEMA.md`
+- config: `.claude/harness-config.yml` の `workflow_stages_modify`
+- 設計: `docs/draft/workflow-enforcement.md` §3 W4