Explain GRACE 4 methodology, .grace artifacts, semantic anchors, change lifecycle, verification, and migration boundaries.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add osovv/grace-marketplace --skill grace-explainer --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Grace Explainer?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/osovv-grace-explainer-grace-marketplace)More formats (shields.io, HTML) on the badges page.
---
name: grace-explainer
description: Explain GRACE 4 methodology, .grace artifacts, semantic anchors, change lifecycle, verification, and migration boundaries.
---
<skill>
<core_model>
GRACE 4 uses `.grace` as the durable project model:
- `.grace/context` stores requirements, technology, principles, deployment, and UX constraints.
- `.grace/graph` stores graph indexes and routed graph documents with `GD-*`, `M-*`, and `DF-*` tags.
- `.grace/verification` stores verification indexes and routed `V-M-*` entries.
- `.grace/changes` stores active and archived `C-*` change bundles with `GraceChangeSpec`, optional non-normative design context, and `GraceChangePlan`.
</core_model>
<workflow>
1. `grace-init` creates the `.grace` skeleton.
2. `grace-spec` creates an active change spec and waits for approval.
3. `grace-plan` creates assertions, scopes, and `T-*` implementation tasks.
4. `grace-execute` runs sequential or parallel-safe mode from the approved plan.
5. `grace lint` and `grace status` provide validation and health evidence.
6. Existing GRACE 3 projects use `grace-migrate`; the CLI validates the result but does not convert legacy docs directly.
</workflow>
</skill>
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!