---

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). Want an independent human read before this goes live? That's exactly what I do. Reach out to me on LinkedIn.