assumption-test
Skill339 starsChanged 2 months agoMITView on GitHub
Test a consequential technical assumption with a small, falsifiable experiment before committing to an approach. Use when a plan depends on uncertain runtime, integration, or data behavior that inspection alone cannot establish. Not for preference interviews or routine implementation.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agent-interface-designSkill
- blindspot-passSkill
- brainstorm-prototypesSkill
- change-quizSkill
- context-auditSkill
- implementation-notesSkill
- implementation-planSkill
- interview-meSkill
- pitch-packagerSkill
- progressive-disclosureSkill
- reference-huntSkill
- regression-proofSkill
- test-blindspotsSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
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 12
Read the request, relevant code, and existing evidence.
- Distinctive: line 15
Run the experiment within the user's authorized scope.
- Distinctive: line 21
Do not use production writes, real payments, destructive operations, or newly incurred costs without authorization.
- Distinctive: line 23
Do not fix the implementation or broaden into a build unless the user requested it.
≈ “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
Assumption test
A plausible assumption can survive every planning conversation and still fail on contact with the system. Turn the consequential uncertainty into a question an experiment can answer.
Steps
- Read the request, relevant code, and existing evidence. If inspection already settles the question, cite that evidence and stop; do not manufacture an experiment. If several assumptions remain, select the one whose failure would most change the approach.
- State the assumption as an observable prediction. Define what would refute it, what would support it within the tested scope, and what would leave it inconclusive. Set those criteria before observing the result.
- Design the smallest discriminating experiment. Use an isolated fixture or test environment, the real component under question where available, and a bounded number of operations. Name what the setup cannot represent; a mock's behavior is not evidence about its provider.
- Run the experiment within the user's authorized scope. Preserve the command, relevant inputs, actual output, and environment details needed to reproduce it. If a tool or dependency is unavailable, report the experiment as unrun or inconclusive, with the missing prerequisite.
- Close with the assumption, method, observation, verdict (supported within scope, refuted, or inconclusive), and the planning decision this evidence changes. Recommend the next discriminating check only if it could change that decision. Keep temporary code separate from the production implementation.
Guardrails
- One successful trial does not establish a universal claim. State the tested conditions and remaining uncertainty, particularly for concurrency and performance.
- Do not use production writes, real payments, destructive operations, or newly incurred costs without authorization. An experiment does not grant additional permissions.
- Distinguish the component failing from the experiment failing to run. Never turn missing access or a broken fixture into a verdict about the system.
- Do not fix the implementation or broaden into a build unless the user requested it. The deliverable is evidence that informs a decision.
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.