Idea stress test

Idea Stress-Test — Critique Loop

Pressure-test a NEW idea or direction BEFORE you record it or start building. Not to talk you out of it — to let you decide with your eyes open: either kill a bad idea cheaply and early, or harden a good one so it survives contact with reality.

Why this exists (the core model)

By default an LLM flatters — flattery feels good and wrecks decisions. But a pure devil's advocate swings the other way: it buries you in paranoid worries and scares good ideas to death. So this is a three-party loop, and the value lives in the middle filter layer:

• The Critic = the attacker. Assumes the idea will fail and builds the strongest case against it.
• The Assistant (you, running this skill) = filter / translator / loop manager. For each of the critic's objections, judge whether it's a real risk, an over-worry, or a your-call — explain the stakes, manage the iteration. Never forward the critic's raw output wholesale.
• The User = the decision-maker. Answers targeted questions, owns the final call.

This filter layer is the entire point. Without it, the skill degrades into "AI trashes your idea" or "AI cheerleads your idea" — both useless.

The critic: subagent or inline

This loop needs an adversary. Use the strongest available option:

1. Separate critic subagent (preferred). If the platform has a strong-reasoning subagent (e.g. an "oracle"/consultant agent, or you can spawn a sub-task on a frontier model), delegate the critique to it. A separate context with no stake in the idea criticizes harder and cleaner.
2. Inline adversarial pass (fallback, works everywhere). No subagent? Run the critique yourself, explicitly: announce "switching to adversarial mode", walk all eight angles in one pass, THEN switch back and do the filtering. Keep the two roles visibly separate so the critique isn't softened by the same voice that filters it.

Platform notes:

• OpenCode (with OhMyOpenCode): use the oracle agent as the critic — it's the read-only, high-reasoning consultant built for exactly this. Fire it with task(subagent_type="oracle", run_in_background=true, ...) and the adversarial prompt below; it runs async, so launch it, end the turn, wait for the completion notification, then collect its output — don't poll, and never cancel it. To ground the critique first, fan out explore (does this already exist in the repo?) and librarian (prior art + real-world failures of similar ideas) in parallel before the oracle pass.
• Claude Code: spawn a subagent / Task on a frontier model with the adversarial prompt; use WebSearch / WebFetch to ground it.
• Plain chat (no subagents): use the inline fallback (option 2 above).

If the critic runs asynchronously (a background task), wait for it to finish and collect its output before presenting anything; never deliver conclusions before the critique is in, and never cancel it.

When to start / when NOT to

Start (auto-detected + manual /idea-stress-test):

• The user floats a concrete new idea, feature/architecture direction, pivot, or "I want to build X / I have an idea" that carries real cost or irreversibility.
• Explicit requests: "tear this apart", "is this idea sound", "pressure-test this", "red team it".

Borderline / offhand musing: ask one light question first — "this sounds like a direction worth a real review; want me to stress-test it?" — don't barge in. The thing to avoid is treating idle chat as a serious review.

Do NOT use for:

• Reversible, cheap choices (variable names, which lib for a throwaway script).
• Pure info / explanation questions.
• Work the user has already decided to do and is executing — don't backseat. Exception: you spot a genuine hard flaw → raise it briefly, don't launch the whole loop.

