plan-verify
Skill0 starsChanged 35 days agoMITView on GitHub
Turn an approved implementation plan into executable verification scripts and the order to run them. Use when a PIC driver starts the verification phase, or when a plan's checks need to become runnable.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- PiloTracer/pilo.ai.logicbisontheir own version, first seen Oct 11, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- PiloTracer/pilo.ai.logicbison★ 0same name
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 repository9 other files it gives its agents.
- AGENTS.mdAGENTS.md
- code-qualitySkill
- golang-codeSkill
- go-service-scaffoldSkill
- implementation-planSkill
- next-stepsSkill
- orchestrateSkill
- plan-driveSkill
- trivy-scannerSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use this at the start of Verification, before the first check runs.
- Distinctive: line 14
Every done criterion in the plan maps to at least one check.
- Very specific: line 30
Write to the path the plan names.
- Distinctive: line 37
No script proves nothing outside the plan.
- Very specific: line 41
Run run-all.sh once against the current state.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Plan verify
Input: the approved implementation plan and the current code. Output: executable verification scripts and the order to run them.
Use this at the start of Verification, before the first check runs.
1. Extract the checks
Every done criterion in the plan maps to at least one check. List each with its expected result, inputs, starting state and evidence location. A criterion without a check is a blocker: return to Planning.
2. Interview the repo
Answer from the code by reading it and running read-only commands. Never ask the leader or a peer to run, produce or confirm evidence. Find:
- What starts the system: command, port, environment, seed data, auth.
- What proves each check: the exact command or observation.
- What is the starting state: clean checkout, built image, running stack.
- What is safe to run twice: destructive steps, data, credentials.
- How evidence is captured: exit code, output, log, screenshot, CI run URL.
Record every answer in the verification README. What you cannot observe is a risk, not a fact.
3. Write the scripts
Write to the path the plan names. If it names none, use verification/<task-slug>/ in the workspace and record the path in the plan.
- One script per check, or per group that shares a setup.
NN-<check>.shin run order, plusrun-all.sh.- Each script carries: exact command, expected output, pass or fail bar, evidence path, cleanup.
- Deterministic, non-destructive, safe to re-run. A secret comes from the environment; never hardcode it.
- A check that cannot be scripted, such as a CI pipeline or post-deploy logs, gets a script that runs the command and records the result, or a named manual step with the exact command and observation.
- No script proves nothing outside the plan. No orphan script.
4. Prove the scripts
Run run-all.sh once against the current state. Fix what fails. A script never run is a draft, not a deliverable. If the state cannot run yet because the code is not written, mark the check PENDING and run it during Verification.
You run every script yourself, including browser and end-to-end flows, with your own session. No check is delegated to the leader or to a peer.
5. Output
README.md with: check, script, what it proves, run order, expected result, evidence path. Update the plan with the script location and the run order.
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.