← All skills
Assumption Check
Makes the agent state what it is assuming — and verify it — before it writes a line.
planningaccuracyreviewsafetyminutes
When to reach for it
Before any task where being wrong is expensive: touching code you did not write, changing something with callers you have not seen, or acting on a bug report you have not reproduced.
What changes
- The agent lists what it believes about your codebase before editing, so a wrong belief surfaces as a sentence instead of as a broken build.
- Each belief is checked against the repository — a file read, a grep, a test run — rather than asserted.
- Unverifiable assumptions become questions to you, instead of silent guesses.
- Cuts the loop where an agent confidently builds on a misread and you spend the next hour unwinding it.
Pairs with
- Budget the SessionDecides in one sentence what this session is for, and writes down what it will not touch.
- Constraint SurfaceGets the real limits — deadline, platform, budget, who inherits it — out of you before anything is designed around a guess.
- Dependency AuditDecides whether a library earns its place, or whether twenty lines of your own would do.
SKILL.mdpaste into your agent
Assumption Check
Before writing or editing code for this task, do this first.
1. Write down what you are assuming
List every belief the change depends on. Be specific enough that each one could turn out false:
- Where the behavior lives ("the retry logic is in
lib/http.ts") - Who calls it ("only the sync worker uses this")
- What the current behavior is ("it already returns null on timeout")
- What the environment provides ("this runs in Node, not the browser")
- What the user means by an ambiguous word ("'slow' means p95 latency")
2. Verify each one against the repository
For every assumption, do the cheapest thing that would prove it wrong:
- Read the file, do not recall it.
- Grep for callers before believing something has one caller.
- Run the failing case before believing you understand the failure.
- Check the lockfile or manifest before assuming a dependency exists.
Mark each assumption confirmed, corrected, or unverifiable.
3. Handle what is left
- Corrected — restate the plan against what is actually there.
- Unverifiable from the repo — ask the user. One specific question beats a paragraph of hedging, and beats guessing entirely.
4. Only then, act
State the plan in one or two sentences and proceed.
Rules
- Do not skip this because the task looks small. Small tasks are where an unchecked assumption is cheapest to make and most likely to ship.
- Do not list assumptions you have no intention of checking. An unverified list is theater.
- If verification contradicts the user's premise, say so before building on it. "The file you named does not import that" is more useful than a change that pretends it does.