@arimakouyou/spec-workflow-mcp 2.2.7

package/.claude-plugin/skills/integration-test/references/whiteboard-template.md

@@ -0,0 +1,81 @@
+# ホワイトボードテンプレート
+
+Command が P1 で作成するホワイトボード。
+作成場所: `.claude/_docs/plans/integ-test-wb-{timestamp}.md`
+
+---
+
+```markdown
+# Integration Test Whiteboard
+
+## Goal
+{対象ドメインのインテグレーションテストを作成する}
+
+## Team Structure
+| Role | Name | Assignment |
+|------|------|-----------|
+| Command | main | 司令塔 |
+| Worker alpha | agent-alpha | {domain_a} |
+| Worker bravo | agent-bravo | {domain_b} |
+| Pentagon | agent-pentagon | 品質レビュー |
+
+## How Our Work Connects
+- alpha と bravo は独立したテストファイルを担当する
+- 共通ヘルパー（TestContext 等）は Command が事前に準備する
+- Pentagon は各 Worker の成果物を品質ゲートで審査する
+
+## Key Questions
+1. {Worker 間で共有すべき問い — 例: 認証エラーのレスポンス構造は共通か？}
+2. {例: テストデータの seed パターンに共通化できる部分は？}
+
+## Shared Resources
+- tests/integration/helpers/mod.rs — 共通ヘルパー
+- tests/integration/helpers/app.rs — テスト用 Axum app 構築
+- tests/integration/helpers/db.rs — testcontainers セットアップ
+
+## File Assignment
+| Worker | File | Status |
+|--------|------|--------|
+| alpha | tests/integration/test_{domain_a}.rs | pending |
+| bravo | tests/integration/test_{domain_b}.rs | pending |
+
+## Analysis Summary
+### {domain_a}
+- Endpoints: {endpoint_list}
+- External deps: {deps}
+
+### {domain_b}
+- Endpoints: {endpoint_list}
+- External deps: {deps}
+
+## Alpha Findings
+(Worker alpha が記入 — Command が転記)
+
+## Bravo Findings
+(Worker bravo が記入 — Command が転記)
+
+## Pentagon Reviews
+| File | Cycle | Result | Notes |
+|------|:-----:|:------:|-------|
+
+## Cross-Cutting Observations
+(チーム全体で共有すべき発見)
+
+## Quality Gate Results
+| File | Status | Reviewer |
+|------|:------:|----------|
+```
+
+---
+
+## 読み書きルール
+
+| 操作 | 誰が | いつ |
+|------|------|------|
+| 作成 | Command | P1 |
+| Key Questions 設定 | Command | P1 |
+| Analysis Summary 記入 | Command | P0 完了時 |
+| Worker Findings 転記 | Command | Worker 完了時 |
+| Pentagon Reviews 記入 | Command | Pentagon レビュー完了時 |
+| Quality Gate Results 更新 | Command | Pentagon PASS 時 |
+| 削除（`.claude/_docs/deleted/` へ移動） | Command | P5 |

package/.claude-plugin/skills/integration-test/references/worker-prompt.md

