review-the-work

---
name: review-the-work
description: "Before showing the user any substantive GTM deliverable (positioning, value prop, homepage, launch post, pricing, sales script, the brief or roadmap), stress-test it against the standard as an independent critic, because the agent that wrote it is the worst judge of whether it is good. Use as a gate right before presenting work, or when the user asks whether something is actually strong."
---

# Review the work (the self-check gate)

> The person who wrote it is the worst judge of whether it is good. Before this reaches the founder, stop being the author and become the skeptic.

**Use this when:** you are about to present any substantive deliverable, or the founder asks "is this actually good?" It is a gate, not a stage. It has no place in the linear sequence. Run it around any piece of work, every time.

## The core idea

An agent that just wrote something is biased to ship it. That bias is how generic, plausible, quietly wrong work reaches a founder who does not yet know enough to catch it. So separate the two jobs: the author drafts, a different lens judges. You do not present work because you made it. You present it because it survived a skeptic.

Steal the one rule that makes this work: **the author may submit the work, the author may not issue the verdict.** Switch roles on purpose. Become the developer who is skeptical, the buyer who is busy, the reviewer who has seen a hundred of these, and try to break it before the market does.

## How to run this (for the agent)

- Run it **silently, before presenting.** The founder should see the verdict and the work, not the whole audit.
- Give a clear verdict: **PASS**, or **REVISE** with the exact checks that failed and the specific fix for each. Never a vague "looks good."
- **Do not rubber-stamp.** If you cannot find a single weakness, you are not reading as the skeptic. Name the weakest point even in work you pass, so the founder knows where it is thin.
- When it fails, fix it and re-run the gate, then present. Do not hand the founder a list of problems you could have fixed yourself.

## The standard (applies to everything)

- **Specific, not puffery.** No "powerful," "seamless," "best-in-class," "platform." Every claim carries a number, a name, or a proof, or it gets cut.
- **The developer is the hero, not the product.** If the founder's tool is the hero of the sentence, rewrite it.
- **It speaks to the real ICP** from the brief, not to "developers." A message for everyone lands on no one.
- **It rests on validated facts.** Anything load-bearing that is still `[assumption]` is flagged out loud, not smuggled in as truth.
- **A skeptical developer could not immediately prove it false.** Developers test claims and find the truth. If a dev would find the failing case in thirty seconds, you have not passed.
- **Human voice.** Reads like a person wrote it. No em-dashes, no AI tells.

## The specific checks (by deliverable)

Run the general standard, then the relevant skill's own checklist:

- **Positioning / story** (`positioning-and-story`): problem-first, not solution-first. Has a villain. Survives the "every competitor could say this" test.
- **Value prop** (`value-prop-that-converts`): no banned words, built on a real job-to-be-done, and a developer would repeat it in their own words.
- **Homepage** (`the-homepage`): written for the developer who visits, not the buyer who never does. Time to first value is obvious.
- **Launch post** (`launch-it`): honest, not salesy. Opens on the developer's problem, not the product. Would not get flamed for overclaiming.
- **Pricing** (`pricing`): anchored to a value metric, not a guessed number. The buyer could justify it to whoever holds the budget.
- **Founder-led sales** (`founder-led-sales`): passes the four-part deal test. Does not mistake a friendly free user for a buyer.
- **The brief** (`start-here`): strongest asset at the top, `[validated]` / `[assumption]` tags intact, in the founder's own words.
- **The roadmap** (`strategy-and-roadmap`): opens with a one-line Diagnosis, then Now / Next / Later. It is a plan, not a re-saved copy of the brief.

## Your next 30 minutes

- [ ] Take the last thing produced (a headline, a post, a price) and run it through the standard above, as the skeptic, not the author.
- [ ] Name the single weakest claim in it. Replace it with something provable, or cut it.
- [ ] Find the one `[assumption]` it depends on most, and decide whether it is safe to ship on or belongs in `talk-to-users` first.
- [ ] Only then put it in front of a real person. If it did not survive you, it will not survive them.

---
Built from real dev-tool GTM experience, with frameworks from Adam Frankl (*The Developer-Facing Startup*) and Jakub Czakon (*markepear.dev*).
When a framework can't make the call, that's what a human is for: [The DevTool GTM Company](https://thedevtoolgtmcompany.com).