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
- ptokos/agent-verification-skillstheir own version, first seen Oct 20, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- ptokos/agent-verification-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository23 other files it gives its agents.
- brainstormingSkill
- claude-md-creatorSkill
- context-managementSkill
- deliberationSkill
- dependency-managementSkill
- dispatching-parallel-agentsSkill
- error-recoverySkill
- executing-plansSkill
- finishing-a-development-branchSkill
- frontend-designSkill
- performance-investigationSkill
- receiving-code-reviewSkill
- refactoringSkill
- requesting-code-reviewSkill
- self-consistency-reasonerSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- token-efficiencySkill
- using-git-worktreesSkill
- using-superpowersSkill
- verification-before-completionSkill
- writing-plansSkill
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
- Distinctive: line 16
Before investing in any design, plan, or architecture proposal
- Distinctive: line 17
Before extending an existing system with significant new complexity
- Distinctive: line 18
When new evidence (test results, research, changed requirements) arrives that relates to the motivation behind proposed or in-progress work
- Distinctive: line 19
When you find yourself updating facts in a document without reassessing whether the document's conclusions still hold
- Distinctive: line 26
Look at what's already in place.
- Distinctive: line 32
If the answer is "nothing breaks, things are just slightly less elegant" — that's a strong signal to skip it.
- Distinctive: line 36
If all three pass: proceed, but note why you believe the work is justified.
- Distinctive: line 37
If any answer is unfavorable: say so directly.
- Distinctive: line 38
If evidence has changed since the work was originally proposed: reassess the conclusions, not just the facts.
≈ “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.
Files
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:
- 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.
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.
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
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.

