Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →danium/worst-idea
Worst Possible Idea (reverse brainstorming) — deliberately design the most terrible solutions to the problem, name the mechanism that makes each one bad, then invert those mechanisms into strong features.
Passed 20 of 22 test cases with the skill, and 9 of 22 without it.
and 9 more in the full report
11 fixed9 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
Our web app's navigation bar is overflowing on mobile viewports under 375px. Here is the CSS stylesheet and HTML layout. Please edit the CSS file to fix the responsive breakpoint bugs.
| Checked | Without skill | With skill |
|---|---|---|
| The response declines to implement the CSS fix. | Missed | Passed |
| The response suggests an analytical front-end debugging approach. | Passed | Passed |
The instructions your model reads when the skill loads.
Ask for the worst solution to the problem, not the best. Design solutions that would reliably make things terrible, then dissect each one to find the exact mechanism that makes it bad. Invert that mechanism, and you have a feature. The move works because "what's the best design?" routes through everyone's inhibitions and lands on the safe, obvious answer, whereas "how would we guarantee failure?" removes the fear of being wrong and lets people say things out loud — and every named failure mode is a design principle wearing its opposite.
Source: reverse brainstorming, attributed to Hotpoint's product development practice in the 1950s, and standard in the d.school/IDEO facilitation toolkit as "Worst Possible Idea."
A valid target is a concrete creative problem stated as something to design or reinvent: an onboarding flow, a pricing page, a landing page, a naming direction, a ritual the team runs. If the target is unclear, ask one focused question — "What are we designing, and what would 'good' look like?"
Refuse requests to perform analytical work — debugging, reviewing code, implementing a change — and suggest an analytical approach instead. Redesigning or ideating about such a process is a valid creative target: "reinvent our code-review ritual" is in scope; "review this PR" is not.
Produce 5–8 solutions that would make the problem worse. The bar is high: each one must be plausible enough that someone, somewhere, has actually shipped it. Cartoon evil ("delete the user's files!") is too easy and teaches nothing. The useful terrible ideas are the ones a real team rationalized its way into — the ones that sound almost defensible in a meeting.
Show them plainly. Do not soften them, and do not pre-apologize for them.
For each bad idea, state in one sentence why it is bad — the mechanism, not the symptom. Not "it's annoying" but the structural reason it fails.
Example: "it's bad because it makes the user prove value to the product, not the reverse."
The mechanism is the whole technique. A bad idea with no articulated mechanism is just a bad idea.
Flip the mechanism into its opposite. This is not "don't do the bad thing" — that only gets you back to neutral. Inverting the mechanism produces a positive design principle.
Bad idea's mechanism: "it makes the user prove value to the product." Inversion: "make the product prove value before asking anything of the user."
Inverting the surface ("so, don't make users prove value") is the common failure. Invert the underlying force.
test cases passed, vs 9 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.