mcpField
G
grace-verification

grace-verification

github.com/osovvTesting & quality25639 installsUpdated 5w ago
Repository

About grace-verification

grace-verification helps strengthen deterministic verification for modules and changes in GRACE projects. It guides users through verification records, commands, evidence, and updates routed through an active change plan.

Key features

  1. 01Reviews graph anchors and verification entries
  2. 02Identifies scenarios, commands, and evidence
  3. 03Checks command determinism and working directories
  4. 04Routes verification changes through an active plan
  5. 05Records fresh command evidence

Use cases

  1. 01Adding deterministic module coverage
  2. 02Defining verification commands and expected evidence
  3. 03Diagnosing flaky verification gates

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/osovv/grace-marketplace --skill grace-verification

After installing, type/grace-verificationin Claude Code to confirm it loaded.

Bundled filesagents/openai.yaml

Details

From the project README
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. 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. When verification commands run from a workspace or package directory, add one direct `relative/project/path` child to the owning `V-M-*` entry. Keep declared `...` paths project-root-relative; the CLI uses `Cwd` only to compare them with cwd-relative command arguments. Use `` when module health must prove a runtime log or trace emission from linked implementation code. Use `` 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. 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. 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.

Comments

Markdown supported