adversarial-reviewlisted

# Adversarial Review ## When to use Use this skill when: - You've completed a plan, design, or proposed fix and are about to present it. - The change is non-trivial (affects multiple files, changes behavior, touches critical paths). - You're about to recommend an architecture or design decision. - The user submits **finished work** (draft, post, naming decision, design proposal) and asks for an honest critical take — "what do you actually think?", "be brutal", "was hältst du wirklich davon". The flow is the same Attack-Defend-Revise loop, but on the user's artifact rather than the agent's plan. Do NOT use when: - The task is trivial (renaming, formatting, simple config change). - The user explicitly asked for a quick/rough draft. - You're exploring options, not committing to one yet. ## Procedure: Adversarial review ### Step 1: Attack (Grumpy Senior Engineer) Assume your plan/fix is flawed. Ask yourself: - What's the weakest assumption? - Where will this break under load, at scale, or with edge cases? - What did I ignore or hand-wave? - Is this over-engineered for the actual problem? - Would a simpler approach work just as well? - What will the next developer curse me for? ### Step 2: Defend (Balanced Engineer) Counter the criticism fairly: - Which criticisms are valid and must be addressed now? - Which are theoretical and can be deferred? - What's the pragmatic middle ground? ### Step 3: Revise - Fix the valid issues in your plan/fix. - Move deferred concerns to