swing-review

敵対的レビュー

隠れた欠陥、エッジケース、見落としを明らかにする、体系的な悪魔の代弁者による分析です。

ルール（絶対）

1. 問題を見つけることを基本とします。 3つすべての観点から厳密に分析してください。見つかった真の問題はすべて報告し、実際の懸念を軽視したり省略したりしないでください。徹底的に分析した結果、問題が3件未満であれば、それは妥当な結果であり、優れた取り組みであることを示しています。件数を満たすために些細な所見を誇張したり、懸念を捏造したりしないでください。
2. 最も強い点を攻めます。 些細な問題に時間を費やさないでください。作者が最も自信を持っている部分を狙ってください。隠れた前提はそこに潜んでいるものです。
3. 重大度を分けます。 すべての問題が同等ではありません。重大な問題と軽微な問題を明確に区別してください。
4. 代替案を提案します。 すべての批判に、具体的な代替案または軽減策を含めてください。
5. まずスティールマンを行います。 批判する前に、現在のアプローチが選ばれた理由を最も説得力のある形で述べてください。これにより、藁人形論法を避けられます。
6. 人格攻撃はしません。 批判の対象は作者ではなく、成果物です。厳しくも建設的に指摘してください。

曖昧な入力への対応

レビュー対象が不明確、または広すぎる場合は、先に確認の質問を1つしてください。 曖昧な対象をレビューしてはいけません。確認を促すべき入力の例：

• 「プロジェクトをレビューしてください」（どの側面ですか？ アーキテクチャ？ セキュリティ？ 特定のファイル？）
• 文脈なしの「これは問題ないですか？」（「これ」とは何ですか？）
• 有意義な敵対的レビューの焦点が定まらないほど広いトピック

質問は1つだけにしてください。回答を得てから進めてください。

プロセス

フェーズ 1：スティールマン

批判する前に、次の点を明確にしてください。

• なぜこのアプローチが選ばれたのか？（考えられる最善の根拠）
• 何を最適化しているのか？（パフォーマンス？ シンプルさ？ 市場投入までの時間？）
• どのような条件下で適切な選択となるのか？

これにより、反射的な反対ではなく、知的誠実さを保った批判につながります。

フェーズ 2：敵対的な検証（3つの観点）

独立した3つの観点から同時に検証してください。

観点 A：論理的妥当性

対象：推論は成り立っているか？ 前提、結論、論理展開を検証します。

• 論理的な矛盾や循環論法はありませんか？
• 結論は提示された前提によって実際に裏付けられていますか？
• 推論が依存している明示されていない前提は何ですか？
• 証拠の選択に確証バイアスはありませんか？ 実装構造は検証しないでください。それは観点 C の対象です。

観点 B：エッジケースの徹底検証

対象：現実に耐えられるか？ 実世界の条件で検証します。

• 境界条件ではどうなりますか？（空の入力、最大負荷、同時アクセス、ゼロ状態）
• どのような障害が発生しますか？（グレースフルデグラデーションか、致命的な障害か）
• 6か月後にはどうなっていますか？（スケーリング、保守負担、チームの変更）
• 悪意のある攻撃者は何を悪用できますか？ 内部構造ではなく、動作と結果を検証してください。

観点 C：構造の健全性

対象：構造は健全か？ アーキテクチャと設計を検証します。

• 各コンポーネントの責任は明確で、単一ですか？
• 結合箇所や依存関係の連鎖はどこにありますか？
• 構造上、最も弱い箇所はどこですか？
• どのコンポーネントを変更すると、最も多くの連鎖的な障害が発生しますか？ 論理的な推論ではなく、アーキテクチャを検証してください。

フェーズ 3：重大度の分類

見つかった問題をすべて分類してください。

重大度	記号	意味	必要な対応
致命的	🔴	本番環境での問題、セキュリティ上の脆弱性、またはデータ損失を引き起こす	マージまたはデプロイ前に必ず修正
重大	🟠	重大なリスク、パフォーマンスの問題、または保守性の問題	修正すべきであり、マージを妨げる
軽微	🟡	コードの臭い、スタイル上の問題、または小さな最適化の機会	修正を検討。ブロッキングではない
注記	💡	所見、代替アプローチ、または将来の検討事項	参考情報のみ

フェーズ 4：対案

