Evidence-First Answer — The "Are You Sure?" Discipline
When to invoke
- Any user question that contains: "why didn't", "how come no", "are we", "what's our", "did we", "how much", "revenue", "money", "customers", "conversion", "traffic", "leads", "sales"
- Any pushback that contains: "are you sure?", "really?", "is that right?", "verify", "prove it"
- Before writing any phrase that implies traction or its absence
The hard discipline (4 steps, no skipping)
1. Date-check every number you're about to cite
# For any doc you're about to quote:
git log -1 --format='%ai %s' -- <path>
grep -E "^Updated:|^Status:|2026-" <path> | head -5
If the doc's last-updated date is older than 14 days, treat its numbers as historical, not current. Say "as of
2. Distinguish "plan" from "telemetry"
Words/phrases that mean the number is a forecast, not an actual:
- "30-day revenue plan showed..."
- "Modeled target..."
- "Projected..."
- "If we hit..."
- Any number inside
docs/MONETIZATION_EXEC_SUMMARY_*.mdpast line 30 - Any number inside
reports/gtm/*that isn't backed by a same-filecurloutput
Words/phrases that mean the number is measured:
- "
getBillingSummaryreturned..." - "
curl /v1/billing/summaryJSON..." - "Stripe-reconciled charges..."
- A bash code block with the actual command + output
When in doubt, run revenue-truth skill — query the live endpoint.
3. The "what would change my mind" test
Before submitting an answer, write down: "What single piece of evidence would prove this answer wrong?" Then go look for that evidence. If you find it, rewrite. If you can't find a falsifier, your hypothesis is probably too vague — refine it.
4. State your uncertainty explicitly
End every answer that touches commercial state with:
- What I verified: (curl outputs, file dates, commit SHAs)
- What I'm assuming: (and why)
- What would change the answer: (the specific check the user can run)
The "Are You Sure?" rule (from CLAUDE.md)
When the CEO says "are you sure?" — you're wrong. Dig deeper. Do not defend your current hypothesis. Re-examine from scratch.
Concrete protocol when this triggers:
- Do not restate. Do not add caveats to the previous answer.
- Re-read the docs you cited, checking dates and source labels.
- Run the live check (
revenue-truthskill or equivalent). - Find what you got wrong before defending what you got right.
- Reply with the correction first, then the new answer.
If the CEO asks "are you sure?" a second time, the answer is structurally wrong — not just numerically off. Look for unstated assumptions:
- Am I treating credentials/tokens as terminal blockers when manual routes exist?
- Am I confusing drafted work with sent work?
- Am I confusing engineering velocity with commercial velocity?
- Am I quoting forecasts as actuals?
If a third time: stop, ask the CEO what specific evidence I'm missing, and re-bootstrap from scratch. Do not produce a fourth answer of the same shape.
Anti-patterns this skill exists to prevent
| Pattern | Why it's wrong |
|---|---|
Quoting 5,984 visitors from a "30-day revenue plan" as if measured |
It's a forecast, not telemetry |
Citing docs/VERIFICATION_EVIDENCE.md March-19 numbers as "current 30d" two months later |
Numbers don't auto-refresh |
| Saying "blocked by Gmail SMTP / LinkedIn token" without trying the manual route | Tokens fail; humans don't |
Conflating "drafted in gtm-revenue-loop.md" with "sent" |
Drafting is not sending |
| Saying "deployed" or "live" without curl output | Hard-block rule #6 |
Exit criteria
An answer is ready when you can show:
- A live curl OR a file path + line number with a date check, for every number
- A "what would change my mind" sentence
- No "should", "probably", "I think" without "verified by
<command>" attached