Skill

verify-first

Every assertion about the codebase, product, or market is a hypothesis. Verify it against live sources before committing to action. The master discipline: verify first, act second. Apply before committing to any claim.

Category
core
Version
0.1.0
License
MIT
Status
active
Length
90 lines
Source
skills/core/verify-first/SKILL.md

Composes with measure-first re-verify-findings read-before-build

Install and discovery

npx --yes --package @youcisla/agent-foundry agent-foundry-install

After the installer runs, this record is available as verify-first. See the docs for harness roots and verification steps.

Contents

Verify First

Every assertion is a hypothesis. Verify before committing.

When to Use

Always active. This is the meta-discipline that governs all work.

  • Always. This is the foundation.
  • Especially: when inheriting work from another agent or audit
  • When the user says "the code does X"
  • When a plan depends on an assumption about the system

Procedure

1 — Tag every input as a hypothesis

Before accepting anything as fact, mentally tag it:

  • Untested assumption (brief says X)
  • Verified fact (I checked: X is true)
  • Stale truth (was X, now Y)

2 — Triangle verification

For any important claim, verify from at least 2 independent sources:

Claim: "The Stripe account is ready for billing"
- Source 1: Stripe MCP (products list → 0 products)
- Source 2: Code search (VITE_BILLING unset, test key only)
- Conclusion: ❌ wrong — wrong account entirely

Best sources to triangulate:

  1. Live DB query (what's actually stored)
  2. Live API call (what the server actually does)
  3. Source code (what the repo says)
  4. Browser (what users actually see)
  5. Git log (when was it last changed)

3 — Log and generalize

When you discover a new type of stale claim, add it to known-patterns so future sessions don't fall for the same trap.

Composes With

  • re-verify-findings — for audit/bug claim context
  • measure-first — adds live data to the triangulation
  • read-before-build — applies the same discipline to plan claims

Anti-patterns

  • Repeating a brief's claim without checking it this session.
  • Trusting an agent's report that a file or row was written.
  • Calling a compile a behavior check.
  • Collapsing timeout, failure, and low score into one status.

Verification Checklist

  • [ ] Every important claim has a source and a verdict.
  • [ ] Artifacts were re-read, not trusted from a report.
  • [ ] Untouched files are byte-identical where claimed.
  • [ ] Failure states are distinguished exactly.
  • [ ] Unverifiable claims are reported as unverified.

Verify the Artifact

  • Verify the world, not the self-report: re-read the stored row, artifact, or response. An agent's claim that it wrote something is not evidence.
  • Assert untouched files are byte-identical, not merely present.
  • A guard only guards if the intended regression fails it. Introduce the regression once, watch the test go red, then revert.
  • Preserve exact failure status: timeout, unparseable, call failure, and low score are four different facts.
  • When two runs are compared, prove the confounders match: same config except the tested flag, same provider stub, no retries or preemption.

Evidence Requirement

A verification claim needs a reference: a file path with line range, a command output chunk, or a stored execution id. A prose assertion is not evidence. If the reference cannot be produced, report the claim as unverified.