question-the-premise
Skill2 starsChanged 4 months agoMITView on GitHub
Use when several well-reasoned fixes on the same hypothesis have all failed, or when a symptom looks impossible.
In this repository19 other files it gives its agents.
- build-release-mindsetSkill
- critical-thinkingSkill
- de-ai-proseSkill
- entry-point-auditSkill
- feasibility-guardSkill
- fix-in-the-shared-layerSkill
- fix-the-root-causeSkill
- independent-review-gateSkill
- logging-for-remote-diagnosisSkill
- no-duplicate-logicSkill
- opportunistic-fixesSkill
- performance-at-scaleSkill
- plan-with-teethSkill
- project-onto-all-systemsSkill
- tests-with-teethSkill
- user-action-edge-casesSkill
- using-instinctsSkill
- ux-designer-mindsetSkill
- verify-against-codeSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
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 18
After about two or three failed fixes, treat the premise as the suspect, not the code.
- Distinctive: line 22
If your evidence for the premise is a missing log line, load logging-for-remote-diagnosis first: absence is not proof.
≈ “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
The rule
Working by hypothesis, test, confirm only helps inside the right frame. If two or three well-reasoned fixes all fail, the likely problem is your premise, not your next fix. Stop and ask: have I actually confirmed the bug is in the layer I'm attacking?
This sharpens superpowers' systematic-debugging: that skill runs the loop; this one says when to stop looping and suspect the frame itself.
Fires when
Two or three fixes on the same hypothesis have all failed. A symptom that looks impossible — works in one path, fails in another that shares the same code. You're about to do a big rewrite or a deep dive to force the current theory to work.
How to apply
After about two or three failed fixes, treat the premise as the suspect, not the code. Get an outside view from someone or something that sees the whole story and has no stake in your theory.
Chase the impossible-looking discrepancy. It points at the layer you're not looking at.
If your evidence for the premise is a missing log line, load logging-for-remote-diagnosis first: absence is not proof.
Worked example
A test is flaky. You add a retry, still flaky. You add a sleep, still flaky. You mock the clock, still flaky. Three reasoned fixes, all failed.
The premise was wrong. Another test in the suite mutates a shared global, and the run order decides the outcome. Every timing fix was reading the wrong layer entirely.
The tell was right there the whole time: it passed alone but failed in the suite. That impossible-looking symptom was pointing at the real layer.
Red flags
| Thought | Reality |
| "Just one more fix and it'll work" after 2–3 have failed | Suspect the premise instead. |
| "The data confirms my theory" | Data read inside a wrong frame confirms the frame. Check the layer. |
| "I'll just rewrite this module" | Before you've confirmed the bug is even in that module. |
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.