Skip to content

Verify a brief's premises before acting

Test a brief's load-bearing claims — where something lives, what a job does — before opening a single file to edit.

Most bad work is correct work aimed at a premise that was never true. A brief arrives asserting where something lives, what a job does, or which package is already a dependency — and the cheapest possible moment to test those assertions is before a single file is opened for editing.

Start here

One prompt to start
Before we open a single file to edit, list every load-bearing assumption this brief is resting on, confirm each one against a real file and line number, and check that any new dependencies it names actually exist on the registry.

Needscompass, confab

Beats

Run these in order. Each prompt is copy-pasteable straight into Claude Code.

  1. compass:compass-verify-assumptionsalso in 1 other recipe

    Once implementation starts, a false premise is discovered as a bug rather than as a claim.

    Run this beat on its own
    prompt
    before we do any of this, list the assumptions this request is resting on and tell me which ones you can't actually confirm
  2. compass:compass-ground-evidencealso in 2 other recipes

    Grounding is cheap on five claims and expensive on a finished diff.

    Run this beat on its own
    prompt
    don't make this up — every claim about this repo needs a file and line number behind it
  3. confab:confab-dependency-auditalso in 2 other recipes

    A hallucinated or typosquat-adjacent package name is free to catch now and a supply-chain incident later.

    Run this beat on its own
    prompt
    the plan names three new dependencies — check they actually exist on the registry before we add any of them

Worked example

Grounded in — why this beat order is trustworthy

a brief asserting that the symbol indexer lives only in `tools/symbol-indexer/` collapses on the first grounding pass: five plugins each carry a byte-identical `scripts/build_symbol_index.py`.

Do / Don't

  • List the brief's assumptions and flag which ones can't actually be confirmed, before implementation starts.
  • Ground every claim about the repo in a real file and line number -- cheap on five claims, expensive on a finished diff.
  • Check that every newly named dependency actually exists on the registry before adding it.
  • Don't start implementing on a premise that hasn't been checked -- a false premise discovered mid-implementation reads as a bug, not as the false claim it actually was.
  • Don't assume a brief's claim about where something lives is unique just because it names one location -- this repo has had a brief collapse on exactly that assumption.
  • Don't add a named dependency without confirming it exists -- a hallucinated or typosquat-adjacent package is free to catch now and expensive later.