Grace Verification
Design and maintain GRACE 4 verification entries, commands, scenarios, markers, and assertion evidence under .grace/verification.
osovv Grace Verification by osovv · 7000b94
npx skillmds@latest add osovv/grace-verification File contents
---name: grace-verificationdescription: Design and maintain GRACE 4 verification entries, commands, scenarios, markers, and assertion evidence under .grace/verification.---<skill><purpose>Strengthen deterministic verification for modules and changes. Verification state lives in `.grace/verification/index.xml` and routed verification documents. Each durable module should have deterministic `V-M-*` coverage unless an explicit exception is planned.</purpose><workflow>1. Read relevant `.grace/graph` anchors and current `V-M-*` entries.2. Identify scenarios, commands, test files, required log markers, and trace assertions.3. Ensure commands are deterministic and runnable from the project root or documented cwd.4. Update or propose `.grace/verification` changes through the active change plan.5. Run the commands and record fresh evidence in the response.</workflow><cwd_contract>When verification commands run from a workspace or package directory, add one direct `<Cwd>relative/project/path</Cwd>` child to the owning `V-M-*` entry. Keep declared `<TestFiles><File>...</File></TestFiles>` paths project-root-relative; the CLI uses `Cwd` only to compare them with cwd-relative command arguments.</cwd_contract><evidence_contract>Use `<Marker>` when module health must prove a runtime log or trace emission from linked implementation code. Use `<TraceAssertion>` for deterministic test or trace evidence that does not require runtime logging, such as pure functions, type-level modules, and core libraries. A non-empty marker or trace assertion satisfies the module-health evidence requirement; only authored markers require matching runtime emission and `BLOCK_*` evidence.</evidence_contract><gate_task_contract>Reference named project tasks in `MustPassCommand` and `ExpectedCommand` (for example `bun run gate:e2e`) instead of inline `;`-chains. Decompose full gates into granular named tasks (`gate:test`, `gate:typecheck`, `gate:build`, `gate:e2e`) so a selective re-run is just running that task, timeouts map to one coherent unit, and `grace lint --run-commands` reports each gate step with its own timing and log.</gate_task_contract><flake_contract>A flaky gate is a defect of the verification entry, not a reason to re-run blindly. Diagnose from the per-attempt logs under `~/.cache/grace/run-commands/`. Fix it by decomposing the gate task, adding runner-level retries inside the task itself (for example playwright `--retries`), or quarantining the unstable scenario. Silent manual re-runs are not a fix: grace records every run honestly, and nondeterministic verification undermines assertion evidence.</flake_contract></skill>
osovv/grace-marketplace/tree/main/skills/grace/grace-verification commit 7000b94487
Frequently asked questions
Run npx skillmds@latest add osovv/grace-verification in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Design and maintain GRACE 4 verification entries, commands, scenarios, markers, and assertion evidence under .grace/verification. It is listed under Coding & Dev Tools on SkillMD.
This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
osovv (@osovv) published this skill. Their other Agent Skills are listed on their SkillMD profile.