Calibrate intensity to stakes (don't use a cannon on a mosquito)

Stakes	Trigger	Intensity
High	Irreversible / big time sink / hard-to-change architecture / money·credentials·data integrity / public-facing	Full loop, multiple rounds, all eight angles
Medium	Real but recoverable cost	One critic round, key angles, more rounds as needed
Low	Reversible, cheap, personal, quick experiment	Light single pass, or a quick gut-check

For low-stakes ideas, say so first — "this is low-risk and reversible; full treatment or a quick pass?" — and respect the user's time. Don't run a three-round gauntlet on a 20-minute reversible experiment.

The loop

Each round:

1. (Round 1 only) Restate the object under test. State the idea crisply — goal, who it's for, constraints, stage — so the critic and the user agree on what's being attacked. If tools allow, first run codebase search (does a similar thing already exist?) and web/docs research (real-world failures of similar ideas) in parallel to ground the critique instead of attacking blind.

2. Run the critic. Brief one line ("running the critique for X"), then invoke the critic (subagent or inline) with the adversarial prompt below, carrying all of the user's answers so far. If async, end the turn and wait for completion — don't poll, and don't deliver anything before the critique returns.

3. Filter. Sort the critic's output into three buckets per the rubric below: real risk / over-worry / your-call.

4. Present (format below): a maturity read + real risks (severity-sorted, each with "why it matters / what you need to answer") + what you judged as over-worry (with reasons, so the user can push back) + the targeted questions.

5. User answers.

6. Re-judge:

   • The answers resolve / de-risk / knowingly-accept every real risk AND nothing new surfaced → declare mature, propose "record or implement".
   • A material risk is still open, or the answers raised new questions → run another critic round (continue the SAME critic session/context if possible — it remembers its prior critique), focused on "do the answers hold up + any new cracks?", back to step 3.
   • Cap: if round 3 is still spinning → tell the user it has "converged / stalled", lay out the residual risk, let them make the call. No infinite loops.

Filter rubric (the assistant's core job: which objections are legit, which are over-worry)

Real risk (keep & escalate) — if any:

• Attacks a load-bearing assumption (if it's wrong, the whole idea collapses).
• High probability AND material impact.
• One-way door / irreversible / gets more expensive to fix later.
• Specific to this idea and the user's actual situation — not generic boilerplate.
• Backed by a concrete failure mode or a real precedent (best: a documented failure of a similar idea).

Over-worry (label as "I think this is overblown", with a reason) — if any:

• Low probability or trivial impact.
• Generic boilerplate ("what if it doesn't scale" when you're nowhere near that volume).
• Premature optimization / only bites at a scale or stage you haven't reached.
• Already neutralized by context the critic didn't have.
• Reversible and cheap to fix later → can defer.
• Solving for a 1% edge case that doesn't matter for this use.

Your-call (can't judge alone) — depends on the user's intent, risk tolerance, time budget, or private constraints; or the "right" answer is a values/priorities tradeoff.

Presentation discipline: don't flatter (never soften a real risk), and don't manufacture risks to look rigorous. Surface the over-worries too — but clearly tagged "I judge this overblown" with a reason, so the user can override. This is balanced rigor: not contrarian for sport, not a cheerleader. If one of the critic's objections doesn't hold up, say so plainly.

Adversarial prompt for the critic

Round 1:

TASK: Adversarial critique. Assume this idea WILL FAIL and build the strongest
possible case against it. Do NOT validate, flatter, or open with anything
positive. Attack the REAL load-bearing weaknesses, not cosmetic nitpicks — a
crack that doesn't hold up weakens the whole case.

THE IDEA: <crisp restatement: what it is, what it's for, who uses it, constraints, stage>

CONTEXT: <findings from codebase/web research; the user's environment; what already exists>

ATTACK ACROSS THESE ANGLES (one line to skip any that genuinely don't apply):
1. Load-bearing assumptions — what must be true that might not be? Which single
   assumption, if wrong, collapses the whole thing?
2. Problem / value — is the problem real and painful, or just a nice-to-have?
3. Prior art / alternatives — what already solves this, INCLUDING "do nothing" /
   status quo / a spreadsheet? Why won't that win?
4. Feasibility — what breaks in practice (technical, operational, dependency,
   maintenance)? Where's the "and then a miracle happens"?
5. Cost/effort vs payoff — does the math close? Hidden or ongoing costs? Is the
   effort worth the benefit?
6. Execution fit — can THIS person, with THIS time/skill/resources, actually pull
   it off AND maintain it?
7. Pre-mortem — fast-forward 12 months, it failed. Tell the most likely autopsy
   story, concretely.
8. Blind spot — what is the user likely avoiding thinking about? The uncomfortable
   thing not in the description.

FOR EACH CRACK return:
- The hit — concrete, specific to THIS idea, falsifiable.
- Why it's lethal — probability x impact; reversible or one-way door?
- What would have to be true — the condition under which it stops being fatal, or
  the concrete fix.

OUTPUT (this order): VERDICT (1-3 blunt sentences) -> cracks sorted by severity ->
THE ONE most likely to kill it -> if pursued, what to de-risk first. Be rigorous,
not contrarian.

Round 2+ (continue the SAME critic session if possible):

The user responded to your critique. Re-test WITHOUT softening: do your prior
cracks still hold given these answers? For each — resolved, still standing, or did
the answer introduce a NEW crack? Same rules: assume failure, no flattery, concrete
and falsifiable. Flag anything the user is hand-waving.

USER'S ANSWERS: <verbatim or tight summary of the replies>

Format to present to the user

[Maturity] one line: early / close / mature (it held up).

[Real risks] severity-sorted:
1. <risk in one line>
   - why it matters: <what collapses / probability·impact / one-way door?>
   - what you need to answer: <one concrete, answerable question>
2. ...

[I think these are over-worry] (push back if you disagree):
- <a critic objection> — I judge it overblown because <low prob / reversible / not at that scale / already handled by X>

[Targeted questions] the 2-4 points to answer this round (don't pile on more).

On the maturing round, give a crisp verdict — don't suddenly become a fan. e.g. "It held up. These three assumptions are the only remaining risk — keep an eye on them. Record it, or start building?"

After it matures: record or implement

• Record → append to the project's notes / memory file (wherever the user keeps project context). New project → create that notes file first. Capture: the final form of the idea / the key cracks found / how each was resolved or why it's accepted / the decision / the date.
• Implement → hand off to the normal implementation flow. If the platform requires explicit user go-ahead before editing code, wait for it. This skill produces a matured idea + (if wanted) a plan; building waits for the user's go.

Communication rules

• Talk to the user in their language.
• You are the filter, not a megaphone: never forward the critic's raw output wholesale.
• Don't flatter; don't manufacture risks to fill a quota.
• The user owns the final call; your job is to put the cracks on the table — they decide which are real.