Outlines of the two skills we run before writing any code.
/office-hours decides whether a thing should exist. /diverge finds the
non-obvious way to build it. They're deliberately separate, and the order matters.
YC-style interrogation. Six forcing questions, one at a time, pushing until the answer is specific and uncomfortable. Kills bad ideas early and cheaply.
Output: a design doc. Never code.
Parallel isolated agents each thinking under a distorted frame, then one critic scores, clusters, and flags traps. Fights premature convergence.
Output: a scored shortlist + a real opinion.
If you merge them you get the worst of both — an idea validated against options you never generated, or twenty clever approaches to something nobody wants. Run office-hours first. Only run diverge on something that already earned the right to exist.
The premise: make sure the problem is understood before any solution is proposed. The skill is an adversarial partner, not a cheerleader. Its single hardest rule is that it must take a position on every answer and say what evidence would change it.
One question routes everything: what's this for?
| Goal | Mode | Posture |
|---|---|---|
| Startup / company · Client work | Startup mode | Adversarial. Six forcing questions. Assume it's wrong until evidence says otherwise. |
| Hackathon · Side project · Open source | Builder mode | Enthusiastic collaborator. Find the coolest version, not the most optimized one. |
Getting this wrong is the most common failure. Running startup rigor on a weekend project kills the fun; running builder enthusiasm on a real business ships something nobody pays for.
Asked one at a time. It stops and waits after each. Push until the answer is specific, evidence-based, and uncomfortable — comfort means you didn't push hard enough. The first answer is always the polished version; the real one comes after the second push.
"Strongest evidence someone actually wants this — not 'interested,' not 'signed up,' but would be genuinely upset if it disappeared tomorrow?"
Red flags: "people say it's interesting", "500 waitlist signups", "VCs are excited." Interest is not demand. Money counts. Panic when it breaks counts.
"What are your users doing right now to solve this — even badly? What does the workaround cost them?"
Red flag: "Nothing, that's why the opportunity is big." Usually means the problem isn't painful enough. The spreadsheet-and-Slack workaround is your real competitor.
"Name the actual human. Title. What gets them promoted. What gets them fired. What keeps them up at night."
Red flag: category answers — "healthcare enterprises", "SMBs", "marketing teams." Those are filters, not people. You can't email a category.
"Smallest possible version someone would pay for THIS WEEK — not after you build the platform?"
Red flag: "We need the full platform first." That's attachment to architecture over value. Bonus push: what if the user had to do nothing at all? No login, no setup.
"Have you sat down and watched someone use it without helping? What did they do that surprised you?"
Red flags: "We sent a survey" (surveys lie), "did some demo calls" (demos are theater), "nothing surprising" (you filtered). The gold: users doing something the product wasn't designed for — that's often the real product emerging.
"If the world looks meaningfully different in 3 years — and it will — does your product become MORE essential, or less? Why?"
Red flag: "AI keeps getting better so we keep getting better." That's a rising-tide argument every competitor can make. Needs to be YOUR thesis.
Not all six, every time. Routing by stage: pre-product → Q1, Q2, Q3 · has users → Q2, Q4, Q5 · has paying customers → Q4, Q5, Q6 · pure infra/dev tool → Q2, Q4. And there's an escape hatch: push back once and it asks only the two most critical; push back twice and it moves on. Respecting that is a rule, not a courtesy.
These phrases are banned during the diagnostic, because each one is a way of avoiding a position:
Before any solution, the premises get named and numbered so you have to agree or disagree in writing: is this even the right problem? What happens if we do nothing — real pain or hypothetical? What already exists that partly solves it? If it's a new artifact, how does anyone actually get it?
Two to three distinct approaches, never fewer. One must be minimal viable (smallest diff, ships fastest), one must be ideal architecture (best long-term shape), one may be lateral (a different framing of the problem). Each gets effort, risk, pros, cons, and what it reuses. Then it recommends one — and still waits for you to pick before writing anything up.
One markdown file, filed by project, with structured frontmatter. Two sections carry disproportionate weight:
"The assignment" — ONE concrete real-world action to take next. Explicitly not "go build it." Usually it's talking to a person.
"What I noticed" — 2-4 bullets quoting your own words back at you. Observational, not characterizing. This is where the uncomfortable insight usually lives.
The output is a document. The skill is forbidden from scaffolding a project, writing code, or invoking build tooling mid-session. Without that rule the model gets excited and starts building the thing it was supposed to be questioning — and once code exists, the idea stops getting challenged.
The first three answers a model gives are the answers a senior engineer gives in thirty seconds: correct, and forgettable. The interesting answers live past number three.
This skill walks past number three — using genuinely isolated parallel agents, not one context pretending to brainstorm. Each branch gets a fresh context and a distorted vantage point on the same problem, and branches never see each other. That isolation is the entire method: the moment branch two can read branch one, everything anchors and you get variations instead of alternatives.
Each agent is told to attack the problem from one vantage point — for example, "transplant a mechanism from biology (immune systems, neural plasticity, cell signaling, evolution) and force-fit it onto this engineering problem." Selection is automatic: several code/design frames plus one deliberately wild one.
A separate agent — not one of the generators — receives the whole pool and does four things:
Survivors then get deepened: sketch, load-bearing risk, first step, child ideas.
It costs ~9 agent calls, so it's gated behind a pre-flight. It runs only when all hold: the answer space is genuinely open-ended (no canonical answer), the cost of the obvious answer being wrong is high (architecture, public API, schema, naming a real product, positioning, a fuzzy bug with no known root cause), and the ask wasn't phrased narrowly ("quick", "standard", "just", "what's the syntax"). Otherwise it answers directly and simply offers the wider run as an option. Cheap tools get used carelessly; expensive tools need a gate.
Most ideas die at step two, which is the point — that's the cheapest possible place for them to die. The ones that survive arrive at the build stage with a named user, a narrowest wedge, a written premise list, and a set of approaches somebody actually argued against.
The specific prompts matter far less than five invariants. These are what make the difference: