1. Default to finding problems. Conduct rigorous analysis across all three vectors. Report every genuine issue found — do not downplay or omit real concerns. If thorough analysis yields fewer than 3 issues, that is a legitimate outcome indicating strong work. Never inflate minor observations to fill a quota, and never fabricate concerns.
2. Attack the strongest points. Don't waste time on trivial issues. Target the parts the author is most confident about — that's where hidden assumptions live.
3. Separate severity levels. Not all issues are equal. Clearly distinguish critical from minor.
4. Propose alternatives. Every criticism must include a concrete alternative or mitigation.
5. Steel-man first. Before attacking, state the strongest version of why the current approach was chosen. This prevents straw-man critiques.
6. No ad hominem. Critique the work, not the author. Be sharp but constructive.

• "Review my project" (which aspect? architecture? security? specific files?)
• "Is this okay?" with no context (what is "this"?)
• A topic so broad that a meaningful adversarial review would be unfocused

• Why was this approach chosen? (Best possible justification)
• What does it optimize for? (Performance? Simplicity? Time-to-market?)
• Under what conditions is this the right choice?

• Are there logical contradictions or circular reasoning?
• Are conclusions actually supported by the stated premises?
• What unstated assumptions does the reasoning depend on?
• Is there confirmation bias in the evidence selection? Do NOT examine implementation structure — that's Vector C.

• What happens at boundaries? (empty input, max load, concurrent access, zero state)
• What's the failure mode? (graceful degradation vs. catastrophic failure)
• What happens in 6 months? (scaling, maintenance burden, team changes)
• What would a malicious actor exploit? Test behavior and outcomes, not internal structure.

• Does each component have a single, clear responsibility?
• Where are the coupling points and dependency chains?
• What is the weakest structural link?
• Which component, if changed, would cause the most cascading failures? Examine architecture, not logical reasoning.

1. What's wrong (1-2 sentences)
2. Why it matters (concrete impact)
3. Suggested fix (code snippet or approach)
4. Trade-off of the fix (nothing is free — what does the fix cost?)

[Why this approach makes sense — strongest justification]

• [If PASS WITH CONDITIONS: list required changes]
• [If FAIL: list blocking issues]

• 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.

• [Assumption 1 that the current approach relies on]
• [Assumption 2 that could invalidate the approach if wrong]

undefined

It works.

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.

• Must implement refresh token rotation before production deploy
• Should migrate rate limiting to shared store before scaling to >1 instance

**Why this is good:**
- Steel-man genuinely engages with the design rationale and trade-offs
- Findings target real security risks, not style preferences
- Each finding has specific, concrete impact (not "readability" or "confusion")
- Fixes include implementation direction AND quantified trade-offs
- Vectors are correctly applied and don't overlap
- Verdict follows directly from the severity thresholds

• Read all changed files with the Read tool
• Check for OWASP Top 10 vulnerabilities
• Verify error handling completeness
• Assess test coverage of edge cases
• Review naming, structure, and abstraction levels

• Evaluate scalability assumptions
• Test with 10x and 100x current load mentally
• Check for single points of failure
• Assess vendor lock-in risks
• Consider team capability alignment

• Focus on behavioral changes, not style
• Check for breaking changes to public APIs
• Verify backward compatibility
• Assess rollback strategy
• Check migration paths for data changes

• Before merging any significant PR
• Before committing to an architecture decision
• When evaluating third-party dependencies
• When someone says "this should be fine"
• When stakes are high and mistakes are expensive
• After completing implementation, before calling it done

• Trivial changes (typos, formatting)
• When exploration is needed first (use

  swing-research

  )
• When generating alternatives (use

  swing-options

  )
• When you need neutral, exhaustive analysis without a verdict (use

  deep-dive-analyzer

  — it understands; this skill challenges)
• Personal preferences or subjective design choices

• With swing-clarify: Run swing-clarify first on ambiguous requests before invoking this skill. Clarified scope produces better results.
• With swing-options: After adversarial review reveals problems, use swing-options to generate alternative approaches
• With swing-research: Use research to verify claims made during review (e.g., "is this really a security risk?"). For a full-rigor workflow:

  swing-research

  →

  swing-review

• With deep-dive-analyzer: For understanding before challenging:

  deep-dive-analyzer

  (understand) →

  swing-review

  (challenge). This skill focuses on finding flaws; deep-dive focuses on neutral exhaustive analysis.
• With orchestrator strategy team: Complements the strategy team's Devil's Advocate agent with structured methodology