@takuma-hirai/hirai-method 0.1.0

package/.claude/commands/module-review.md

@@ -0,0 +1,149 @@
+---
+description: TDD 完了直後のモジュール単位レビュー + リファクタリング (持続可能性 / 汎用性 / 非冗長化 の 3 観点)
+---
+
+# /module-review — モジュール単位レビュー & リファクタリング
+
+`/new-feature` Step 9 / `/modify-feature` Step 7 で呼ばれる。指定モジュール (ファイル / ディレクトリ) の TDD 完了直後に、`reviewer_registry_impl` カテゴリの agent を並列起動し、**持続可能性 / 汎用性 / 非冗長化** の 3 観点で findings を集約 + 修正提案。
+
+## 前提
+
+- 対象モジュールの TDD (Red/Green/Refactor) が完了し、テストが全 PASS
+- 該当タスクファイル `docs/tasks/task-<id>-<slug>.md` が存在 (workflow 進行中の文脈確認)
+- 直前の commit ハッシュが取得できる (`git log -1 --format=%H`)
+
+## 使い方
+
+```
+/module-review <module>                       # 既定: code-reviewer + refactoring-specialist + 言語別 reviewer
+/module-review <module> --since <commit>      # 比較対象の commit を明示
+/module-review <module> --skip-refactor       # findings 検出のみ、修正提案を生成しない
+/module-review <module> --max-reviewers 3     # cost 制御
+```
+
+## 引数
+
+- `<module>` — ファイル path または ディレクトリ path (validation: `src/` `tests/` `.claude/` 配下のみ)
+- `--since <commit>` — 比較開始 commit (省略時は直前 commit)
+- `--skip-refactor` — 修正コード提案を skip (検出 only)
+
+## 動作
+
+### Phase 0: yml 参照 (task-45 Phase 2、reviewer 制御 yml 経由化)
+
+本 command 開始前に `harness-config.yml` から以下 4 値を参照 (env > yml > default、`config-loader.sh` 仕様):
+
+| 環境変数 | yml key | default | 用途 |
+|---|---|---:|---|
+| `HC_REVIEW_REQUIRED_MODULE` | `review_required_module` | `true` | `false` なら本 command を **no-op skip** (理由付きでユーザに報告 + 終了、`/new-feature` Step 9 / `/modify-feature` Step 7 で skip 可) |
+| `HC_REVIEW_MIN_COUNT_MODULE` | `review_min_count_module` | `2` | reviewer 最低数 (default 2 = code-reviewer + refactoring-specialist) |
+| `HC_REVIEW_MAX_COUNT_MODULE` | `review_max_count_module` | `5` | reviewer 上限 (`--max-reviewers` 未指定時の default) |
+| `HC_REVIEW_ITERATION_MAX` | `review_iteration_max` | `5` | findings 修正後の反復ループ上限 |
+
+**起動前に必ず以下を実行して reviewer 数を確定する (task-64、散文参照でなく実行手順)**:
+
+```bash
+bash .claude/scripts/hc-config.sh --get review_required_module   # false なら本 command を no-op skip
+bash .claude/scripts/hc-config.sh --get review_min_count_module  # 範囲下限
+bash .claude/scripts/hc-config.sh --get review_max_count_module  # 範囲上限
+# → min ≤ 並列起動 reviewer 数 N ≤ max を保証して起動 (青天井禁止)。値解決順 env > harness-config.local.yml > harness-config.yml > default
+```
+
+`HC_REVIEW_REQUIRED_MODULE=false` で skip した場合は、bypass.log に記録し、ユーザに「review_required_module=false のため /module-review を skip した、Phase 1 以降を実行しない」と明示。
+
+### Phase 1: 前提チェック
+
+1. `<module>` が valid な path か (`^[a-zA-Z0-9_./-]+$`)、`..` 含まないこと
+2. `git diff --stat <since>..HEAD -- <module>` で diff が存在するか
+3. `docs/tasks/task-<id>-<slug>.md` (現在進行中タスク) が存在し、Wave 進捗が「実装 (TDD) 完了」状態か
+
+### Phase 2: 対象抽出 + stack 推定
+
+1. `git diff <since>..HEAD -- <module>` で変更コード + 関連 test を抽出
+2. 言語推定 (`.ts` `.py` `.go` `.rs` 等の拡張子 + `package.json` / `pyproject.toml` 検出)
+3. `harness-config.yml` の `reviewer_registry_impl` から起動 reviewer を選定:
+   - **code-reviewer** — 常時起動
+   - **refactoring-specialist** — 常時起動 (本 command の中核)
+   - 言語別 reviewer (typescript-reviewer / python-reviewer / go-reviewer 等) — stack 適合時のみ
+
+### Phase 3: 並列 Agent fan-out
+
+1. 選定 reviewer ごとに **TaskCreate** + **Agent tool 起動** (`run_in_background: true` 必須)
+2. 共通 prompt 規約 (refactoring-specialist 中心):
+
+```
+入力:
+- 対象モジュール: <module>
+- 変更 diff: <git diff の本文>
+- 関連 test: <tests/... の本文>
+
+レビュー観点 (3 観点必須):
+
+1. **持続可能性 (Sustainability)**:
+   - (a) 命名が意図を表しているか
+   - (b) 関数 50 行以内・ファイル 800 行以内
+   - (c) ネスト 4 階層以内
+   - (d) magic number 排除
+   - (e) 副作用が局所化
+   - (f) 型注釈・docstring が将来の読み手に必要十分
+   - (g) error path が silent failure になっていない
+
+2. **汎用性 (Generality)**:
+   - (a) 引数で挙動を切替可能か
+   - (b) 1 callee に特化したコードでないか
+   - (c) 言語/framework idiom に従っているか
+   - (d) interface が抽象に依存し具象に縛られていないか
+   - (e) test seam が存在するか
+
+3. **非冗長化 (Deduplication)**:
+   - (a) 同一ロジックの複製がないか (DRY)
+   - (b) 似た条件分岐の table-driven 化候補
+   - (c) 既存 util/helper の再発明をしていないか
+   - (d) 既存型・既存 schema を流用できる箇所
+   - (e) 不要な抽象 (over-engineering) を作っていないか (YAGNI)
+
+4. **プロジェクト整合性 + 他 task 影響確認 (項目 5、`workflow.md` §reviewer prompt 共通規約 準拠、2026-05-28 追加)**:
+   - (a) `docs/tasks/list.md` を Read、本 module 変更が他 task (🔄 進行中 / 🔲 未着手 / 📝 計画中) と重複 / 競合 / 前提崩壊しないか
+   - (b) 本対象の依存先 task.md + draft.md を Read、影響範囲を把握
+   - (c) `docs/tasks/next-actions.md` の未処理 🔴 / 🟡 entry を確認、本 module 変更で解決 / 関連する entry を特定
+   - (d) `.claude/rules/*.md` (Layer A 全 7 file) を Read、本 module 変更が既存規範と矛盾していないか / 規範更新が必要か
+   - (e) `README.md` / `docs/INVENTORY.md` を Read、本 module 変更が project SSoT を破壊していないか
+   - (f) `.claude/hooks/` `.claude/commands/` `.claude/skills/` を Glob/Grep、類似機能が既存なら本変更との関係を findings に明記 (再発明回避)
+
+出力 format:
+- 4 観点ごとに findings (CRITICAL / HIGH / MED / LOW)
+- 各 finding に「該当ファイル:行 / 問題 / 修正コード提案 (具体 diff)」
+- 項目 4 (プロジェクト整合性) の findings には「他 task #N との重複」「既存 rule §X と矛盾」「副産物 entry #Y を解決可能」「既存 hook/command/skill 再利用可」「SSoT 矛盾」のいずれかを該当時に明示
+- behavior-preserving 原則必須 (public API / DB schema 変更禁止)
+- 全 finding に対応 → modified diff を提示
+- 末尾に `confidence: 0.X` 必須
+- bypass: `HC_REVIEW_PROJECT_CONTEXT_REQUIRED=false` (typo 1 行 / comment-only refactor 等の cost 過大ケースのみ、`.claude/rules/` 編集を含む change では NG)
+```
+
+### Phase 4: 集約 + 修正案提示
+
+1. 全 agent 完了通知後、findings を `docs/draft/<slug>-module-review-<module-slug>.md` に集約
+2. CRITICAL/HIGH を blocking findings として表示
+3. `--skip-refactor` 未指定時は、refactoring-specialist の修正案を user に提示し承認後に適用
+
+### Phase 5: 修正適用 + テスト再 PASS 確認
+
+1. 承認された修正をモジュールに適用 (subagent 経由、main は直接編集禁止)
+2. 該当モジュールのテスト再実行
+3. 全 PASS なら Wave 進捗を「ローカルテスト」に進める
+4. FAIL なら修正取り消し + user 確認
+
+## 制約
+
+- behavior-preserving 必須 (public API / DB schema 変更不可)
+- workflow-guard.sh (W4 実装後) はこの step を skip した `/finish-task` を block
+- skip する場合は `docs/work.md` 時系列ログに skip 理由 + user 承認時刻記載必須
+- bypass: `ECC_MODULE_REVIEW_OFF=1` (推奨せず、hot fix 用)
+
+## 関連
+
+- `/system-review` — 全体統合レビュー (本 command の後段)
+- `/design-review` — 設計レビュー (本 command の前段)
+- `/finish-task` — タスク完了 (本 command 後)
+- config: `.claude/harness-config.yml` の `reviewer_registry_impl`
+- 設計 draft: `docs/draft/workflow-enforcement.md` §3 W3

package/.claude/commands/move-section.md

@@ -0,0 +1,67 @@
+---
+name: move-section
+description: "Asanaタスクのセクション移動 - APIを使用してタスクを指定セクションに移動"
+category: workflow
+complexity: basic
+model: haiku
+---
+
+# /move-section - Asanaセクション移動
+
+## 概要
+
+Asana APIを直接呼び出し、タスクを指定のセクションに移動するコマンド。
+
+## 使用方法
+
+```
+/move-section {AsanaタスクURL} {移動先セクション名}
+```
+
+例:
+
+```
+/move-section https://app.asana.com/.../task/1212783078881318 依頼確定済み
+```
+
+## 実行コマンド
+
+```bash
+curl -X POST "https://app.asana.com/api/1.0/sections/{section_gid}/addTask" \
+  -H "Authorization: Bearer {{ASANA_PERSONAL_ACCESS_TOKEN}}" \
+  -H "Content-Type: application/json" \
+  -d '{"data": {"task": "{task_gid}"}}'
+```
+
+## プロジェクト: ClassLab SalesForce 構築
+
+### セクション一覧
+
+| セクション名                | GID              |
+| --------------------------- | ---------------- |
+| 工数見積,実現可否の検証     | 1201939731380483 |
+| 依頼検討中                  | 1201975562340041 |
+| **依頼確定済み**            | 1203436351848909 |
+| 構築中(開発環境)            | 1201939731380472 |
+| お客様確認中(テスト環境)    | 1204458678797631 |
+| リリース待ち                | 1202018010404869 |
+| お客様確認中(本番環境)&工数 | 1201939731380525 |
+| 完了                        | 1201947180153922 |
+| 保留                        | 1201939731380482 |
+
+## /design フローでの使用
+
+PR作成後（B-7完了後）、タスクを「依頼確定済み」セクションに移動:
+
+```bash
+curl -X POST "https://app.asana.com/api/1.0/sections/1203436351848909/addTask" \
+  -H "Authorization: Bearer {{ASANA_PERSONAL_ACCESS_TOKEN}}" \
+  -H "Content-Type: application/json" \
+  -d '{"data": {"task": "{AsanaタスクID}"}}'
+```
+
+## 注意事項
+
+- PATはコマンド内に直接記載
+- セクションGIDはプロジェクト固有
+- 移動先セクションは同一プロジェクト内である必要がある

package/.claude/commands/new-draft.md

@@ -0,0 +1,67 @@
+---
+description: docs/draft/ に設計 draft を起こす。設計→承認→タスク追加フローの起点。
+---
+
+# /new-draft — 設計 draft 起こし
+
+`docs/draft/<slug>.md` を `_DRAFT_TEMPLATE.md` から生成。設計→承認→`/new-task` でタスク化、というフローの最初のステップ。
+
+## 使い方
+
+```
+/new-draft <slug>                          # 例: link-card-componentize
+/new-draft <slug> --title "<タイトル>"     # H1 を明示
+/new-draft <slug> --origin "<起点>"        # 「ユーザー報告 / 監査 / 障害」等
+```
+
+## 引数
+
+- `<slug>` — kebab-case（最終的な task ファイル名と揃える）
+
+## 動作
+
+### Phase 1: 既存確認
+
+- `docs/draft/<slug>.md` が存在しないことを確認
+- 存在する場合は中断（既存編集を促す）
+
+### Phase 2: テンプレ展開
+
+1. `.claude/templates/docs/draft/_DRAFT_TEMPLATE.md` をコピー
+2. プレースホルダ置換:
+   - `<設計タイトル>` → `--title` 引数 or slug を Title-Case 化
+   - 起案日 → 今日
+   - `<起点>` → `--origin` 引数 or 「user 依頼」
+
+### Phase 3: 起案案内
+
+```
+📝 Draft 起こしました: docs/draft/<slug>.md
+
+次の操作:
+  1. ファイルを開いて H1〜セクション 9 を埋める
+  2. mermaid 図 / 案比較 / Wave 分割 / リスク 等を充実させる
+  3. user にレビュー・承認を依頼
+  4. 承認後: /new-task <ID> <slug> でタスク化
+```
+
+## 設計テンプレの章立て
+
+`_DRAFT_TEMPLATE.md` は以下の構成:
+
+1. 真因サマリ / 課題サマリ
+2. 解決アプローチ比較（複数案 + 推奨）
+3. 採用案の詳細設計（Wave / Sub-task 分割）
+4. リスクと緩和
+5. 移行計画
+6. 完了条件（DoD）
+7. 工数見積
+8. 承認履歴
+9. 関連
+
+## 関連
+
+- `/new-task <id> <slug>` — 設計承認後にタスク化
+- `/init-tasks` — テンプレ初期化
+- rule: `.claude/rules/development-process.md` 「設計→承認→タスク追加フロー」
+- 例: `docs/draft/task-<slug>.md`（`<slug>` は kebab-case の機能名）

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

@@ -0,0 +1,286 @@
+---
+description: 新規機能開発の 14-stage workflow を起動する (要件→設計→テスト→TDD→レビュー→完了)
+args: <slug>
+related: [/test-design, /design-review, /new-task, /start-task, /module-review, /system-review, /finish-task]
+---
+
+# /new-feature — 新規機能開発 14-stage workflow オーケストレータ
+
+新規機能開発の 14-stage workflow を起動する。要件定義から完了までを workflow-guard.sh が `.claude/.workflow-state/<slug>.json` を参照して強制する。
+
+設計 draft v2 §3 W4 準拠。stage 名は `harness-config.yml` の `workflow_stages_new` (= env `HC_WORKFLOW_STAGES_NEW`) と完全一致。
+
+## 使い方
+
+```
+/new-feature <slug>
+```
+
+## 引数
+
+- `<slug>` — kebab-case の機能識別子
+  - validation: `^[a-z0-9][a-z0-9-]{2,48}$` (git-workflow.md branch 規約準拠)
+  - path traversal 防止: `.` `/` `..` を含む値は reject
+  - 例: `loop-mode`, `proxy-rate-limit`, `link-card-componentize`
+
+## 動作
+
+このコマンドが呼ばれたら、メインエージェントは以下 14 stage を順次実行する。各 stage 完了時に `.claude/.workflow-state/<slug>.json` の `current_stage` と `completed_stages` を更新する。
+
+### Stage 1: `requirements` — 要件定義
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- user との対話で WHAT (何を作るか) / WHY (なぜ作るか) を確定
+- `/new-draft <slug>` を起動して `docs/draft/<slug>.md` を `_DRAFT_TEMPLATE.md` から生成
+- draft §1 (真因サマリ / 課題サマリ) を埋める
+- 完了条件: §1 が user 確認済み
+- 完了したら state JSON `current_stage` を `basic-design` に進め、`completed_stages` に `requirements` を追加
+
+### Stage 2: `basic-design` — 基本設計
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- draft §2 (解決アプローチ比較) を埋める
+- 複数案 (最小 2 案) + 工数 + メリット/デメリット表
+- Wave 分割の方針を user に提示
+- 完了条件: 採用案が user 承認済み
+- 完了したら state JSON を更新し `detailed-design` に進む
+
+### Stage 3: `detailed-design` — 詳細設計
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- draft §3 (採用案の詳細設計 / Wave / Sub-task 分割) を埋める
+- API endpoint / データモデル / UI コンポーネント / DB schema を具体化
+- 影響範囲を明示 (ファイル path レベル)
+- 完了条件: §3 が user 確認済み
+- 完了したら state JSON を更新し `test-design` に進む
+
+### Stage 4: `test-design` — テスト設計 (W1)
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- `/test-design <slug>` を実行
+- MECE 20 カテゴリ表が `docs/draft/<slug>.test-design.md` に生成される
+- 採用/不採用を user が全行確認 (不採用には必ず理由)
+- 完了条件: 全 20 行が ☑/☒ で確定 + user スコープ承認済み
+- 完了したら state JSON を更新し `design-review` に進む
+
+### Stage 5: `design-review` — 設計レビュー fan-out (W2)
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- `/design-review <slug>` を実行
+- `reviewer_registry_design` + `reviewer_registry_security` カテゴリの全 agent を **並列 fan-out** (`run_in_background: true` 必須)
+- 各 agent からの findings を `docs/draft/<slug>-review.md` に集約
+- TaskCreate で全 subagent を登録 (subagent_id を metadata 記録)
+- 完了条件: CRITICAL/HIGH 件数 0 件、もしくは draft 修正後再 review で 0 件
+- 完了したら state JSON を更新し `user-approval` に進む
+
+### Stage 6: `user-approval` — user 承認
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- user に draft 承認依頼 (review 集約結果を提示)
+- 承認履歴を `docs/draft/<slug>.md` §8 に記録 (日付 + 承認者 + 結果)
+- 完了条件: §8 に「承認」エントリが追加された
+- 完了したら state JSON を更新し `task-creation` に進む
+
+### Stage 7: `task-creation` — タスク化
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- `/new-task <id> <slug>` を実行
+- `_TASK_TEMPLATE.md` から `docs/tasks/task-<id>-<slug>.md` 生成
+- `docs/tasks/list.md` に `🔲 未着手` 行追加
+- **`.claude/.workflow-state/<slug>.json` を初期化** (`workflow_type=new`, `current_stage=task-creation`, `completed_stages` は Stage 1〜6 を列挙, `pending_findings={module_review:[],system_review:[]}`, `skip_log=[]`, `created_at` `updated_at`)
+- 完了条件: state JSON が作成され、task ファイル + list.md 行が存在
+- 完了したら state JSON を更新し `tdd` に進む
+
+### Stage 8: `tdd` — TDD 実装
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- `/start-task <id>` で着手 (branch 切替 + status 同期)
+- RED: 採用テスト (Stage 4 で確定) を `tests/` に追加し、FAIL を確認
+- GREEN: 最小実装で PASS させる
+- REFACTOR: behavior-preserving で整理
+- **テスト経由でしか実装しない** (テスト先行を厳守)
+- 実装は subagent 経由 (メインは `src/` `tests/` 直接編集禁止)
+- 完了条件: モジュール毎の単体テストが全 PASS
+- 完了したら state JSON を更新し `module-review` に進む
+
+#### 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 再計画コストが発生する。
+
+### Stage 9: `module-review` — モジュール単位レビュー (W3)
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- 変更があった各モジュールについて `/module-review <module>` を実行
+- refactoring-specialist + code-reviewer + 言語別 reviewer を並列起動
+- 3 観点 (持続可能性 / 汎用性 / 非冗長化) で findings 収集
+- 検出された findings を state JSON の `pending_findings.module_review` 配列に追加 (id / severity / summary)
+- CRITICAL/HIGH を修正 (subagent 経由) し、対応済 finding を `pending_findings.module_review` から除去
+- 完了条件: `pending_findings.module_review` が空、または残存は MEDIUM/LOW のみ + user 承認済
+- 完了したら state JSON を更新し `local-test` に進む
+
+### Stage 10: `local-test` — ローカル全テスト green
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- 採用テスト全カテゴリを実行 (subagent 経由)
+- 単体 / 統合 / E2E / smoke 等、`<slug>.test-design.md` で ☑ にしたもの全て
+- 完了条件: 全 PASS
+- FAIL 時は Stage 8 (tdd) に戻る (state JSON `current_stage` を `tdd` に戻し、`completed_stages` からは除去しない=再実行扱い)
+- 完了したら state JSON を更新し `system-review` に進む
+
+### Stage 11: `system-review` — 全体統合レビュー (W3)
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- `/system-review --slug <slug>` を実行
+- architect-reviewer + refactoring-specialist + code-reviewer を並列起動
+- モジュール間重複 / 横断的責務漏れ / 設計乖離 を検出
+- findings を state JSON の `pending_findings.system_review` 配列に追加
+- CRITICAL/HIGH を修正、対応済を pending から除去
+- 完了条件: `pending_findings.system_review` が空、または残存は MEDIUM/LOW のみ + user 承認済
+- 完了したら state JSON を更新し `ci-cd` に進む
+
+### Stage 12: `ci-cd` — CI/CD 適用 (skippable)
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- `.github/workflows/` 等の CI/CD 設定を更新 (必要時のみ)
+- **skip 可能 stage**: `.claude/mode.yml` の `asana_enabled: false` プロジェクトでは default skip 推奨
+- skip する場合: state JSON `skip_log` 配列に `{stage:"ci-cd", reason:"<skip 理由>", user_approved_at:"<ISO-8601 UTC>"}` を追加
+- 完了条件: CI/CD 適用済 OR skip ログ記録済
+- 完了したら state JSON を更新し `scenario-test` に進む
+
+### Stage 13: `scenario-test` — シナリオテスト
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- user 主導でシナリオを実行、または `e2e-runner` agent を起動 (`run_in_background: true`)
+- `<slug>.test-design.md` で ☑ にしたシナリオテスト / E2E を全て実施
+- 完了条件: 全シナリオ PASS
+- FAIL 時は該当 stage (tdd / module-review) に戻る (state JSON の `current_stage` を巻き戻し)
+- 完了したら state JSON を更新し `finish` に進む
+
+### Stage 14: `finish` — 完了
+
+このコマンドが呼ばれたら、メインエージェントは以下の手順を実行してください:
+
+- `/finish-task <id>` を実行
+- **workflow-guard.sh** が PreToolUse(Bash) で `/finish-task` 起動を検知し、state JSON を検証:
+  - 14 stage 全てが `completed_stages` に含まれているか
+  - `pending_findings.module_review` `pending_findings.system_review` が空 (または MEDIUM/LOW のみ + skip_log 記載)
+  - 不足があれば BLOCK + 「Stage X が未完了」「pending finding ID-YYY が未対応」と提示
+- 検証 PASS で `/finish-task` が継続:
+  - `docs/tasks/list.md` の該当行を `done` 化
+  - commit + push (CLAUDE.md "Autonomous Progression" 準拠)
+- 完了報告フォーマット:
+  ```
+  #<id> <タスク名> 完了。
+  14-stage workflow 通過、累計 +<N> tests、commit <count>、push 済 <URL>。
+  ```
+
+## State 管理
+
+`.claude/.workflow-state/<slug>.json` を SSoT として各 stage 完了時に以下を更新:
+
+- `current_stage` — 次に進む stage 名 (`HC_WORKFLOW_STAGES_NEW` の値と一致)
+- `completed_stages` — 完了済 stage 名の配列 (順序保持)
+- `pending_findings` — module-review / system-review で発生した未解決 findings
+- `skip_log` — skip された stage の audit ログ
+- `updated_at` — ISO-8601 UTC
+
+schema 詳細: [`.claude/.workflow-state/SCHEMA.md`](../.workflow-state/SCHEMA.md)
+
+state JSON が存在しない場合、Stage 7 (`task-creation`) で初期化する。Stage 1〜6 は state JSON 作成前なので、メインは内部で stage 進行を追跡し、Stage 7 到達時に `completed_stages` に 1〜6 を列挙する。
+
+## Skip ルール
+
+| Stage | skippable | default |
+|---|:---:|---|
+| `requirements` | × | 必須 |
+| `basic-design` | × | 必須 |
+| `detailed-design` | × | 必須 |
+| `test-design` | × | 必須 |
+| `design-review` | × | 必須 |
+| `user-approval` | × | 必須 |
+| `task-creation` | × | 必須 |
+| `tdd` | × | 必須 |
+| `module-review` | × | 必須 |
+| `local-test` | × | 必須 |
+| `system-review` | × | 必須 |
+| `ci-cd` | ○ | `asana_enabled=false` で default skip |
+| `scenario-test` | △ | user 明示承認時のみ skip 可 |
+| `finish` | × | 必須 |
+
+skip する場合は state JSON `skip_log` に必ず以下を記録:
+
+```json
+{
+  "stage": "<stage-name>",
+  "reason": "<user が提示した skip 理由>",
+  "user_approved_at": "<ISO-8601 UTC 秒精度 Z suffix>"
+}
+```
+
+`ci-cd` 以外を skip する際は **user 明示承認必須**。承認なしで skip した場合は workflow-guard.sh が Stage 14 (`finish`) で BLOCK する。
+
+## workflow-guard.sh との連携
+
+`/finish-task` 起動時、`workflow-guard.sh` が PreToolUse(Bash) hook で発火し、state JSON を検証:
+
+1. `.claude/.workflow-state/<slug>.json` を読む (slug は branch 名 / task ファイル / `docs/work.md` から解決)
+2. `completed_stages` が `HC_WORKFLOW_STAGES_NEW` の 14 stage 全てを含むか確認
+3. `pending_findings.module_review` と `pending_findings.system_review` を確認:
+   - CRITICAL/HIGH が残っていれば BLOCK
+   - MEDIUM/LOW のみ残存 + `skip_log` に該当 finding の skip 理由あり → 通過
+4. skip された stage は `skip_log` エントリが存在することを確認 (`reason` + `user_approved_at` 両必須)
+5. 検証失敗時は stderr に「Stage X 未完了 / Finding ID-YYY 未対応 / skip_log エントリ不足」を出力して exit 2 (BLOCK)
+6. 検証 PASS で `/finish-task` が継続
+
+bypass: `ECC_WORKFLOW_GUARD=off` (緊急用、`bypass.log` に audit 記録される)
+
+## 制約
+
+- 各 stage は順序固定。前 stage 未完了で次に進むと workflow-guard.sh が BLOCK
+- subagent 起動は **必ず** `run_in_background: true` + TaskCreate (CLAUDE.md §1 §4)
+- `<slug>` validation 違反は即 reject (path traversal 防止)
+- state JSON 更新は subagent でも main でも可だが、整合性責任は main にある (CLAUDE.md §2 順序整合性)
+- bypass env (`ECC_WORKFLOW_GUARD=off`) は緊急時のみ、`bypass.log` で audit
+
+## Loop モード時の特例
+
+- 各 stage 間で「進めてもよいですか?」を聞かない (Loop モード「中間確認の停止」原則)
+- Why × 5 評価で推奨を即採用
+- ただし `user-approval` (Stage 6) は本質的に user 承認が必要なので確認する (Loop モードでも例外)
+- `pending_findings` の CRITICAL/HIGH 修正は自動適用 (subagent 経由、behavior-preserving)
+
+## 関連
+
+- `/test-design <slug>` — Stage 4 (W1)
+- `/design-review <slug>` — Stage 5 (W2)
+- `/new-task <id> <slug>` — Stage 7
+- `/start-task <id>` — Stage 8 着手
+- `/module-review <module>` — Stage 9 (W3)
+- `/system-review` — Stage 11 (W3)
+- `/finish-task <id>` — Stage 14
+- config: `.claude/harness-config.yml` の `workflow_stages_new` (= env `HC_WORKFLOW_STAGES_NEW`)
+- state schema: [`.claude/.workflow-state/SCHEMA.md`](../.workflow-state/SCHEMA.md)
+- template: `.claude/templates/docs/tasks/_TASK_TEMPLATE.md` (frontmatter 拡張済)
+- hook: `.claude/hooks/workflow-guard.sh` (W4-guard で実装予定)
+- 設計 draft: [`docs/draft/workflow-enforcement.md`](../../docs/draft/workflow-enforcement.md) §3 W4
+- 既存 modify workflow: `/modify-feature <slug>` (10-stage、別 command)