On-demandOn-demand: invoked explicitly — never occupies your agent's context until called.
◆Coding pack
Last verified 10/12/2026
What it changes
Passed 19 of 20 test cases with the skill, and 13 of 20 without it.
Without skill65%
With skill95%
Checks it passed that the model alone missed
The response advises against invoking a separate review agent.
The response identifies NOT_PROVEN as the appropriate verdict.
The response limits the stall investigation to at most one fresh helper.
and 5 more in the full report
7 fixed12 passed either way0 still failing1 broke5 errored
Pass-rate lift
+30 pp
Tokens
+44%
Agent turns
0%
Response time
-53%
Model gemini-3.6-flashMeasured 10/12/2026v719 of 25 cases passed with skill · 20 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 7
Prompt
An independent validator reviewed `cmd/export.go` and flagged one missing error message format check along with two optional stylistic comments. The author repaired the error message check and re-ran the test suite cleanly. Should the author dispatch another validator review to inspect the fix?
What was checked, without and with the skill
Checked
Without skill
With skill
The response advises verifying the fix with a check.
Passed
Passed
The response advises completing the task without initiating a second validation round.
Missed
Passed
case-12 · gemini-3.6-flash · 10/12/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md116 lines4 filesincludes scripts
RPI
Own the authorized outcome through finish. Use the native coding agent and
shell. BD or the caller's tracker owns work and handoffs; Git owns content and
delivery. AgentOps supplies a small charter and one fresh judgment where a
mistake is costly, not a scheduler.
Operating charter
Use the existing accepted outcome, scope and real bounds. A clear change
needs no Plan, Recall or Learn worksheet. Resolve uncertainty only when it
could change the implementation or acceptance decision.
Take the smallest acceptance-advancing action. Plan
shapes missing intent or revises a disproved approach. Once an implementer
can act and a validator can judge, implement; do not keep improving the plan.
Approach revisions preserve acceptance and authorized scope.
Acceptance changes need caller authority.
Implement and repair ordinary known defects directly.
A known test failure needs a fix and a discriminating check, not another
planning phase, council or helper.
Use focused checks during edits and complete required integration checks
before finishing. Reuse valid exact-input receipts; rerun affected checks
after changes. Reserve capacity for integration and repair. Keep a subject
unchanged while it is being judged.
Spend validation where a mistake is costly. For an ordinary change the
checks and CI are the gate: finish. Obtain Validate
from one fresh author-distinct context only when the caller asks, when a
mistake cannot be cheaply undone after it lands (a published release or
instructions users will follow, a security boundary, destroying data or
tracker state, deleting a check that protects the product), or when no
deterministic check covers the changed behavior. Use the author's model
family unless the caller selects additional legs; explicitly required
reviewers remain required.
One round. Give the validator the accepted criteria, the exact subject and
one question written before it starts, never the author's confidence or
desired verdict; it does not re-run the checks. Repair what fails the
accepted behavior or would mislead a user, break install or the CLI, or
remove protection for the product; treat the rest as optional notes. Confirm
each repair with a check and finish. A repair does not start another
review, and NOT_PROVEN is reported with its gaps, not chased. Keep review