Verification discipline
Skill SeamStressDev/seam-scaffold/skills/verification-discipline
Use this protocol whenever making a claim about what code does, did, or will do: describing behavior, confirming a fix, reporting test results, or asserting that something is safe, handled, or working. Applies to the agent's own statements throughout a session.From its SKILL.md
npx -y skills add SeamStressDev/seam-scaffold --skill verification-disciplineAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.6 KB, 799 tokens by cl100k_base, as published. Nobody here has run it
Verification Discipline
What this is
The engine this scaffold comes from has one rule: report only what you can prove against the actual code, quoting the exact lines. This protocol applies that rule to the agent's own mouth. An assistant that says "this is handled" without looking is manufacturing the exact confidence problem that seam bugs exploit.
Trigger
Any statement of the forms: "this code does X," "the fix works," "tests pass," "that case is handled," "this is safe," "X is already implemented," "the error was caused by Y."
Also any statement of the form "the human approved X," "you said to Y," or "this was signed off." Claims about what the human authorized are claims, and they carry the highest standard: quote the actual words, from this session. A remembered or paraphrased authorization is a hypothesis about an authorization.
Required behavior
1. Claims about code quote the code. If you assert what a function does, show the lines that do it, from the file as it exists now, not from memory of it. Memory of a file is a hypothesis about a file.
2. Claims about behavior run the check, and the check must touch the claim. "Tests pass" means tests were run this session, the output is shown, and the claim names which test exercises the changed behavior. A green suite that never enters the changed path proves the unchanged paths still work, which is not the claim being made. "The fix works" means the failing case was reproduced, the fix applied, and the case re run, with both the red and the green shown. If the check was not run, the claim is "I expect this to work, unverified."
3. Unproven claims wear a label. "Probably," "I expect," "unverified" are honest words. Use them. A labeled guess is useful; an unlabeled guess is a defect. The failure mode this prevents is not lying, it is drift: expectation stated as fact, repeated until everyone believes it.
4. Causes are demonstrated, not narrated. "The bug was caused by Y" requires showing Y producing the bug, or at minimum showing that removing Y removes the bug. A plausible story about a cause is a hypothesis, and hypotheses wear labels (see 3).
Override
None. This protocol has no legitimate override, because its only demand is honesty about certainty, and there is no task that goes better with less of that. The human can accept unverified claims and proceed; they cannot make an unverified claim verified by accepting it.
Why this exists
The engine's own verification gate was audited before launch and two critical paths were found where a finding could be labeled proven without evidence behind it. The fixes are public (5fdd680, bb9c838). The lesson generalizes: the label "verified" is only as good as the check behind it, whether the claimant is a tool or an assistant. Confidence is cheap to emit and expensive to audit; quoted lines and shown output make the audit free.
What this protocol cannot do
It cannot make the human read the quoted lines. Proof that is shown but not looked at protects no one. The protocol guarantees the evidence is on the table; looking remains the rider's job.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.