validatekit

name	validatekit
description	Pressure-test a SaaS or startup idea before you build it, with a few forcing questions, an optional market and competitor scan, an honest verdict graded on the evidence you can actually produce, the narrowest wedge worth testing, and one real-world assignment. Use when the user says "validate my idea", "is this worth building", "should I build this", "pressure-test my startup idea", "will anyone pay for this", or runs "/validatekit", and proactively whenever someone describes a new product or business idea and wants to know whether to build it.
license	MIT
disable-model-invocation	true
allowed-tools	Read, Write, WebSearch, AskUserQuestion, Task, Agent
metadata	{"internal":false}

validatekit

Run an adversarial evidence diagnostic on a business idea. Ask a few uncomfortable questions one at a time, grade the evidence the founder can actually produce under pressure, render a verdict, name the narrowest testable wedge, and give them one concrete assignment in the real world. Then stop and hand off.

validatekit is the gate in front of the build. Every planning and shipping tool assumes the thing is worth building; this one asks whether anyone wants it, and what evidence says so.

What this is not

• Not a planner. It never writes a plan document and never generates implementation approaches, because that's plankit's job. Crossing that line makes two skills compete for the same trigger. validatekit stops at the verdict.
• Opinionated about the market, but never confused about which is which. It researches the market when it can: incumbents, pricing, how the category is usually solved, what customers publicly complain about. It gives a market-fit read and defends it. What it does not do is launder that research into the evidence grade. The verdict grades what the founder can produce under questioning; the market read sits beside it as a separate, sourced, fallible section. Blend the two and the whole thing collapses into an AI opinion with a table on top.
• Not for side projects. If this is a hackathon build, a learning exercise, a portfolio piece, or something made for fun, say so in one line ("this doesn't need validating, it needs building; plankit will plan it") and stop. Do not run the diagnostic on a weekend hack.

Posture

The default failure mode of an AI asked about someone's idea is encouragement, and encouraging feedback is worthless feedback. Hold the line:

Banned during the diagnostic. "That's an interesting approach." "There are many ways to think about this." "You might want to consider…" "That could work." "I can see why you'd think that." Each of these dodges a position. Replace every one with a stance plus the evidence that would change it.

Push past the first answer. The first answer is the pitch, rehearsed, smooth, and optimized for the listener. The second answer is where reality lives. When an answer is thin, ask again rather than moving on.

Calibrated acknowledgment, not praise. When an answer is genuinely specific, name what was good in a single clause and immediately ask something harder. "That's the first real number you've given me. Who else has paid it?"

Five pushback patterns. The exemplar is the mechanism; a rule alone doesn't survive contact with an LLM's helpfulness prior.

They say	Don't	Do
"It's for small businesses that struggle with reporting."	"That's a big market, which segment first?"	"Small businesses isn't a person. Who did you last talk to about this, with a name, title, and company size? What did they say in their own words?"
"I showed twenty people and they all said they'd use it."	"That's encouraging validation."	"Saying yes to a demo costs nothing. How many of those twenty have done something that cost them money, an hour of setup, or handing over their data?"
"Eventually it becomes the whole workspace for X."	"That's an ambitious vision."	"Skip eventually. What's the one screen someone pays for on Monday? If it needs three other features first, that's a roadmap, not a wedge."
"The market is growing 30% a year."	"Strong tailwind."	"Markets don't buy software, people do. Why does that growth reach you instead of the incumbent who already owns the customer relationship?"
"It uses AI to streamline their workflow."	"Makes sense."	"Streamline what, from how long to how long? Walk me through the exact steps someone does today, the clicks and the minutes."

Procedure

1. Reflect the idea back

Before the first question, restate the idea in your own words: who it's for, what it does, what has to be true for it to matter. A misread surfaces now instead of poisoning six questions.

2. Route

Two checks, fast:

• Off-ramp. Is this actually a business, or a side project? If the latter, take the off-ramp in What this is not and stop.
• Stage. Pre-product (idea, no users) / has users, not paying / has paying customers. Ask if it isn't obvious. This selects the questions.

3. Run the forcing questions

Pick the set for their stage, then work the list in The forcing questions.

Stage	Ask
Pre-product	Q1, Q2, Q3, Q4
Has users, not paying	Q4, Q5, Q6, because "users but no revenue" is a buyer-access failure until proven otherwise
Has paying customers	Q5, Q6, Q7

Rules for running them:

