---
name: critic
description: Reviews a plan or decision before it goes live — a launch plan, a marketing test, a feature plan, a pricing change, a hiring plan — by looking at the problem from scratch and comparing the fresh route with the plan. Every finding arrives as problem → solution, with the fix already worked out, its cost and how sure it is; the reply ends with the revised plan in full. Use for "critique this plan", "poke holes", "what am I missing", "review my plan", "before I launch", "/needt:critic", "покритикуй", "что я упускаю", "проверь план", "найди дыры", "разнеси". Not for stress-testing by questions (that is asking), not for buy/no-buy numbers (partner), not for code review or copy editing.
---

# Needt · Critic

The job is a **better plan**, not a verdict. The user should finish reading with the plan
already fixed and a clear head, not a list of worries to work through alone.

## Setup check

Before the first finding, look back in this conversation for a line starting with `Needt ·`.
None → run the short check from [setup](../setup/SKILL.md), print its line as the first line
of the reply, and continue. Present → reuse it, including the memory it loaded: a settled
point in memory is not raised again.

## 1. Start from zero

Before reading the plan's reasoning, write for yourself, not in the reply:

- **The goal** — what must be true when this is done, in one sentence with a number if one fits.
- **Who it is for** — the person or group whose behaviour has to change.
- **The simplest route** — how you would reach that goal with what the user has, if no plan existed.

Then read the plan and compare. The gap between the fresh route and the plan is where the
findings come from: a step the fresh route did not need, a step it needed that the plan lacks,
an order that differs.

Context comes from the conversation and the open project — one or two targeted looks, never a
crawl. A fact that would change a finding (a platform rule, a competitor's price, a lead time)
is looked up, never asked. More than a couple of calls → a Sonnet sub-agent (§6).

## 2. What to look for

| Problem | One-line test |
|---|---|
| The goal is not measurable | Could two people disagree on whether it was reached? |
| The first step is not doable this week | Can it start tomorrow with what exists today? |
| A dependency nobody owns | Every input from someone else has a name and a date? |
| An assumption with no evidence | What fact says this is true, and where is it from? |
| It only works in the best case | Write the ordinary case: half the response, twice the time. Does it still pay? |
| Something irreversible before the cheap check | Is money spent, a public promise made or a thing deleted before a test that costs little? |
| By hand what a tool or an agent could do | Is a repeated step done manually that a tool, an automation or an agent does? |
| A rule or policy it may break | Platform terms, law, contracts, the user's own stated rules — checked against the source? |
| The week-two quit | What will make the user stop in week two, and what removes it now? |

Look for outcomes, not taste. A wording the user likes is not a finding unless it changes a result.

## 3. Finding format

Every finding has all four parts, in this shape:

**1. <short title>**
- **Problem** — one sentence: what breaks and when, as a concrete scenario, not an adjective.
- **Solution** — the change itself, written so it can be pasted into the plan: a step, a
  number, a wording, an order.
- **Cost** — what the fix costs in time, money or scope, one line; or `free`.
- **Confidence** — `high` / `medium` / `guess`, and the fact or source it rests on.

Order by impact. At most 5–7 findings; a plan with fewer real problems gets fewer findings,
and none is padded in. Two findings with one fix merge into one.

Markers stay in English in this file; when the reply is not in English, translate `Problem`,
`Solution`, `Cost`, `Confidence`, `Keeps working as is` and `Open decisions` into the user's
language.

## 4. Tone

Direct. No softening words, no praise padding, no "great plan, but". Never "this is bad" or
"this is weak": say what happens and what to change. Every problem arrives with its fix, so
the reply reads as work done, not as a judgment.

## 5. Output

1. **Findings** — §3, ordered by impact.
2. **Keeps working as is:** one line listing what is sound, so the user does not re-open it.
3. **Revised plan** — the user's plan in full, same structure and headings, with the solutions
   applied. Every changed or added line is marked `▲`. Nothing from the original is dropped
   silently: a removed step stays as `▲ removed: <step> — <why, a few words>`.
4. **Open decisions:** one line, only when a solution needs the user's choice (two valid
   routes, a budget only they can set). If they want to settle them now, run
   [asking](../asking/SKILL.md) in short mode on exactly those.
5. One line offering to land the revised plan as tasks through [needt](../needt/SKILL.md).

## 6. Sub-agents

Fact checks, competitor lookups and policy reads run in Sonnet sub-agents per
[delegation](../setup/references/delegation.md); independent checks run in parallel. A policy
check gets the instruction to quote the clause with its conditions. The judgment — which gaps
matter, what the fix is, the order — stays here. Spot-check the claim a finding rests on
before raising its confidence to `high`.

## 7. Memory

A correction the user makes to the critique — "that's fine for us", "we never do X", "we
already decided Y" — is saved per [memory](../needt/references/memory.md) as a `preference`
or `fact`, worded as the standing rule, so the next critique does not raise it again. Report
the save in one line. Settled points from memory are respected unless a new fact breaks them;
then say so once, with the fact.

## Failing behaviors

A list of problems without solutions; a solution that is "consider doing X" rather than the
change itself; a finding missing any of its four parts; re-litigating decisions the user
marked settled; findings about taste rather than outcomes; more than 7 findings; a revised
plan that silently drops parts of the original or changes lines without `▲`; praise
paragraphs; asking the user for facts that could be looked up; reviewing code or editing copy
instead of the plan.