Help us improve
Share bugs, ideas, or general feedback.
Validates if proposed or in-progress work justifies investment before designing, planning, or building non-trivial features. Use when new evidence questions motivations or facts change.
npx claudepluginhub repozy/superpowers-optimizedHow this skill is triggered — by the user, by Claude, or both
Slash command
/superpowers-optimized:premise-checkThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
It's easy to treat a design request as unconditional — "user asked me to design X, so I'll design the best X I can." But the right answer is sometimes "X shouldn't exist." Without a deliberate check, effort flows into comprehensive designs that solve problems that are already handled, cost more than they're worth, or whose motivation evaporated when new evidence arrived.
Use when a user requests new work - features, components, integrations, or additions - to challenge assumptions, evaluate effort, surface alternatives, and ensure the work is worth doing before committing to it
Runs a strict pre-project gate that defaults to NO-GO unless five framework checks pass, includes memory of past attempts, and enforces a 24-hour cooldown on high enthusiasm. Outputs a public commitment artifact with kill criteria for D14/D30/D60/D90 reviews.
Interviews you relentlessly about a plan or design using Socratic questioning. Uncovers hidden assumptions, edge cases, and feasibility gaps before implementation.
Share bugs, ideas, or general feedback.
It's easy to treat a design request as unconditional — "user asked me to design X, so I'll design the best X I can." But the right answer is sometimes "X shouldn't exist." Without a deliberate check, effort flows into comprehensive designs that solve problems that are already handled, cost more than they're worth, or whose motivation evaporated when new evidence arrived.
The most dangerous failure mode isn't building something wrong — it's building something unnecessary with conviction.
Answer these three questions honestly before proceeding:
Does the problem actually exist, or is it already solved? Look at what's already in place. Check whether existing mechanisms already cover the gap. If the problem was hypothetical when the work was proposed, has it since been confirmed or disproven?
Is the proposed solution proportional to the problem? Compare the complexity, maintenance burden, and token/time cost of the solution against the severity and frequency of the problem. A rare edge case doesn't justify a framework. Three lines of code don't need an abstraction.
What's the cost of NOT building this? If the answer is "nothing breaks, things are just slightly less elegant" — that's a strong signal to skip it.