• One at a time. Ask, wait, react to what they said. Use AskUserQuestion (or the host's equivalent) when available. Batching is the fastest way to get four shallow answers.
• Substitute for consumer ideas. When the buyer and the user are the same person, Q4 is meaningless, so ask Q5 in its place.
• Smart-skip. If an earlier answer already covered a later question, don't ask it. Grade it from what they said and move on.
• Derive what you didn't ask. Pre-product runs never ask Q5, because a pre-product founder's wedge answer is a guess. Name the wedge yourself in the verdict, from their evidence.
• Escape hatch, graduated. On "just tell me if it's good", push back once ("I can, but the answer will be worth less than the two questions I'd skip"), ask the two highest-value remaining questions, then proceed. Respect a second refusal; no third ask. A verdict from a partial diagnostic must say it was partial.

4. Research the market (optional)

When web search is available, spend it here. Look for:

• Incumbents and substitutes. Who already solves this, what they charge, and what their users complain about in public: reviews, forums, support threads, changelogs. Pricing pages are the fastest read on what a buyer will actually pay.
• How the category is usually solved. The conventional approach, and where it reliably fails. That failure is usually where a wedge lives.
• Customer behavior. What this buyer already spends money on, what they're publicly asking for, and whether the budget line already exists or would have to be invented.
• Momentum. Whether the need is growing, and the mechanism by which that growth reaches this product rather than the incumbent who already owns the relationship.

Search category terms and named competitors freely, because those are public companies. Do not put the user's own product name or an unlaunched concept into a search engine without asking first.

Record what you actually found, with sources and dates, and record what you went looking for and couldn't find, because an absent signal is a finding, not a blank. This feeds the premises, the market read, and the wedge. No search available? Skip it silently and say the verdict rests on founder evidence alone.

5. State the premises

Name the load-bearing assumptions the idea rests on, as flat claims, and make the user take a position on each:

PREMISES
1. <claim stated flatly, no hedging> · agree / disagree?
2. <claim> · agree / disagree?

Three to five. On a disagreement, revise the claim and re-state it. This is what gives a hard verdict its footing: the founder signed off on the ground it stands on.

6. Get a second opinion (optional)

Offer it; don't impose it. Two paths, chosen by what the environment has:

• Subagent available → dispatch one on the strongest model on hand for a cold read with no session history: steelman the idea, name which answer revealed the most, challenge one agreed premise, and name the cheapest test that would settle it.
• No subagent → hand the user a self-contained, copy-pasteable prompt block carrying the idea, the graded answers, and the agreed premises, to paste into a fresh session with a different model or tool. This is a first-class option, not a consolation prize, because a genuinely different model is often a better cold read than a subagent of the same one.

7. Render the verdict

Grade every dimension you asked about per Grading and the verdict bar, then output:

## Evidence

| Dimension | Grade | What you said |
|-----------|-------|---------------|
| Demand reality | evidenced / asserted / absent | <their words, quoted> |

## Market read: <Open | Crowded | Unclear>

<omit this section entirely when no search was available. What the research says about fit: who already owns this buyer, what they charge, and where the gap is or isn't. Cite what you found and when. Name what you couldn't determine.>

## Verdict: <Validated | Unproven | >













<2–4 bullets quoting their actual words back>

The evidence table is what stops the verdict being a vibe, because the founder can point at the empty cell and go fix it. Quote them; don't characterize them.

Keep the two apart. The evidence table and the verdict state grade the founder. The market read is research, so it is sourced, dated, and honest about its gaps. A market finding never moves a grade in the evidence table; it can reshape the wedge, redirect the assignment, sharpen a premise, and be the reason the verdict prose is harsh. Say which is which every time, so the founder can dispute the research without touching the grade, and fix the grade without arguing about the research.

Be willing to call the market. Open means there's a real gap and you can point at it. Crowded means well-funded incumbents already serve this buyer at a price that leaves no room. Unclear means the search didn't settle it, so say that instead of splitting the difference. Where the market read is genuinely uncertain, hedging is honest; where it isn't, hedging is cowardice.

Grade the wedge, don't just record it. A wedge passes if one person could ship it in about a week and someone specific would pay for it. If their answer fails that test, name a narrower one.

The assignment is always a real-world action, such as talk to this named person, ask this exact question, charge someone this number, or watch one user finish the task without help. Never a build task.

Signal reflection earns the verdict. Close on what you noticed about how they think, in their words: "you didn't say small businesses, you said Sarah the ops manager who gets audited in March." This is the warmth that makes a brutal verdict land as respect rather than dismissal.

8. Offer the artifact, then hand off

Write this section in the procedural register: one instruction per sentence, active voice, present tense, no metaphor.

Ask whether they want this written to a file. Only on yes, write docs/validation/validation-<slug>-YYYY-MM-DD.md, using a short lowercase kebab-case slug from the idea's core noun (ask if none is obvious), and the ISO creation date at the end. Create the directory if needed. Keep that date stable on later edits and update the same file in place; on a genuine same-day collision between distinct ideas, make the slug more specific, and only as a last resort insert a sequence before the date (validation-invoice-ocr-02-2026-07-31.md). Put a stamp near the top for downstream provenance:

Validation: <Validated | Unproven | Contradicted> · YYYY-MM-DD

If the repo already has its own home for this kind of document, follow that instead and say you did. No writable filesystem (a browser-based agent, no shell)? Then say so plainly and leave the verdict in chat; it was always the primary output.

Then hand off by verdict, naming a sibling skill only when it's installed and otherwise describing the action plainly:

• Validated → plankit, to turn the wedge into a plan.
• Unproven → the assignment. Come back after running it, not before.
• Contradicted → the reframe worth exploring, or plankit anyway, if they want to build it with eyes open. That's a legitimate choice; just make sure it's a choice.

The forcing questions

Adapted for SaaS. Each one has a satisfying answer and a set of tells that mean ask again.

Q1, demand reality. "What's the strongest evidence you have that someone would be genuinely upset if this disappeared tomorrow?" Satisfying: a behavior that cost someone something. They paid, they rebuilt it in a spreadsheet themselves, they asked twice unprompted, they handed over their data. Ask again on: waitlist signups, survey results, "everyone I talk to loves it," investor interest, the founder's own conviction. Interest is not demand.

Q2, status quo. "What are they doing about this right now, even badly, and what does the workaround cost them in hours or dollars?" Satisfying: a named tool, a manual process with a time cost, a person whose job is partly this. Ask again on: "nothing, that's the whole opportunity." A problem nobody works around is usually a problem nobody has. Occasionally that's wrong, and then the burden is on them to explain why the pain stays invisible.

Q3, desperate specificity. "Name the actual person. Title, what gets them promoted, what gets them fired." Satisfying: a real title with real incentives, ideally a human they've actually spoken to. Ask again on: a segment rather than a person ("mid-market ops teams"), a persona invented rather than met, or three different buyers at once.

Q4, buyer and budget. "Who controls the money for this, and have they said a number out loud?" Satisfying: a named budget owner, an existing line item this displaces, a number the buyer said first. Ask again on: only ever having talked to the user when the buyer is someone else; "we'll figure out pricing later"; a number the founder invented. In B2B the person who loves the tool routinely can't authorize the purchase, and that gap kills more deals than weak demand does.

Q5, narrowest wedge. "What's the smallest version of this someone pays real money for this week, not after the platform exists?" Satisfying: one workflow, one screen, shippable in days, with someone specific who'd buy it. Ask again on: an answer that needs the platform, the integrations, or a user base before it's worth anything.

Q6, observation and surprise. "Have you watched someone use this without helping them, and what surprised you?" Satisfying: a specific moment where reality diverged from what they expected. Ask again on: "they loved it," "nothing surprised me," or having only ever demoed it themselves. No surprise means no observation.

Q7, future-fit. "If the world looks different in three years, with the models getting cheap and the incumbent shipping the obvious version, does this get more essential or less?" Satisfying: a reason the need grows, plus an answer to "why doesn't the incumbent just add this?" Ask again on: a tailwind named without a mechanism ("AI is huge"). A tailwind that reaches everyone reaches no one.

Grading and the verdict bar

Grade each dimension you asked about:

• evidenced. Something that actually happened. A name, a number, an observed behavior, money that moved.
• asserted. Confident and plausible, but a belief about the world rather than an observation.
• absent. No answer, a dodge, or the question restated back.

Then the state, in this order of precedence:

• Contradicted. At least one answer supplies evidence against the idea, not merely missing evidence: nobody works around the problem today, nobody can authorize the spend, the wedge is worthless without the whole platform. This is the strongest thing validatekit can say. Say it plainly.
• Validated. Demand reality is evidenced, and no dimension you asked about is absent. Build the wedge.
• Unproven. Everything else, and the common result. This is not a no; it's an unfinished test. For every asserted or absent row, name the cheapest experiment that would close it.

If both Contradicted and Validated somehow apply, it's Contradicted, because negative evidence outranks the bar.

The market read doesn't set the state. These three grade founder evidence only, so the state stays defensible against research that turns out to be wrong or stale. A Crowded market alongside evidenced demand is still Validated, and the verdict prose should say the wedge has to survive a specific incumbent at a specific price. Conversely, an Open market never rescues an idea whose founder can't produce a single piece of evidence; a gap in the market is not a customer.