validate
Skill453 starsChanged 4 months agoApache-2.0View on GitHub
Freshly judge whether a finished change and its claims meet original acceptance: PASS, FAIL or NOT_PROVEN. Use when: asked for a go/no-go, sign-off or independent verdict.
63 other projects use a version of this.
Adopted by
Most recently taken up by
- joeldevz/skynex-pitheir own version, first seen Nov 8, 2026
- 99Luuk/Forge-or-Scraptheir own version, first seen Nov 8, 2026
- etr/groundworktheir own version, first seen Nov 8, 2026
- cykedev/vereinsheimtheir own version, first seen Nov 3, 2026
- vzhukovs/podman-desktop-kittheir own version, first seen Nov 1, 2026
- aya-taleb/biz-ready-skillstheir own version, first seen Nov 1, 2026
Used with
Projects with it also use policy-init, create and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
open-coder-aiSkillpolicy-init
Create conformant Chock policy from request. args(request, target_path,
Also in 3 projects that use this
MicrosoftSkillcreate
Also in 4 projects that use this
HermeticOrmusSkillclose
End-of-session ritual. Captures session state, updates auto-memory, writes a session summary, then exits the session cleanly.
Also in 4 projects that use this
Hugging FaceSkillsprint
Work on a batch of GitHub issues in parallel using Agent Teams. Creates one worktree per issue with TDD enforcement, coordinates via a lead agent, then produces stacked PRs.
Also in 4 projects that use this
qtzx06Skilleval
Evaluate trained YOLO model accuracy with mAP metrics and per-class error analysis. Identifies failure cases for targeted improvement. Use after training.
Also in 4 projects that use this
csiddhant796-blipSkillboard
Read, write, and browse the AgentHub message board for agent coordination.
Also in 3 projects that use this
Other versions63 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 63
- iPlug2/iPlug2★ 2.4ksame name
- sirius-db/sirius★ 1.1ksame name
- H-mmer/pentest-agents★ 815same name
- nudgebee/nudgebee★ 520same name
- microsoft/skills-for-copilot-studio★ 486same name
- scaccogatto/okf-skills★ 444same name
- whawkinsiv/solo-founder-skills★ 260same name
- whawkinsiv/claude-code-skills★ 258same name
- OffchainLabs/arbitrum-docs★ 252same name
- cortex-tms/cortex-tms★ 180same name
53 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository32 other files it gives its agents.
- AGENTS.mdAGENTS.md
- cli/AGENTS.mdAGENTS.md
- agent-nativeSkill
- agy-nativeSkill
- architectureSkill
- claude-execSkill
- codex-execSkill
- councilSkill
- craft-goalSkill
- docSkill
- domainSkill
- ergonomicsSkill
- idea-genieSkill
- implementSkill
- interviewSkill
- memorySkill
- navigateSkill
- orchestrateSkill
- planSkill
- postmortemSkill
- premortemSkill
- refactorSkill
- researchSkill
- reverse-engineerSkill
- reviewSkill
- rpiSkill
- securitySkill
- skill-builderSkill
- skill-evalSkill
- testSkill
- triageSkill
- using-gcSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 2 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 53 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 74
Every criterion is verified with evidence, checked scope is nonempty and not_checked is empty: PASS.
- Distinctive: line 95
no deterministic check covers the behavior that changed.
- Distinctive: line 145
Default to one fresh reviewer in the author's model family (Codex/OpenAI for Codex/OpenAI, Claude/Anthropic for Claude/Anthropic), on the …
- Very specific: line 203
Keep prior findings visible.
- Very specific: line 210
Only when the caller requests machine-readable evidence or a declared consumer requires it, persist through ao provenance store-verdict …
“Common” is measured: kept by at least 6 in 10 of the 53 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Validate
Freshly judge one finished candidate against its original acceptance, return
PASS, FAIL, or NOT_PROVEN with criterion-level evidence, and stop.
Neighbours: advice or a second look is Review; whether a
stated claim holds is Research. This file
carries every rule the judgment needs. Linked files, including
RPI boundaries and
mechanics, add depth only: if one cannot be read,
judge from this file and say which was unavailable.
Rules that decide the verdict
- The author cannot issue a binding PASS, and advisory findings, such as a Review or Council report, cannot stand in for this judgment: test them as claims. An author's summary, confidence or assurance is a claim to check, not evidence; explanation alone is not proof.
- Each criterion needs its own evidence on the exact candidate. A criterion
nobody demonstrated goes in
not_checkedand never counts toward PASS. - A changed test, tolerance, golden, suppression or acceptance text must still satisfy the original intent. Green obtained by weakening the oracle is FAIL for the criterion it was meant to prove, and that green is not evidence. The same holds for green obtained by changing what the check runs against: product code that behaves differently when it detects a test or CI environment, a failure path newly silenced by an empty handler or discarded error, or a check made non-blocking, skipped or bypassed. Each needs a reason visible in the change that still serves the original intent.
- A receipt is check output tied to this subject: command, result, and commit SHA or digest; a summary such as "suite is green" is a claim. Read receipts; do not re-run checks the author ran on this exact subject or that CI will run. Re-execute only a risk-critical claim that has no receipt.
- A necessary finding never becomes an optional caveat or non-goal.
Decide in this order:
- The subject changed during judgment, changed-path coverage is incomplete, or author and validator identity or freshness is missing, colliding or unattested: NOT_PROVEN.
- A criterion is proven failed, or a change is proven out of scope: FAIL, even when other criteria are unverified.
- Any in-scope criterion lacks evidence: NOT_PROVEN.
- Every criterion is verified with evidence, checked scope is nonempty and
not_checkedis empty: PASS.
Establish intent first
An explicit request for Validate, an acceptance verdict or independent proof
that original acceptance is met selects this skill, even when phrased as
"review this"; a request for a look or opinion goes to Review, and when the
purpose is open, ask once and issue no verdict meanwhile, since missing intent
is not a NOT_PROVEN verdict
(advice or acceptance).
When a fresh judgment is worth it
Spend validation where a mistake is costly. For an ordinary change the author's checks and CI are the gate, and no fresh judgment is owed. Use Validate when:
- the caller asks for an acceptance verdict or independent proof;
- 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
- no deterministic check covers the behavior that changed.
Judge once. Report NOT_PROVEN with its gaps and stop; do not request or wait for another round. After the author repairs findings, the affected checks confirm the repair; a second judgment happens only when the caller asks for one. Keep the judgment's cost a fraction of the cost of the work: when it approaches that cost, stop and return what is unchecked.
Subject
The subject is a nonempty implementation candidate, held unchanged after required checks and known repairs; plans, audits and reviews are subjects only when the caller requested document review. Supplied failed-acceptance evidence proves a failure on that subject: FAIL, unless a step 1 gap makes it NOT_PROVEN; do not review a moving repair. Bind its identity at the start and again at the end of judgment:
- With AgentOps installed:
ao provenance manifest --root "$REPO_ROOT" --include "$CHANGED_PATH", one--includeper changed path (helper commands). A deleted path is bound only with--base-manifest <base-manifest>; without a base manifest, use the Git fallback below. - In any Git repository: the commit SHA (
git rev-parse HEAD) and the changed paths (git diff --name-only <base>...HEAD); for uncommitted work, thegit status --porcelainlisting and ashasum -a 256of each changed file. - A subject supplied only in the conversation, such as a pasted diff or a described change, is exactly what was supplied, so its coverage is complete as supplied; anything it does not show is unverified.
Identity and freshness
Author and validator identities must be explicit and distinct, and freshness attested by the runtime or the caller, naming the attester; an attestation is a declared trust fact, not cryptographic isolation. In ordinary use these count:
- Author: the identity the caller gives for whoever produced the candidate: a person, a session or agent ID, or the commit author.
- Validator: this context's runtime ID, such as a subagent or session ID; otherwise the dispatcher's handle for it, such as the agent ID returned at launch, or "this conversation" when the caller opened it for the judgment.
- Freshness: a statement, naming who makes it, that this context did not produce the candidate and was given intent, subject and evidence rather than the author's working history. When the caller opened this conversation for the judgment and supplied the candidate, the caller is the attester.
A role name, a persona switch inside the author's conversation, or the validator vouching for itself does not count. Never invent an identity. An identity gap makes the result NOT_PROVEN; keep every finding in the report.
Reviewers
Default to one fresh reviewer in the author's model family (Codex/OpenAI for Codex/OpenAI, Claude/Anthropic for Claude/Anthropic), on the runtime's configured capable model unless pinned. If this context produced the candidate, it cannot be that reviewer: dispatch one and return its result, or return NOT_PROVEN with the identity gap when none can run. Give the reviewer intent, scope, exact subject, the evidence each criterion needs and one question written before it starts, never full author history, the author's confidence, a desired verdict or peer conclusions.
Cross-model review is opt-in: --cross-model [model] is a skill prompt
selection, not an AO flag, adding a fresh other-family reviewer through
model-dispatch. A required leg
that cannot run is a diversity_unsatisfied finding and makes the combined
result NOT_PROVEN, even if another leg passed; unavailable optional diversity
is disclosed without erasing findings. Delivered FAILs and dissent stand;
neither voting nor model preference makes a split PASS, and agreement is not
proof of truth. Respect real caller and native time bounds without renewing
them; a timeout is missing judgment, not FAIL.
Judgment
- Bind the subject. Verify continuity with the exact caller-owned intent, cited evidence and complete changed-path coverage; missing integrity is NOT_PROVEN.
- Revisit the original accepted behavior examples, including those in the conversation or bead, and check each observable result and its domain meaning on the exact candidate. A new test or renamed concept cannot replace an unfulfilled scenario. Inspect the actual diff against every criterion; publication or provenance claims in docs need verifiable evidence too. Risk sets depth: acceptance, permissions, tests and gates, stopping, disclosure, hooks and executable controls warrant deeper reading, including prose policy. Unknown risk merits examination, not extra reviewers.
- Classify commands before running any. Regeneration, synchronization,
formatting and
--forcemutate the subject until proven otherwise; run them only on a disposable copy, such as a fresh worktree or clone at the committed SHA, never the judged checkout. - Bind the subject again; a mismatch is NOT_PROVEN.
- Return one result in the shape below, promptly, and stop.
Report
Verdict: PASS | FAIL | NOT_PROVEN
Subject: <manifest digest, or commit SHA and changed paths>; unchanged start to end: yes | no
Criteria:
1. <criterion> - verified | failed | not verified - <evidence: file:line, receipt, observed output>
Findings: <class> - <what and where> - <consequence> (or "none")
Notes (optional, do not change the verdict): <...>
Checked: <what was inspected, and how>
Not checked: <in-scope acceptance not verified> (empty only for PASS)
Identity: author <id>; validator <id>; freshness attested by <runtime | caller>: <attester>A finding fails an acceptance criterion or would mislead a user, break install
or the CLI, or remove protection for the product; anything else is an optional
note the author may ignore. Give each new finding a short stable class,
reused on recurrence, and say whether it is pre-existing, introduced or unknown
from before/after evidence; counts and timestamps alone do not establish cause.
Keep prior findings visible. not_checked holds in-scope acceptance that was
not verified, including delivery inside acceptance whose evidence does not yet
exist; never remove a criterion or hide a limit to reach PASS. Other limits
stay in criterion reasoning, declared non-goals or residual-risk prose
(homes).
Validate is the sole semantic author of verdict.v2.
Only when the caller requests machine-readable evidence or a declared consumer
requires it, persist through ao provenance store-verdict
(draft shape); Go verifies
structure and storage, not truth. Otherwise return the result through the
caller's channel, without hidden machine artifacts. Validate owns no repair,
retry, delivery or tracker transition: findings go back to the author for
direct repair, and a causal stall gets at most one bounded fresh helper
(RPI).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

