agentleFS
REPOZYREPOZY/superpowers-optimized/skills/premise-check/SKILL.md

premise-check

Skill146 starsChanged 7 months agoMITView on GitHub

Validates whether proposed or in-progress work should exist before investing in it. Invoke BEFORE designing, planning, or building anything non-trivial — and WHEN new evidence arrives that could change the motivation for existing work. Triggers on: 'design a system', 'create a plan', 'build out the full version', 'extend this to handle', architecture proposals, or any moment where test results, research findings, or changed requirements weaken the original reason for doing something. Also triggers when you catch yourself updating a document's facts without reassessing its conclusions.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before investing in any design, plan, or architecture proposal

    line 16
  2. Distinctive:

    Before extending an existing system with significant new complexity

    line 17
  3. Distinctive:

    When new evidence (test results, research, changed requirements) arrives that relates to the motivation behind proposed or in-progress work

    line 18
  4. Distinctive:

    When you find yourself updating facts in a document without reassessing whether the document's conclusions still hold

    line 19
  5. Distinctive:

    Look at what's already in place.

    line 26
  6. Distinctive:

    If the answer is "nothing breaks, things are just slightly less elegant" — that's a strong signal to skip it.

    line 32
  7. Distinctive:

    If all three pass: proceed, but note why you believe the work is justified.

    line 36
  8. Distinctive:

    If any answer is unfavorable: say so directly.

    line 37
  9. Distinctive:

    If evidence has changed since the work was originally proposed: reassess the conclusions, not just the facts.

    line 38

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Premise Check

Why This Exists

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.

When to Apply

  • Before investing in any design, plan, or architecture proposal
  • Before extending an existing system with significant new complexity
  • When new evidence (test results, research, changed requirements) arrives that relates to the motivation behind proposed or in-progress work
  • When you find yourself updating facts in a document without reassessing whether the document's conclusions still hold

The Check

Answer these three questions honestly before proceeding:

  1. 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?
  2. 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.
  3. 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.

What to Do With the Answers

  • If all three pass: proceed, but note why you believe the work is justified.
  • If any answer is unfavorable: say so directly. Recommend against proceeding and explain why. Don't just note the concern and keep building — stop and surface the tradeoff to the user.
  • If evidence has changed since the work was originally proposed: reassess the conclusions, not just the facts. Updated facts with unchanged conclusions is the specific failure mode this check exists to catch.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.