How do I install the Assumption Test skill?

Run npx skillmds@latest add neeeophytee/assumption-test in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Assumption Test safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Assumption Test?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Assumption Test free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Assumption Test?

neeeophytee (@neeeophytee) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Assumption Test by neeeophytee — Agent Skill

Name: Assumption Test
Author: neeeophytee

Assumption Test

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.

neeeophytee ddf0b4d 2.5 KB Updated Sep 17, 2026

File contents

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.

---name: assumption-testdescription: 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.---# Assumption testA 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.## Steps1. 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.2. 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.3. 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.4. 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.5. 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.

Frequently asked questions