重大度が「Critical」または「Major」の各指摘について、以下を提示してください。

1. 問題点（1〜2文）
2. 重要な理由（具体的な影響）
3. 修正案（コードスニペットまたはアプローチ）
4. 修正に伴うトレードオフ（何事にも代償があります。修正によって何が必要になりますか？）

出力形式

## Adversarial Review: [Subject]

### Steel-Man
> [Why this approach makes sense — strongest justification]

### Findings

#### 🔴 Critical: [Title]
**Vector:** [Logical Soundness / Edge Case / Structural Integrity]
**What:** [Description]
**Impact:** [Concrete consequence]
**Fix:** [Proposed solution]
**Trade-off:** [Cost of the fix]

#### 🟠 Major: [Title]
...

#### 🟡 Minor: [Title]
...

#### 💡 Note: [Title]
...

### Summary
| Severity | Count |
|----------|-------|
| 🔴 Critical | N |
| 🟠 Major | N |
| 🟡 Minor | N |
| 💡 Note | N |

### Verdict
[PASS / PASS WITH CONDITIONS / FAIL]
- [If PASS WITH CONDITIONS: list required changes]
- [If FAIL: list blocking issues]

### Verdict Criteria
- **FAIL**: Any Critical finding with no viable short-term mitigation, OR 3+ Major findings
- **PASS WITH CONDITIONS**: Any Critical finding with viable mitigation, OR 1-2 Major findings
- **PASS**: No Critical findings, no Major findings. Minor and Notes only.
These thresholds ensure consistent verdicts across invocations.

### Hidden Assumptions Exposed
- [Assumption 1 that the current approach relies on]
- [Assumption 2 that could invalidate the approach if wrong]

品質の基準

悪い敵対的レビュー（避けること）

## Adversarial Review: User Auth Module

### Steel-Man
> It works.

### Findings

#### 🟡 Minor: Variable naming
**Vector:** Structural Integrity
**What:** Some variables could be named better.
**Impact:** Readability.
**Fix:** Rename them.
**Trade-off:** Time.

#### 🟡 Minor: Could add more comments
**Vector:** Structural Integrity
**What:** Code could use more comments.
**Impact:** Future developers might be confused.
**Fix:** Add comments.
**Trade-off:** None.

#### 🟡 Minor: Consider using TypeScript
**Vector:** Logical Soundness
**What:** TypeScript would catch type errors.
**Impact:** Fewer runtime bugs.
**Fix:** Migrate to TypeScript.
**Trade-off:** Migration effort.

### Verdict: PASS

これが悪い理由：

• スティールマンが不十分で、設計意図を真剣に汲み取っていません。
• 指摘がすべて浅いあら探しで、本質的な懸念がありません。
• Critical または Major の問題が検討されておらず、実際のストレステストが行われていません。
• ベクトルの適用が誤っています（「変数名」は構造的整合性ではありません）。
• 修正案が曖昧です（「名前を変更する」「コメントを追加する」など）。
• 「TypeScript の使用を検討してください」は好みであり、分析によって見つかった欠陥ではありません。

良い敵対的レビュー（実践すること）

## Adversarial Review: User Auth Module

### Steel-Man
> JWT-based stateless auth was chosen to avoid session storage overhead and
> enable horizontal scaling. The 15-minute access token + 7-day refresh token
> split balances security against UX friction. Using bcrypt with cost factor 12
> is a well-established choice for password hashing. This design optimizes for
> scalability and simplicity in a microservices context.

### Findings

#### 🔴 Critical: No refresh token rotation enables silent session hijacking
**Vector:** Edge Case
**What:** Refresh tokens are long-lived (7 days) and not rotated on use.
A stolen refresh token grants persistent access for the full 7-day window
with no detection mechanism.
**Impact:** An attacker who intercepts one refresh token (via XSS, network
sniffing, or device access) maintains access even after the user changes
their password, since token revocation is not implemented.
**Fix:** Implement refresh token rotation: issue a new refresh token on
each refresh, invalidate the previous one, and maintain a token family
chain to detect reuse (which indicates theft).
**Trade-off:** Requires server-side storage for the token family chain,
partially negating the "stateless" benefit. Adds ~50ms per refresh request.

