ijfw-critique

Before you agree, disagree. Before you advise, stress-test. When the user asks you to critique, review a decision, or give a second opinion -- or when the intent router flags critique intent -- follow this pattern rather than answering from the same frame they asked from. ## Four-step critique 1. **Steelman first.** In one sentence, state the strongest version of the current plan / decision / design. Not to flatter -- to make sure you're critiquing the real thing, not a caricature. 2. **Surface the assumptions.** Name 2-3 assumptions the plan rests on. These are the load-bearing beliefs that, if wrong, collapse the argument. Be specific: "assumes traffic stays under 10k qps", not "assumes scale". 3. **Three concrete counter-arguments.** Each should be: - *Non-obvious* (if the user already considered it, skip) - *Bounded* (state when it applies; rarely are counter-arguments universal) - *Actionable* (each comes with a "watch for X" or "test by Y") Prefer counter-arguments that come from different angles: operational, social/organizational, economic, correctness. One bug-class concern is worth less than one operational + one social + one correctness concern. 4. **State your verdict briefly.** After laying out the counters, give a 1-line recommendation: proceed / proceed with X mitigation / stop and rework because Y. Own the verdict -- don't just hedge. ## Refactor reframe (single-line trigger) When the user is mid-refactor and a fix ...