/grace-verification
Design and maintain GRACE 4 verification entries, commands, scenarios, markers, and assertion evidence under .grace/verification.
$ npx -y skills add osovv/grace-marketplace --skill grace-verification --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/grace-verification
Context preview
The summary Claude sees to decide when to auto-load this skill.
Design and maintain GRACE 4 verification entries, commands, scenarios, markers, and assertion evidence under .grace/verification.
SKILL.md
grace-verification.SKILL.mdname: grace-verification
description: 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> </skill>
Read more
name: grace-verification description: 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> </skill>
GRACE means Graph-RAG Anchored Code Engineering: a contract-first AI engineering methodology built around semantic markup, .grace XML artifacts, knowledge-graph navigation, assertions, scopes, and log-driven verification.
Repo: osovv/grace-marketplace
Other skills on grace-marketplace.
- /grace-ask
Answer questions about a GRACE 4 project by navigating .grace current-state artifacts and file-local semantic markup.
Open skill - /grace-cli
Operate the GRACE 4 CLI for .grace linting, status, module navigation, verification navigation, and file-local semantic markup.
Open skill - /grace-execute
Execute an approved GRACE 4 GraceChangePlan in sequential or parallel-safe mode with recovery-aware preflight and centralized durable apply.
Open skill - /grace-explainer
Explain GRACE 4 methodology, .grace artifacts, semantic anchors, change lifecycle, verification, and migration boundaries.
Open skill - /grace-fix
Debug and fix issues in a GRACE 4 project using .grace semantic navigation, assertions, and verification evidence.
Open skill - /grace-init
Bootstrap a Full GRACE 4 project by creating the canonical .grace context, graph, verification, and changes skeleton.
Open skill

