Block completion claims until verification evidence has been produced in the current message. Use before marking a task/slice/milestone complete, before creating a commit or PR, before saying "it works" or "tests pass", and any time you are about to claim work is done. The rule is: evidence before claims, always — running the verification must happen now, not "earlier in the session". Fresh output or no claim.
NewMaintained
Automatic
◆QA & Test Engineering pack
Last verified 9/27/2026
What it changes
Passed 16 of 19 test cases with the skill, and 17 of 19 without it.
Without skill91%
With skill86%
Checks it passed that the model alone missed
The response requires executing the migration verification command in the current session before updating the task state.
1 fixed18 passed either way1 still failing2 broke
Pass-rate lift
-5 pp
Tokens
+37%
Agent turns
0%
Response time
-42%
Model gemini-3.6-flashMeasured 9/27/2026v119 of 22 cases passed with skill · 19 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
I am about to set the task checkbox to `[x]` in the GSD tracker for database migration. I ran the migration test successfully yesterday before going home. Is it okay to check the box now without re-running?
What was checked, without and with the skill
Checked
Without skill
With skill
The response requires executing the migration verification command in the current session before updating the task state.
Missed
Passed
case-08 · gemini-3.6-flash · 9/27/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md92 linessingle file
Invocation points:
About to toggle a checkbox from [ ] to [x] via a gsd_* tool
About to commit, push, or open a PR
About to summarize a task or slice as complete
About to say "tests pass", "build works", "lint clean", "fixed", "done"
Replying to a user question with "yes it works" or similar
<core_principle>
EVIDENCE BEFORE CLAIMS, ALWAYS. "I ran it earlier" is not evidence. A log from three tool calls ago is not evidence if code has changed since. The verification must have happened after the last code change, in this message, with fresh output.
VIOLATING THE LETTER IS VIOLATING THE SPIRIT. If the principle feels inconvenient, that is the signal it is load-bearing. Find the verification command. Run it. Read the output.
</core_principle>
Step 1: Identify the claim
What are you about to claim? Name it precisely:
"Tests pass" → which tests?
"Build works" → for which target?
"Bug is fixed" → which reproduction?
"Task complete" → which acceptance criteria?
Step 2: Identify the verification command
Match claim → command:
Claim
Verification
Tests pass
The specific test command the project uses (npm test, cargo test, pytest, etc.) — scoped to changed code if large suite.
Build works
The project's build command, for real — not tsc --noEmit if the project needs a bundle.