spae-verify
Skill2 starsChanged 15 days agoMITView on GitHub
- STATE.json reads phase: verify: judge the implementation against SPEC.md. - Judge the implemented workstream against every SPEC.md requirement as the final arbiter; record every hard block in VERIFY.md. - On Pass, complete the workstream (phase: done); on Revision required, route it to phase: spec. Read only what the verdict requires: - .spae/current/STATE.json; references/STATE.md holds field reference, directives, and snapshots. - .spae/current/SPEC.md. - .spae/current/PLAN.md: task IDs and Scope fields. - Repository source, tests, docs, configuration, and logs the workstream changed,…
In this repository21 other files it gives its agents.
- auto-commitSkill
- cleanSkill
- code-reviewSkill
- coverageSkill
- documentSkill
- purifySkill
- puritySkill
- refactorSkill
- spae-buildSkill
- spae-checkSkill
- spae-fixSkill
- spae-inspectSkill
- spae-orchestrateSkill
- spae-planSkill
- spae-prepareSkill
- spae-spawnSkill
- spae-specSkill
- structureSkill
- testSkill
- tipSkill
- troubleshootSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 4 are distinctive, and 10 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Read only what the verdict requires:
- Very specific: line 34
Never read .spae/current/VERIFY.md.
- Very specific: line 46
Read SPEC.md in full; capture every R-NNN into a coverage checklist.
- Very specific: line 48
Read PLAN.md task Scope fields to bound workstream changes.
- Very specific: line 56
Run the project checks and every SPEC.md Testing strategy command.
- Very specific: line 92
Write STATE.json per the references/STATE.md exit snapshot matching the verdict.
- Very specific: line 116
Write scope: write only .spae/current/VERIFY.md and .spae/current/STATE.json.
- Very specific: line 124
Version control and release: never execute git mutations (staging, commits, branches, tags, pushes) or release operations.
- Distinctive: line 127
Autonomy: never ask users for input or clarification mid-execution.
- Very specific: line 131
State schema: never introduce STATE.json fields outside references/STATE.md.
- Very specific: line 148
Every R-NNN judged against cited automated evidence.
- Very specific: line 149
Every finding matching a Hard block or Soft finding item—workstream-added bloat included—carries that tag.
- Distinctive: line 167
Keep prose terse while ensuring clarity.
- Distinctive: line 170
Use lists and sub-lists for long sentences and dense paragraphs.
≈ “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
Verify (SPAE)
When to use
STATE.jsonreadsphase: verify: judge the implementation againstSPEC.md.
Goal
- Judge the implemented
workstreamagainst everySPEC.mdrequirement as the final arbiter; record every hard block inVERIFY.md. - On
Pass, complete theworkstream(phase: done); onRevision required, route it tophase: spec.
Input
Read only what the verdict requires:
.spae/current/STATE.json;references/STATE.mdholds field reference, directives, and snapshots..spae/current/SPEC.md..spae/current/PLAN.md: task IDs andScopefields.- Repository source, tests, docs, configuration, and logs the
workstreamchanged, for analysis.
Never read .spae/current/VERIFY.md; SPEC.md holds every requirement.
Workflow
- GATE—Make no writes:
- Parse
.spae/current/STATE.json; self-heal missing metadata:version("1.0"),workstream(target directory name),status("active");PERSISTwrites the healed fields. - Halt on any Halt conditions entry.
- Parse
- ORIENT—State goal in one sentence:
SPEC.mdandPLAN.mdstay unmodified; directly modify no source or tests; write nothing beforePERSIST.- Read
SPEC.mdin full; capture everyR-NNNinto a coverage checklist. - Read
PLAN.mdtaskScopefields to boundworkstreamchanges.
- PLAN—Declare the evidence map:
- Read
references/verification-guide.mdandreferences/shell-command-guide.md. - Map each
R-NNNto the evidence that proves it: aTesting strategycommand, a project check, or source. - Halt on any Halt conditions entry.
- Read
- ACT—Gather evidence and label findings:
- Run the project checks and every
SPEC.mdTesting strategycommand. - Judge each
R-NNNagainst command output,workstreamchanges, and source. - Label each finding with exactly one tag:
- Hard block—drives
Revision required; cite reproducible evidence:- Missing or incorrect required behavior, a contract break, or a regression.
- A project-check failure the
workstreamcauses. - A spec defect: an
R-NNNno available automated evidence proves, such as one needing human presence or tooling the repository never declares.
- Soft finding—never a verdict input:
- Absent test coverage of explicit required behavior.
- An unsafe optimization.
- Speculative abstraction, defensive bloat, or complexity no
R-NNNgrounds, cited fromworkstreamchanges—never a hypothetical risk or stylistic preference.
- Observation—never a verdict input: thin edge-case coverage,
an ambiguous requirement, a minor deviation outside
SPEC.mdscope, an unrequested guardrail, a theoretical risk, anOut of scoperesidual risk, or a check failure theworkstreamdoesn't cause.
- Hard block—drives
- Head each finding with the
R-NNNit concerns, elsenone. - On any
Hard block, draftVERIFY.mdperreferences/VERIFY.md. - Apply Directives and Constraints.
- Run the project checks and every
- VERIFY—Loop over Verification criteria for the verdict and
the
VERIFY.mddraft:- For each failure: return to
ACT, complete the evaluation, then re-enterVERIFY. - Exit only when every criterion passes.
- Halt only on a Halt conditions entry.
- For each failure: return to
- PERSIST—Write in order:
- On a
Revision requiredverdict, write.spae/current/VERIFY.md, replacing any prior copy. - Write
STATE.jsonper thereferences/STATE.mdexit snapshot matching the verdict. - Re-read
STATE.json; on a mismatch against Verification state criteria, rewrite and re-read beforeREPORT. - On a
Passverdict, delete.spae/current/VERIFY.mdwhen present, then remove the.spae/currentsymlink.
- On a
- REPORT—Emit result following result directives and using result
template:
Resultby re-readphase:done→Pass,spec→Revision required; a halt→Failed.- List each
Hard block, then eachSoft finding, then eachObservationunderFindings.
Directives
- Optimize for agent, token, and context efficiency.
- Refine and optimize
VERIFY.mdfor agent consumption: agents read it for varied purposes, with no memory of this run; keep it self-contained, explicit, and token-dense; make eachHard blockactionable without repeating the investigation. - Consult
references/prose-protocol.mdbefore draftingVERIFY.md.
Constraints
- Write scope: write only
.spae/current/VERIFY.mdand.spae/current/STATE.json; onPass, deleteVERIFY.mdand the.spae/currentsymlink; forbid all other writes. Byproducts of a command run for evidence, such as a formatter's rewrites, never count as this phase's writes; never run a command for its write effect outside this scope. Read source code only for analysis. - Phase boundary: judge the whole
workstream; complete it or hand off work to/spec. - Version control and release: never execute git mutations (staging,
commits, branches, tags, pushes) or release operations. Never stage or
commit
.spae/. - Autonomy: never ask users for input or clarification mid-execution; halts and failures stop autonomously. Never perform or request human execution, an attended or interactive terminal, or human presence.
- State schema: never introduce
STATE.jsonfields outsidereferences/STATE.md. - Halt conditions: halt without writing; report
Failedwith a diagnostic underFindings:.spae/currentmissing or dangling.STATE.jsonmissing or holds unparseable JSON syntax.STATE.jsonphaseother thanverify.SPEC.mdorPLAN.mdmissing.- A
PLAN.mdtask absent fromtasksor reading other than"done". - Evidence can't run for a cause outside the repository: a broken external dependency or an environment failure.
- Scope control: judge only
SPEC.mdrequirements andworkstream-caused regressions; add no requirement or verdict input beyond them.
Verification
- Every
R-NNNjudged against cited automated evidence. - Every finding matching a
Hard blockorSoft findingitem—workstream-added bloat included—carries that tag; every other finding carriesObservation. - Verdict reads
Passonly with zeroHard blockfindings; anyHard blockyieldsRevision required. - On
Revision required, theVERIFY.mddraft matchesreferences/VERIFY.md: every finding headed by itsR-NNN, elsenone; everyHard blockwithFile,Expected,Actual, and reproducibleEvidence. - No
VERIFY.mdfinding requests human execution, an attended or interactive terminal, or human presence. STATE.jsonmatches thereferences/STATE.mdexit snapshot for the verdict.- This phase wrote no file outside Write scope.
Result directives
- Minimum words. Maximum signal.
- Keep prose terse while ensuring clarity.
- Optimize prose for agent, token, and context efficiency.
- Split actions, findings, and summaries into terse bullet points.
- Use lists and sub-lists for long sentences and dense paragraphs.
- Emit result template as live markdown—never in a code fence.
- Output nothing outside template.
- Source every
SPAE Statusvalue from confirmed re-read, never from working memory of intent.
Result template
<!-- prettier-ignore-start -->### Execution Summary
- **Actions**:
- [Terse list of actions taken]
- **Files**:
- [Terse list of affected files]
- **Findings**:
- [Terse list of notable findings]
- **Summary**:
- [Terse list of summary of changes]
> **`SPAE` Status** • `[workstream-name]`
> **Result**: [Pass | Revision required | Failed]
> **Next Phase**: `/spec` _(if revision required)_<!-- prettier-ignore-end -->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.

