---
name: Critique
slug: critique-3
category: AI Engineering
description: Critique challenges decisions, surfaces assumptions, and offers concrete counter-arguments when someone asks for a second opinion or devil’s advocate. It also reframes non-trivial refactors toward the elegant solution before choosing a pragmatic fix.
github: "https://github.com/FerroxLabs/ijfw/tree/main/claude/skills/ijfw-critique"
language: JavaScript
stars: 210
forks: 40
install: "npx degit https://github.com/FerroxLabs/ijfw/tree/main/claude/skills/ijfw-critique ~/.claude/skills/ijfw-critique"
installs_to: ~/.claude/skills/ijfw-critique
source_path: claude/skills/ijfw-critique/SKILL.md
collection_size: 25
category_size: 2970
collection_url: "https://dirskills.com/collections/FerroxLabs/ijfw"
added: 2026-09-04T05:26:35.043Z
last_synced: 2026-09-04T05:26:35.043Z
canonical_url: "https://dirskills.com/skills/critique-3"
---

# Critique

Critique challenges decisions, surfaces assumptions, and offers concrete counter-arguments when someone asks for a second opinion or devil’s advocate. It also reframes non-trivial refactors toward the elegant solution before choosing a pragmatic fix.

**Install:**

```bash
npx degit https://github.com/FerroxLabs/ijfw/tree/main/claude/skills/ijfw-critique ~/.claude/skills/ijfw-critique
```

## README

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 feels hacky, or you catch yourself
patching around a smell rather than removing it, run this prompt out loud:

> *Knowing everything I know now, what would the elegant solution look like?*

Answer it briefly (3-5 lines). If the elegant version costs less than the
hack you're about to ship, replace the hack. If it costs more than 2x, log
the elegant version as a follow-up and proceed with the pragmatic fix --
but only after you've named the debt explicitly.

Skip this for trivial or obvious fixes; the point is to break frame on
non-trivial decisions, not to over-engineer.

## When NOT to critique

- The user is midway through implementing and needs help, not a critique.
- The decision is reversible and cheap (just do it and see).
- You lack the domain facts to form an opinion -- say so instead of guessing.
- The question is "how" not "whether". How-to questions deserve how-to
  answers, not a rehash of whether to do it at all.

## Output shape

```
Steelman: <one-line strongest version>

Assumptions:
  1. <load-bearing belief>
  2. <load-bearing belief>

Counter-arguments:
  1. <non-obvious objection> -- applies when <condition>; watch for <signal>.
  2. <different angle> -- applies when <condition>; test with <method>.
  3. <third angle> -- applies when <condition>; mitigate via <approach>.

Verdict: <proceed|mitigate|rework> -- <one-line reason>

Audit: stress-tested <N> assumptions, <N> angles (<angle-1> + <angle-2> + <angle-3>). Confidence: <low|med|high>.
```

### Worked example

```
Steelman: Rewriting the auth layer in Rust eliminates the class of memory bugs that caused last quarter's outages.

Assumptions:
  1. The team has enough Rust fluency to maintain the new code without slowdown.
  2. The outages trace to memory bugs, not logic or config errors.

Counter-arguments:
  1. Operationally: Rust compile times and borrow-checker friction could double review cycles -- applies when the team has <3 months Rust experience; watch for PR cycle time increasing past 2 days.
  2. Socially: the auth team may resist a full rewrite when incremental hardening (address-sanitiser + fuzzing) could close the same risk at 20% of the effort -- applies when management is measuring velocity; test by asking the team to estimate both approaches.
  3. Correctness: auth logic bugs (e.g. missing token expiry checks) are language-agnostic -- applies if the root-cause analysis is incomplete; mitigate by running a postmortem before deciding on the rewrite.

Verdict: mitigate -- commission a 2-week root-cause analysis first; if the cause is confirmed memory-safety, Rust is the right call.

Audit: stress-tested 2 assumptions, 3 angles (operational + social + correctness). Confidence: high.
```

## Tone

Direct, not hedging. The user asked for a critique; they don't need
"this is just my opinion". State the counter clearly. If they push back,
that's the signal to update or yield -- but make them do the work of
pushing back, not you.

Resume normal mode after.