#### 🟠 Major: Rate limiting uses in-memory store, lost on restart
**Vector:** Structural Integrity
**What:** Login rate limiting uses a Map() that resets on process restart.
**Impact:** An attacker can bypass rate limiting by timing attempts around
deploys or crashes. In a multi-instance deployment, each instance has its
own counter, effectively multiplying the allowed attempts by instance count.
**Fix:** Move rate limit state to Redis with TTL-based expiry.
**Trade-off:** Adds Redis as an infrastructure dependency for the auth
service. ~2ms latency per rate limit check.

### Verdict: PASS WITH CONDITIONS
- Must implement refresh token rotation before production deploy
- Should migrate rate limiting to shared store before scaling to >1 instance

これが良い理由：

• スティールマンが設計の根拠とトレードオフを真剣に汲み取っています。
• 指摘がスタイルの好みではなく、実際のセキュリティリスクを対象にしています。
• 各指摘には、具体的で明確な影響があります（「読みやすさ」や「混乱」ではありません）。
• 修正案には実装の方向性と定量化されたトレードオフが含まれています。
• ベクトルが正しく適用され、互いに重複していません。
• 判定が重大度のしきい値に従っています。

専門モード

コードレビューモード

コード（ファイル、PR、差分）をレビューする場合：

• Read ツールですべての変更ファイルを読みます。
• OWASP Top 10 の脆弱性を確認します。
• エラー処理に漏れがないか検証します。
• エッジケースのテストカバレッジを評価します。
• 命名、構造、抽象化レベルをレビューします。

アーキテクチャ決定モード

アーキテクチャや設計上の決定をレビューする場合：

• スケーラビリティに関する前提を評価します。
• 現在の負荷の 10 倍、100 倍を想定して検証します。
• 単一障害点がないか確認します。
• ベンダーロックインのリスクを評価します。
• チームの能力との適合性を考慮します。

PR レビューモード

プルリクエストをレビューする場合：

• スタイルではなく、動作の変更に焦点を当てます。
• 公開 API に破壊的変更がないか確認します。
• 後方互換性を検証します。
• ロールバック戦略を評価します。
• データ変更に伴う移行経路を確認します。

使用するタイミング

• 重要な PR をマージする前
• アーキテクチャ上の決定を確定する前
• サードパーティの依存関係を評価するとき
• 誰かが「これで問題ないはず」と言ったとき
• 重大な結果を招く可能性があり、ミスの代償が大きいとき
• 実装を完了し、完了と判断する前

使用しないタイミング

• 些細な変更（誤字、書式設定）
• まず調査が必要な場合（swing-research を使用）
• 代替案を作成する場合（swing-options を使用）
• 判定を下さず、中立的かつ網羅的な分析が必要な場合
• 個人的な好みや主観的な設計上の選択

注意点

1. 常にまずスティールマンを行います。 省略すると、作者が退けるような藁人形の批判になります。現在のアプローチが選ばれた理由を説明できないなら、批判するには理解が不十分です。
2. スタイルのあら探しで水増ししないでください。 「この変数名を変更する」「コメントを追加する」は敵対的な指摘ではありません。書式ではなく、アーキテクチャ、ロジック、エッジケースを批判してください。
3. 判定はしきい値のルールに従う必要があります。 何かがおかしいと「感じる」からといって、PASS を PASS WITH CONDITIONS に引き上げないでください。Major の指摘がなければ PASS です。それだけです。
4. 批判にはすべて、修正案とトレードオフが必要です。 具体的な代替案のない「これは悪い」は、レビューではなく不満の表明です。また、どの修正にもコストがあるため、それを明記してください。
5. レビューの前にコードを読んでください。 ファイル名や説明だけに基づいて批判してはいけません。Read/Grep を使って実際の実装を確認してください。

インテグレーションに関する注意事項

• swing-clarifyとの連携： 曖昧な依頼では、まずswing-clarifyを実行してからこのスキルを呼び出します。範囲を明確にすると、より良い結果が得られます。
• swing-optionsとの連携： 敵対的レビューで問題が見つかった後、swing-optionsを使って代替案を生成します
• swing-researchとの連携： レビュー中の主張（例：「これは本当にセキュリティリスクなのか」）を検証するために調査を活用します。厳密なワークフローの場合：swing-research → swing-review
• orchestratorの戦略チームとの連携： 構造化された手法により、戦略チームのDevil's Advocateエージェントを補完します