# Verify The Premise

> Verify the Premise

- Skill: `bahadirkisbet/verify-the-premise` (Agent Skill)
- Install (CLI): `npx skillmds@latest add bahadirkisbet/verify-the-premise`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bahadirkisbet/verify-the-premise/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: bahadirkisbet (https://skillmd.com/u/bahadirkisbet)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bahadirkisbet/verify-the-premise

---


# Verify the Premise

Never assume. Decide, suggest, and act on **data** — observed behavior, real code, actual output — not on what you or anyone expects to be true.

This is a behavior, not a step you do once. Before you act on a belief, ask: **do I know this, or am I assuming it?** If assuming, verify first.

## Iron Law

**NEVER ACT ON AN ASSUMPTION — READ IT, RUN IT, OR TRACE IT FIRST.**

## The Rule

A premise and a conclusion can each be independently right or wrong. A correct conclusion drawn from a wrong premise is luck; a wrong conclusion from a correct premise is a missed fix. Check the premise *and* the conclusion against reality before acting on either.

## What "Verify" Means

- **Read the code**, don't recall it. The function you remember may have changed.
- **Run it / observe the output**, don't predict it. "This should return X" is a hypothesis until you see X.
- **Trace the actual path.** "The lower layer already retries" is only actionable if it actually does — confirm which layer retries before deleting the other.
- **Check what THIS source emits**, not what the class of thing usually emits. "This 429 branch is dead" requires confirming this endpoint emits 429 and not, say, 502.

## Apply To

- Review findings — yours and others'. Verify the claim before you fix or dismiss it.
- Docs, comments, memories, tickets — they drift from the code. Trust the code.
- Your own "I know this works" — the most expensive assumption. Confirm it.
- A user's stated cause — respectfully verify; they may be reporting a symptom, not the cause.

## When You Cannot Verify

Say so. State the assumption explicitly, what would confirm it, and the risk if it's wrong — then let the decision account for the uncertainty. An unverifiable premise that is flagged is safe; an unverified premise acted on silently is the failure.

## Red Flags — STOP

| Thought | Reality |
|---|---|
| "I'm pretty sure this function does X" | Pretty sure is a guess. Read it. |
| "The docs/comment say it works this way" | Docs drift from code. Trust the code. |
| "The lower layer already handles it" | Confirm which layer, on THIS path, before relying on it. |
| "This branch is obviously dead" | Confirm what this source actually emits before deleting it. |
| "It worked last time, so it works now" | Last time is not this time. Observe it. |

## Common Mistakes

- Acting on a remembered API/signature instead of reading the current one.
- Accepting a review finding's premise without tracing the real behavior.
- Predicting output instead of running and observing it.
- Generalizing ("X usually does Y") onto THIS specific case without checking it.
- Letting a confident claim substitute for evidence — confidence is not data.

**Pairs with:** `bardak:blind-review` and `bardak:pipeline-verification` (verify each finding and the real path before acting), and `bardak:no-silent-errors` (confirm a fault path is real, not assumed).