/audit-my-assumptions

name: audit-my-assumptions
description: Use when a finished thing — a source, a result, code, or the record — is about to be trusted or consumed; the gate fires before the work leans on it. Fire FIRST - before a number is BUILT on inherited sources or PRESENTED from them - when the silent assumptions baked into procs, queries, exports, or workbooks have not been validated; the clean, small, unremarkable figure is the primary case, not the edge case. Surfaces every inherited definition/filter/grain/unit/date-basis as a numbered assumption, grades by blast radius, falsifies the load-bearing ones, routes intent calls to the owner. Detects: "the data team ran the proc, turn it into my report/deck", "put together the headline numbers / board figure from this proc/query/export", "give me the number from this report", "I'm rebuilding this from these procs", "before I present this". Within this family: a controlled A/B result is audit-my-experiment; a forecast is audit-my-forecast; the code itself is review-my-query; the whole record is kb-reconcile. Read-only: never touches a live system, never computes the deliverable.
allowed-tools: Read, Write

audit-my-assumptions

The colleague who makes you write down what you're taking for granted before you build a quarter of work on top of it — then tries to break the load-bearing ones while it's still cheap.

When to use

Fire FIRST — before you **build/derive** on it AND before you **present/stand behind** it. Fire when about to build or derive on top of something you did not author and fully verify, OR when about to present a number (of any provenance — inherited, self-derived, or long-trusted) and you want its premises checked before the room: rebuild a report from inherited stored procs, derive a new metric from an existing query, stack more years onto an old workbook, turn a proc's output into a deck, re-point a model at a new source. The question is "what am I silently assuming, and which of those assumptions would poison everything if it's wrong?" — asked **before** the build, not after a stakeholder squints at the output. Do NOT fire when a number is already in hand and known wrong (that's `triage-my-number`, downstream), to pin what a metric should mean (`kpi-contract`), to review one code object against a contract (`review-my-query`), or to audit a whole accreted knowledge base (`kb-reconcile`). This runs at the **front** of the work, on the inputs.

**This vs. its neighbors.** The gate is *no symptom yet*: you're about to build/derive on, or present/stand behind, a number whose load-bearing premises are unexamined (any provenance — inherited, self-derived, or long-trusted) and you want them falsified first. Route elsewhere when the case differs — a number *already known wrong* → `triage-my-number` (diagnose the whole failure surface); a query's *code logic* suspect while the definition is trusted → `review-my-query`; your *whole accreted knowledge base*, not one source → `kb-reconcile`. Among the present-moment trio — **premises → here · phrasing → `brief-my-findings` · pushback → `defend-my-number`** — fire here for *"what am I assuming under this number?"* (it can be clean and still wrong); for *"how do I write this up?"* use `brief-my-findings`; for *"how do I hold up under live challenge?"* use `defend-my-number`.

The trap this exists to beat

Asked to "rebuild this from the existing procs" or "turn this proc output into my report," a capable assistant does the build well — and **inherits every silent premise in the source as fact**. It copies the population definition, the magic exclusion list, the date filter, the unit a column is in, because that is "what the source does" — and ships a plausible output resting on an assumption it never named, that may be stale, wrong, or built for a different purpose years ago. The cascade is invisible *precisely because the output looks right*: a wrong foundational assumption doesn't error, it produces a confident, well-formatted, wrong number that only a domain expert catches, late. **A clean, small, unremarkable number is not evidence of safety — a stale definition produces a clean number too** (measured: handed a tidy single-year figure, a bare model builds the deck and never questions the inherited definition; the same model, audited, stops and catches it). A second, related failure: it **validates a load-bearing premise against a derivative** (the prior report, an inline reconstruction) or with a **whole-table sum** instead of the generative source on the matching scope — so the check passes while the assumption is still wrong. This skill refuses to build on an un-excavated premise: it inventories the inherited assumptions, grades them by blast radius, tries to *falsify* the load-bearing ones against the most authoritative source it can reach — including the population's behavior **over time**, where a regime change hides — routes the intent-type ones to the owner, and only then declares the foundation safe.

The loop

1. **Inventory the inherited premises.** For each source you will build on (proc, query, export, prior report, doc), extract every decision it makes *silently*: the population/definition filter (what counts as the thing — does "package" mean what the business means?), the grain (one row = what), the **unit each measure is in** (is "Revenue" really revenue, or cost-in-a-swap?), the **date/period basis** (order vs fulfilment vs as-of), the **identity key** (does one `ItemLabel` mean one property?), the magic constants and exclusion lists, the joins that could fan out. Each becomes a numbered assumption with a verbatim cite. Inherited ≠ verified. The same trunk classes apply whoever set the premise — the source, **you** (the population you scoped, the joins/exclusions you chose), or **a long-ago author** of a trusted artifact nobody re-examines. Two prompts beyond the inherited case: *self-derived* — "which choices did I make that a domain expert would challenge?";