@@ -0,0 +1,70 @@
+# Worker プロンプトテンプレート
+
+Worker（alpha/bravo）起動時に展開するプロンプト。
+`{変数}` は Command が起動時に埋め込む。
+
+---
+
+```
+あなたは integration-test Worker「{worker_name}」です。
+
+## 担当
+- ドメイン: {domain}
+- テストファイル: tests/integration/test_{domain}.rs
+- 対象エンドポイント:
+{endpoint_list}
+
+## 作業手順
+
+### 1. ホワイトボード読取（最重要）
+{whiteboard_path} を Read し、以下を確認する:
+- Key Questions（他の Worker と共有すべき問い）
+- Shared Resources（共通ヘルパー、テスト用データ構造）
+- 他の Worker の Findings（あれば）
+
+### 2. コンテキスト確認
+以下のファイルを Read して対象 API を理解する:
+- src/handlers/{domain}.rs（handler 定義）
+- src/db/repository/{domain}.rs（リポジトリ層）
+- src/models/{domain}.rs（Diesel モデル）
+- src/dto/{domain}.rs（リクエスト/レスポンス型）
+- tests/integration/helpers/（共通ヘルパー）
+
+### 3. テストケース設計
+references/test-case-design.md の 5 分類に従い、テストケースを列挙する。
+各エンドポイントに対して正常系・異常系・境界値・エッジケース・外部依存を考慮する。
+
+### 4. テスト実装
+references/test-patterns.md のパターンに従い実装する。
+- Given-When-Then 構造を守る
+- TestContext を使用する
+- 外部 API は trait DI でテストダブルに差し替える（references/external-api-mock.md 参照）
+
+### 5. 品質セルフチェック
+references/quality-gate.md の全項目を自己チェックする。
+Pentagon に差し戻されるとサイクルが増えるため、事前に品質を担保する。
+
+### 6. 完了報告
+
+```
+[Worker {worker_name} 完了]
+テストファイル: tests/integration/test_{domain}.rs
+テストケース数: {count}
+  - 正常系: {n}
+  - 異常系: {n}
+  - 境界値: {n}
+  - エッジケース: {n}
+  - 外部依存: {n}
+実行結果: cargo test --test integration_{domain} → PASS / FAIL
+発見事項: {findings}
+```
+
+## 禁止事項
+- tests/integration/helpers/ の共通ヘルパーを勝手に変更しない（Command に報告）
+- 本番コードを変更しない
+- `#[ignore]` でテストをスキップしない
+- `sleep` でタイミング依存テストを書かない
+
+## Pentagon 差し戻し時
+差し戻しの指摘事項に従い修正する。修正後は再度セルフチェックを行い完了報告する。
+```

package/.claude-plugin/skills/knowhow-capture/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: knowhow-capture
+description: >
+  A skill for accumulating user feedback, corrections, and instructions as know-how in `.claude/_docs/know-how/`.
+  Provides step-by-step procedures for recording know-how (domain selection, duplicate check, file creation, INDEX update).
+  Triggers when the user says "remember this", "do this from now on", "remember", or "add to know-how",
+  or when the feedback-loop rule detects feedback and instructs a recording.
+  Can also be explicitly invoked with /knowhow-capture.
+---
+
+# Know-how Capture
+
+A skill for accumulating practical team knowledge gained through interactions with the user into `.claude/_docs/know-how/`,
+so the same mistakes are not repeated in future tasks.
+
+Personal preferences and working styles should be recorded in the built-in memory system, not here.
+
+## Two Recording Patterns
+
+### Pattern A: Explicit Recording (User-Directed)
+
+When the user says "remember this", "add to know-how", or "do this from now on".
+Record immediately without asking for confirmation.
+
+**Trigger examples:**
+- "Remember this"
+- "Add this to know-how"
+- "Do it this way from now on"
+- "remember this"
+
+**Behavior:** Immediately create the know-how file and update INDEX.md.
+
+### Pattern B: Suggested Recording (Detection + Confirmation)
+
+The AI detects a user correction or instruction and proposes "Shall I record this as know-how?".
+Record only if the user approves.
+
+**Trigger conditions:**
+- The user clearly corrected the AI's output or judgment ("That's not right, it should be...", "No, it's...")
+- The user rejected the AI's approach and directed a different method
+- The user shared a project-specific convention or rule
+- The same type of correction was received 2 or more times within the same session
+
+**Behavior:**
+1. Summarize the correction and present it
+2. Ask "Shall I record this knowledge as know-how?"
+3. Record if the user approves
+
+**Suggestion format:**
+
+```
+[know-how suggestion] The following knowledge can be recorded:
+- Summary: {one-line summary of the correction}
+- Domain: {testing / workflow / conventions / ...}
+Shall I add this to know-how?
+```
+
+## Step-by-Step Recording Procedure
+
+### Step 1: Determine the Domain
+
+Select a domain based on the content of the know-how.
+
+| Domain | Content |
+|--------|---------|
+| testing | Knowledge about test design, structure, and execution |
+| workflow | Knowledge about development flow, Git operations, CI/CD |
+| conventions | Naming conventions, directory structure, code style |
+| architecture | Layer structure, DI, design decisions |
+| debugging | Debugging techniques, error handling, performance |
+
+If the content does not fit an existing domain, a new domain may be created.
+
+### Step 2: Duplicate Check
+
+Read `.claude/_docs/know-how/INDEX.md` and confirm that the same know-how does not already exist.
+If a duplicate exists, update the existing file rather than creating a new one.
+
+### Step 3: Create the File
+
+Create `.claude/_docs/know-how/{domain}/{slug}.md` using the following format:
+
+```markdown
+---
+created: {YYYY-MM-DD}
+domain: {domain}
+source: user-feedback
+---
+
+# {Title (concise)}
+
+## Summary
+
+{Describe the core of the knowledge in 1-2 sentences}
+
+## Background
+
+{Why this knowledge is needed, and in what situation it arose}
+
+## Checklist
+
+- [ ] {Item to verify during implementation 1}
+- [ ] {Item to verify during implementation 2}
+
+## Counter-example
+
+{What happens if this knowledge is ignored}
+```
+
+**Constraints:**
+- Aim for 50 lines or fewer (consider splitting if longer)
+- `created`, `domain`, and `source` fields in frontmatter are required
+
+### Step 4: Update INDEX.md
+
+Add one row to the relevant domain table in `.claude/_docs/know-how/INDEX.md`.
+If the domain section does not exist, add a new section.
+
+## Pattern Decision Flowchart
+
+```
+Detect user's statement
+  │
+  ├─ Explicit instruction like "remember this" or "remember"?
+  │   └─ YES → Pattern A (record immediately)
+  │
+  ├─ Did the user correct or reject the AI's judgment?
+  │   └─ YES → Pattern B (suggest and confirm)
+  │
+  ├─ Did the user share a project-specific convention?
+  │   └─ YES → Pattern B (suggest and confirm)
+  │
+  └─ Same correction received 2 or more times?
+      └─ YES → Pattern B (suggest and confirm)
+```
+
+## Notes
+
+- **Distinction from memory**: "Should teammates also know this?" → Yes = know-how, No = built-in memory
+- Do not write temporary state (current branch name, tasks in progress, etc.) to know-how
+- Know-how is meant for "practical knowledge"; established rules should be promoted to `.claude/rules/`
+- If the user says "make it a rule", promote the know-how to a rule in `.claude/rules/`
+- Staging and committing files after creation should only be done when the user explicitly requests it

package/.claude-plugin/skills/phase-review-team/SKILL.md

@@ -0,0 +1,380 @@
+---
+name: phase-review-team
+description: "Phase completion expert team review. Assembles a multi-disciplinary review team to perform comprehensive code review before Phase commit. Each expert independently analyzes the code from their specialty perspective, then a leader consolidates findings into a prioritized final report saved to file. Triggers on: Phase review tasks (_PhaseReview: true) in spec-implement workflow, or explicit '/phase-review-team' invocation."
+---
+
+# Phase Review — Expert Team Review
+
+Phase 完了時にコミット前に実施する、専門家チームによる多角的コードレビュー。
+
+## Overview
+
+各 Phase の成果物に対して、5 名の専門家が独立して調査を行い、具体的な問題箇所と改善案を報告する。リーダーは各報告を統合し、優先度付きの最終レポートを作成してファイルに保存する。
+
+## Inputs
+
+- **spec-name**: スペック名（kebab-case）
+- **phase-number**: 対象 Phase 番号
+- **changed-files**: Phase で変更されたファイル一覧
+- **project-path**: プロジェクトルートパス
+- **integration-verification**: 統合検証結果（3.5.1.5 で取得。各ステップの PASS/FAIL/SKIP と詳細）
+
+## Expert Team Composition
+
+| Role | Perspective |
+|------|-------------|
+| **実装担当** | 仕様書にある機能を網羅しているか、仕様を逸脱していないか |
+| **セキュリティ担当1** | 認証、認可、データ漏洩 |
+| **セキュリティ担当2** | OWASP TOP 10、最新の CVE |
+| **パフォーマンス担当** | ボトルネック、計算量、リソース効率 |
+| **品質・保守性担当** | テストカバレッジ、読みやすさ、命名規則、DRY 原則 |
+
+## Execution Steps
+
+### 1. Assemble and Dispatch (Parallel)
+
+5 名の専門家を **並列** で起動する。各専門家は Agent tool で起動し、独立して調査・報告を行う。
+
+```javascript
+// 実装担当
+Agent({
+  subagent_type: "general-purpose",
+  description: "Phase review: spec compliance",
+  prompt: `あなたは実装レビューの専門家です。Phase {phase-number} で変更されたコードを、仕様書の観点からレビューしてください。
+
+    プロジェクトパス: {project-path}
+    スペック名: {spec-name}
+    変更ファイル: {changed-files}
+
+    統合検証結果:
+    - ビルド: {integration-verification.build}
+    - 統合テスト: {integration-verification.integration-tests}
+    - スモークテスト: {integration-verification.smoke-test}
+
+    レビュー観点:
+    - 仕様書（requirements.md, design.md）にある機能をすべて網羅しているか
+    - 仕様を逸脱した実装がないか
+    - design.md のAPI定義（パス、メソッド、リクエスト/レスポンス型）との整合性
+    - tasks.md の各タスクの Success 基準がすべて満たされているか
+
+    参照ファイル:
+    - {project-path}/.spec-workflow/specs/{spec-name}/requirements.md
+    - {project-path}/.spec-workflow/specs/{spec-name}/design.md
+    - {project-path}/.spec-workflow/specs/{spec-name}/tasks.md
+
+    レポート形式:
+    ## 実装担当レビュー
+    ### 発見事項
+    各発見事項について以下を記載:
+    - ファイル: (パスと行番号)
+    - 深刻度: Critical / Major / Minor
+    - 問題: (具体的な説明)
+    - 改善案: (具体的な修正方法)
+    ### 総合評価
+    - 仕様カバレッジ: X/Y (実装済み/仕様数)
+    - 仕様逸脱: あり/なし`
+})
+
+// セキュリティ担当1
+Agent({
+  subagent_type: "general-purpose",
+  description: "Phase review: auth & data security",
+  prompt: `あなたはセキュリティレビューの専門家（認証・認可・データ保護）です。Phase {phase-number} で変更されたコードをレビューしてください。
+
+    プロジェクトパス: {project-path}
+    変更ファイル: {changed-files}
+
+    統合検証結果:
+    - ビルド: {integration-verification.build}
+    - 統合テスト: {integration-verification.integration-tests}
+    - スモークテスト: {integration-verification.smoke-test}
+
+    ★重要: 最新のセキュリティ情報に基づいてレビューすること★
+    レビュー開始前に、以下の情報を取得してください:
+
+    【WebSearch が利用可能な場合】
+    1. 使用しているフレームワーク・ライブラリの最新セキュリティアドバイザリ
+       - 検索例: "{framework名} security advisory {current year}"
+       - 検索例: "{framework名} CVE {current year}"
+    2. 認証・認可に関する最新のベストプラクティス
+       - 検索例: "authentication best practices {current year}"
+       - 検索例: "JWT security vulnerabilities {current year}"
+
+    【WebSearch が利用できない場合のオフラインフォールバック】
+    1. `cargo audit` を実行して既知の脆弱性を検出（RustSec Advisory DB ベース）
+    2. Cargo.toml の依存クレートバージョンを確認し、明らかに古いバージョンを検出
+    3. 自身の学習データに基づくセキュリティベストプラクティスでレビュー
+    4. レポートに「オフラインレビュー: WebSearch 未使用」と明記
+
+    取得した情報をレビューの判断基準に反映させること。
+
+    レビュー観点:
+    - 認証: 認証が必要なエンドポイントにミドルウェアが適用されているか、トークン生成・検証は安全か
+    - 認可: リソースへのアクセス制御、権限チェックの欠落、IDOR 脆弱性
+    - データ漏洩: レスポンスにパスワードハッシュ・内部ID・スタックトレースが含まれていないか、ログへの機密情報出力
+    - セッション管理: セッション固定、セッションハイジャック対策
+    - 暗号: 適切なハッシュアルゴリズム、ソルトの使用、鍵管理
+
+    レポート形式:
+    ## セキュリティレビュー（認証・認可・データ保護）
+    ### 参照した最新セキュリティ情報
+    - (WebSearch で取得した情報のサマリとソース URL)
+    ### 発見事項
+    各発見事項について以下を記載:
+    - ファイル: (パスと行番号)
+    - 深刻度: Critical / Major / Minor
+    - カテゴリ: 認証 / 認可 / データ漏洩 / セッション / 暗号
+    - 根拠: (最新のベストプラクティスや Advisory との照合結果)
+    - 問題: (具体的な説明)
+    - 改善案: (具体的な修正方法)
+    ### 総合評価`
+})
+
+// セキュリティ担当2
+Agent({
+  subagent_type: "general-purpose",
+  description: "Phase review: OWASP & CVE",
+  prompt: `あなたはセキュリティレビューの専門家（OWASP・脆弱性）です。Phase {phase-number} で変更されたコードをレビューしてください。
+
+    プロジェクトパス: {project-path}
+    変更ファイル: {changed-files}
+
+    統合検証結果:
+    - ビルド: {integration-verification.build}
+    - 統合テスト: {integration-verification.integration-tests}
+    - スモークテスト: {integration-verification.smoke-test}
+
+    ★重要: 最新の脆弱性情報に基づいてレビューすること★
+    レビュー開始前に、以下の手順を実行してください:
+
+    手順1: プロジェクトの依存クレートを特定
+    - Cargo.toml を読み、依存クレート名とバージョンを一覧化する
+
+    手順2: 依存クレートの脆弱性を確認
+    【WebSearch が利用可能な場合】
+    - 各クレートの最新 CVE を検索:
+      - 検索例: "{crate名} CVE" (例: "axum CVE", "diesel CVE", "tokio CVE")
+      - 検索例: "{crate名} security advisory {current year}"
+      - 検索例: "RustSec advisory {crate名}"
+      - RustSec Advisory Database (https://rustsec.org/advisories/) も参照
+    - 見つかった CVE について、使用中のバージョンが影響を受けるか確認
+    【WebSearch が利用できない場合のオフラインフォールバック】
+    - `cargo audit` を実行して RustSec Advisory DB から既知の脆弱性を検出
+    - Cargo.toml のバージョンを確認し、明らかに古いバージョンをフラグ
+    - レポートに「オフラインレビュー: WebSearch 未使用、cargo audit ベース」と明記
+
+    手順3: OWASP の最新動向を確認
+    【WebSearch が利用可能な場合】
+    - 検索例: "OWASP TOP 10 latest update"
+    - 検索例: "OWASP {使用フレームワーク} cheat sheet"
+    【WebSearch が利用できない場合】
+    - 自身の学習データに基づく OWASP TOP 10 知識でレビュー
+
+    手順4: 上記の情報を踏まえてコードをレビュー
+
+    レビュー観点:
+    OWASP TOP 10 の各項目について確認:
+    - A01: アクセス制御の不備
+    - A02: 暗号化の失敗
+    - A03: インジェクション（SQL, コマンド, XSS）
+    - A04: 安全でない設計
+    - A05: セキュリティ設定の不備
+    - A06: 脆弱で古くなったコンポーネント
+    - A07: 識別と認証の失敗
+    - A08: ソフトウェアとデータの整合性の不備
+    - A09: セキュリティログとモニタリングの不備
+    - A10: サーバーサイドリクエストフォージェリ (SSRF)
+
+    追加確認:
+    - 手順2 で発見した CVE に該当する使用箇所がないか
+    - cargo audit 相当のチェック（既知の脆弱性を持つバージョンを使用していないか）
+    - 入力バリデーションの漏れ
+    - エラーメッセージによる情報漏洩
+
+    レポート形式:
+    ## セキュリティレビュー（OWASP・CVE）
+    ### 検索した脆弱性情報
+    - (依存クレートごとに検索結果をサマリ、ソース URL を記載)
+    - (該当 CVE があればCVE番号、影響バージョン、対処状況を記載)
+    ### 発見事項
+    各発見事項について以下を記載:
+    - ファイル: (パスと行番号)
+    - 深刻度: Critical / Major / Minor
+    - OWASP カテゴリ: A01-A10 / CVE番号
+    - 根拠: (検索で見つけた CVE/Advisory への参照)
+    - 問題: (具体的な説明)
+    - 改善案: (具体的な修正方法、パッチバージョンがあればそのバージョン番号)
+    ### 総合評価`
+})
+
+// パフォーマンス担当
+Agent({
+  subagent_type: "general-purpose",
+  description: "Phase review: performance",
+  prompt: `あなたはパフォーマンスレビューの専門家です。Phase {phase-number} で変更されたコードをレビューしてください。
+
+    プロジェクトパス: {project-path}
+    変更ファイル: {changed-files}
+
+    統合検証結果:
+    - ビルド: {integration-verification.build}
+    - 統合テスト: {integration-verification.integration-tests}
+    - スモークテスト: {integration-verification.smoke-test}
+
+    レビュー観点:
+    - ボトルネック: N+1 クエリ、不要なループ内 DB アクセス、ブロッキング I/O
+    - 計算量: O(n²) 以上のアルゴリズムがないか、大量データでの挙動
+    - リソース効率: 不要な clone()、メモリ割り当ての最適化、コネクションプール活用
+    - 非同期処理: async/await の適切な使用、不要な .await の連鎖
+    - キャッシュ: キャッシュすべきデータがキャッシュされているか、キャッシュ無効化戦略
+    - DB: インデックスの活用、クエリ最適化、不要なカラムの SELECT
+
+    レポート形式:
+    ## パフォーマンスレビュー
+    ### 発見事項
+    各発見事項について以下を記載:
+    - ファイル: (パスと行番号)
+    - 深刻度: Critical / Major / Minor
+    - カテゴリ: ボトルネック / 計算量 / リソース / 非同期 / キャッシュ / DB
+    - 影響: (推定されるパフォーマンス影響)
+    - 改善案: (具体的な修正方法)
+    ### 総合評価`
+})
+
+// 品質・保守性担当
+Agent({
+  subagent_type: "general-purpose",
+  description: "Phase review: quality & maintainability",
+  prompt: `あなたは品質・保守性レビューの専門家です。Phase {phase-number} で変更されたコードをレビューしてください。
+
+    プロジェクトパス: {project-path}
+    変更ファイル: {changed-files}
+
+    統合検証結果:
+    - ビルド: {integration-verification.build}
+    - 統合テスト: {integration-verification.integration-tests}
+    - スモークテスト: {integration-verification.smoke-test}
+
+    レビュー観点:
+    - テストカバレッジ: 新規コードに対するテストの網羅性、ハッピーパス・異常系・境界値
+    - test-design.md 準拠: test-design.md が存在する場合、該当 Phase のコンポーネントに対する UT 仕様が実装されているか検証する。IT 仕様に定義されたシナリオが統合テストで網羅されているか確認する
+    - 統合テストカバレッジ: Phase の主要機能に対する統合テストが存在するか。統合検証で SKIP された場合、統合テストの追加が必要か評価する
+    - テスト粒度バランス: ユニットテストと統合テストの棲み分けが適切か。ユニットテストのみで統合テストが皆無の場合は指摘する
+    - TDD 遵守: テストが実装を駆動しているか（形骸化の兆候がないか）
+      - is_ok()/is_some() だけのアサーション → 形骸化
+      - ハッピーパスのみ → 不十分
+      - 実装の内部構造に依存したテスト → 設計品質の問題
+    - 読みやすさ: 関数の長さ、ネストの深さ、コメントの適切さ
+    - 命名規則: 型・関数・変数の命名がプロジェクト規約に沿っているか、意図が明確か
+    - DRY 原則: 重複コード、共通化すべきロジック
+    - SOLID 原則: 単一責任、依存性逆転、インターフェース分離
+    - エラーハンドリング: 統一されたエラー型、unwrap() の不適切な使用
+
+    レポート形式:
+    ## 品質・保守性レビュー
+    ### 発見事項
+    各発見事項について以下を記載:
+    - ファイル: (パスと行番号)
+    - 深刻度: Critical / Major / Minor
+    - カテゴリ: テスト / TDD / 可読性 / 命名 / DRY / SOLID / エラー処理
+    - 問題: (具体的な説明)
+    - 改善案: (具体的な修正方法)
+    ### 総合評価`
+})
+```
+
+### 2. Consolidate (Leader)
+
+全専門家のレポートが返ってきたら、リーダー（オーケストレーター自身）が統合する。
+
+#### 2.1 統合レポートの作成
+
+全発見事項を以下の優先度で分類:
+
+| Priority | Criteria | Action |
+|----------|----------|--------|
+| **P0 — Blocker** | Critical なセキュリティ脆弱性、仕様の重大な逸脱 | コミット不可。即座に修正が必要 |
+| **P1 — Must Fix** | Major な問題（セキュリティ、設計、仕様準拠） | コミット前に修正が必要 |
+| **P2 — Should Fix** | Minor な問題（パフォーマンス改善、コード品質向上） | このPhaseで修正推奨。次Phase送りも可 |
+| **P3 — Nice to Have** | 提案レベル（命名改善、コメント追加等） | 改善推奨だがブロッカーではない |
+
+#### 2.2 レポートファイルの保存
+
+```
+.spec-workflow/specs/{spec-name}/reviews/phase-{phase-number}-review.md
+```
+
+レポートフォーマット:
+
+```markdown
+# Phase {phase-number} Expert Team Review
+
+**Date**: {date}
+**Spec**: {spec-name}
+**Phase**: {phase-number}
+**Reviewers**: 実装担当, セキュリティ担当1, セキュリティ担当2, パフォーマンス担当, 品質・保守性担当
+
+## Summary
+
+| Priority | Count | Action Required |
+|----------|-------|-----------------|
+| P0 — Blocker | {n} | Must fix before commit |
+| P1 — Must Fix | {n} | Must fix before commit |
+| P2 — Should Fix | {n} | Fix recommended |
+| P3 — Nice to Have | {n} | Optional |
+
+## Verdict: {PASS / NEEDS_REWORK / BLOCK}
+
+{1-2 sentence summary of overall assessment}
+
+---
+
+## P0 — Blocker
+
+{findings sorted by priority, each with file, line, reviewer, problem, and suggested fix}
+
+## P1 — Must Fix
+
+{...}
+
+## P2 — Should Fix
+
+{...}
+
+## P3 — Nice to Have
+
+{...}
+
+---
+
+## Individual Reports
+
+### 実装担当
+{full report}
+
+### セキュリティ担当1（認証・認可・データ保護）
+{full report}
+
+### セキュリティ担当2（OWASP・CVE）
+{full report}
+
+### パフォーマンス担当
+{full report}
+
+### 品質・保守性担当
+{full report}
+```
+
+### 3. Verdict and Action
+
+| Verdict | Condition | Action |
+|---------|-----------|--------|
+| **PASS** | P0 = 0, P1 = 0 | review-worker にコミットを委譲 |
+| **NEEDS_REWORK** | P0 = 0, P1 > 0 | P1 の発見事項を parallel-worker に差し戻し。修正後に再度チームレビュー |
+| **BLOCK** | P0 > 0 | ユーザーにエスカレート。Critical なセキュリティ問題や仕様の根本的な逸脱 |
+
+### 4. Re-review Policy
+
+- NEEDS_REWORK 後の再レビューは **変更された箇所のみ** を対象とする（全体の再レビューは不要）
+- 再レビューは最大 2 回まで。解消しない場合はユーザーにエスカレート
+- PASS 後は review-worker の通常フロー（コミット）に進む