Output Verification

Wrong skill? Pre-commit checks → pre-commit-gate. Completion checklist → verification-before-completion. Code review → progressive-code-review-gate.

Purpose: Prevent confabulation disguised as verification Core Principle: You cannot describe output you haven't read. Period.

Companion Skills

• pre-commit-gate: Pre-commit quality checks
• verification-before-completion: Completion checklist
• holistic-repo-verification: Full repo health

When to Use

• Before describing what a generated file contains
• Before saying output "looks good" or "rendered correctly"
• Before approving any artifact for sharing or handoff
• Before summarizing script/command output
• After generating any deliverable — before making ANY claims about it
• When presenting results back to the user — "here's what was created" requires reading what was created

⚠️ ACTION-PATTERN TRIGGER

This skill fires on a behavior pattern, not just phrases:

IF: you generated/created/wrote an artifact (file, API response, script output)
AND: you are about to describe what that artifact contains
AND: you have NOT read the artifact back since generating it
THEN: STOP. This skill applies. Inspect before describing.

The phrase triggers ("looks good," "verified") are a backup. The primary trigger is the action pattern above. If you catch yourself writing a summary of generated output without a tool call between the generation and the summary, this skill has already failed.

The Anti-Pattern

This skill targets a specific failure mode that is NOT "forgot to test."

Confabulation disguised as verification: The agent generates a description of what it expects to see in the output and presents that description as though it observed it.

Key characteristics:

• Description is plausible (matches what should be there based on prior work)
• No tool call, file read, grep, or inspection was executed between generating and describing
• The user cannot distinguish the confabulated review from a real one
• Plausible fiction is worse than an obvious error because the user trusts it

The existing verification-before-completion skill asks "did you run the command?" This skill asks: "did you actually READ what the command produced?"

The Iron Law

NO CLAIMS ABOUT OUTPUT WITHOUT A PRECEDING INSPECTION TOOL CALL

If there is no tool call between "generate" and "describe,"
the description is fiction.

The Gate Function

BEFORE making ANY claim about generated output:

1. IDENTIFY: What output am I about to describe?
2. INSPECT: Execute an appropriate inspection action (see table below)
3. READ: Actually read what the inspection returned — all of it
4. COMPARE: Does what I see match what I expected?
   - If MISMATCH: Report the actual state, not the expected state
   - If MATCH: Cite specific evidence (line numbers, counts, grep output)
5. ONLY THEN: Make the claim, with evidence

Skip any step = confabulation, not verification

Required Inspection Actions

Detection Signals — Am I Confabulating?

If cumulative weight ≥ 5: STOP. You are confabulating. Go back to step 2 of the Gate Function.

Common Rationalizations (All Invalid)

"I just wrote it" → you know intent, not result. "Exit 0" → finished ≠ correct. "Source looks right" → source ≠ render. "I checked the important parts" → cite line numbers or it didn't happen. "Counts are close enough" → 13 ≠ 17, the difference is the bug.

Incident History

2026-03-27: Agent generated PDF from wiki export. Script printed "Processing 17 documents" (expected 13) — agent didn't notice. PDF contained 4 confidential docs + all 15 Mermaid diagrams showed "Syntax error." Agent said "all rendered correctly" and "ready to hand off" without opening the PDF. Near-miss: confidential docs almost sent to external auditors.

Example

# Verify generated output matches expectations
diff <(cat expected-output.txt) <(cat actual-output.txt) || echo "MISMATCH"
# Check for truncation
wc -l actual-output.txt

Failure Modes