---
name: Grace Verification
slug: grace-verification
category: Quality
description: Grace Verification designs and maintains deterministic verification entries, commands, scenarios, markers, and assertion evidence under .grace/verification. Use it when updating module coverage, gate tasks, or recorded evidence for GRACE 4.
github: "https://github.com/osovv/grace-marketplace/tree/main/skills/grace/grace-verification"
language: TypeScript
stars: 239
forks: 54
install: "npx degit https://github.com/osovv/grace-marketplace/tree/main/skills/grace/grace-verification ~/.claude/skills/grace-verification"
installs_to: ~/.claude/skills/grace-verification
source_path: skills/grace/grace-verification/SKILL.md
collection_size: 15
category_size: 1478
collection_url: "https://dirskills.com/collections/osovv/grace-marketplace"
added: 2026-09-03T06:03:54.408Z
last_synced: 2026-09-03T06:03:54.408Z
canonical_url: "https://dirskills.com/skills/grace-verification"
---

# Grace Verification

Grace Verification designs and maintains deterministic verification entries, commands, scenarios, markers, and assertion evidence under .grace/verification. Use it when updating module coverage, gate tasks, or recorded evidence for GRACE 4.

**Install:**

```bash
npx degit https://github.com/osovv/grace-marketplace/tree/main/skills/grace/grace-verification ~/.claude/skills/grace-verification
```

## README

<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>