GRACE Marketplace and CLI skill
Fifteen GRACE skills and a CLI for contract-driven development: spec, plan, execute and verify through .grace artifacts
- 268 ★ on the repository
- Last commit
- MIT
Broad access
Why this level
- Skills create and change `.grace` files and `AGENTS.md` in the project, and migration may propose cleaning up old documents
- The CLI with `--run-commands` executes `MustPassCommand` entries declared in project artifacts
- Parallel-safe execution starts several agents and each writes to the repository
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/grace-marketplace-and-cliDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- Skills create and change `.grace` files and `AGENTS.md` in the project, and migration may propose cleaning up old documents
- The CLI with `--run-commands` executes `MustPassCommand` entries declared in project artifacts
- Parallel-safe execution starts several agents and each writes to the repository
This is third-party code. Review the repository files before installing.
What it does
GRACE (Graph-RAG Anchored Code Engineering) is a methodology in which an agent writes code from contracts: modules carry semantic markup, the project has a knowledge graph and every change has verification. The repository ships 15 skills in `skills/grace/`, a Claude Code marketplace mirror and an optional `grace` CLI. The source of truth is the `.grace` folder: project context (requirements, technology, principles, deployment, UX) in XML, a module graph, verification records and `C-*` change bundles in active and archived states. The workflow follows the skills. `grace-init` creates the `.grace` skeleton and `AGENTS.md`, `grace-spec` writes an approved change spec, `grace-plan` builds assertions, scopes and verification from it, and `grace-execute` runs the plan sequentially or in parallel-safe mode. For maintenance there are `grace-refactor`, `grace-fix`, `grace-refresh` and `grace-status`, for questions `grace-ask`, and for checks `grace-verification` and `grace-reviewer`. `grace-migrate` moves projects from the old version. The CLI `grace lint` checks markup and contracts, `grace status` shows project health and drift against git, and `grace module`, `grace verification` and `grace file show` search and display modules and records. With the `--run-commands` flag the linter executes declared `MustPassCommand` entries, meaning tests, type checks and builds.
Who it is for. For developers who run a large codebase with Claude Code or Codex and want module contracts, a graph and verification fixed in the project.
Good fit when
- An agent keeps drifting from the architecture and you need a document that says what each module must do
- Before a big change you need a spec, a plan and acceptance criteria you approve before any code is written
- A refactor (rename, move, merge of modules) must proceed without drift between code and artifacts
- You want to catch drift between code and description with `grace status` and `grace lint`
- You need to find quickly in the graph where a module lives and which checks are linked to it
Not a fit when
- A small script or a throwaway prototype: the `.grace` skeleton, contracts and verification add more work than value
- The project is in Go, Rust, Java, C++, C# or shell and you need exact export checks: for those only the markup structure is validated and export parity is not analyzed
- You have no Bun: the CLI installs with `bun add -g @osovv/grace-cli`, and without it only the skills remain
- The project uses XML-comment dialects such as `.xaml` or `.csproj`: markers are recognized only behind the `//`, `#`, `--`, `;` and `*` prefixes
Example request
Run $grace-init for a TypeScript project, then use $grace-spec to write the change "add card payment" and show the spec for approvalLimitations
The repository is for distribution, and the author stresses it is not an end-user application. Install the skills first; the CLI is optional but recommended and needs Bun. The skills call the installed `grace` binary directly, with no `bunx` or `npx`.
Semantic analysis for TypeScript and JavaScript is bundled. Python and Dart need their runtimes on PATH, and without a runtime the check fails with `analysis.runtime-missing`. For languages with no adapter, including Go, Rust, Java, C/C++, C# and shell, only structure is checked: markup, contract completeness and the `MODULE_MAP` shape, and export parity is not analyzed. GRACE 3 projects fail validation and move over with the `grace-migrate` skill. Cleanup after migration needs a separate explicit confirmation. The license is MIT.
How to disable. Remove the plugin with `/plugin uninstall grace@grace-marketplace` or the `grace-*` folders from the agent skills directory, and the CLI with `bun remove -g @osovv/grace-cli`. The `.grace` folder and `AGENTS.md` live in your project, so delete them by hand if you no longer need the methodology.
FAQ
How do I install GRACE in Claude Code?
Run `/plugin marketplace add osovv/grace-marketplace`, then `/plugin install grace@grace-marketplace`. Other routes exist: `opkg install gh@osovv/grace-marketplace` through OpenPackage or copying the `grace-*` folders from `skills/grace/` into the agent skills directory.
Where do I start with a new project?
Call `$grace-init` to create `.grace` and then fill the `.grace/context` files. For the first change use `$grace-spec`, `$grace-plan` and `$grace-execute`. Before writing run `grace lint --path <root> --assertions current`, and before archiving check `--assertions final`.
Do I need the CLI if I have the skills?
The skills work alone, and the CLI adds fast checks and search over artifacts. It needs Bun: `bun add -g @osovv/grace-cli`, then `grace --version` and `grace lint --path <project>`.
What about a GRACE 3 project?
Run `$grace-migrate` and review the migration report before artifacts are written to `.grace`. The CLI validates the result but does not convert the old documents. Cleanup after migration has separate conditions: a fresh status with no errors, a git review and explicit confirmation.
Which programming languages are supported?
TypeScript and JavaScript analysis is bundled. Python and Dart are checked when their runtimes are on PATH. For other languages, including Go, Rust and Java, the markup structure is checked without export parity.
Discussion
No questions or reviews yet.
Related
Skills73 skills for a delivery pipeline: plan, code, review and QA, ending in a ready, labeled PR in your own repository.
CLI installs Graftcode Gateway and coding-agent rules so methods of your own service can be exposed as MCP tools
Plugin marketplace for Claude Code and AdaL CLI: skills for landing page cloning, code graphs, PostHog and 23 CLI guides.
Tasks, docs, specs and decisions live as markdown files in your repository, and the agent reads them through the CLI and MCP
The author's personal set: shared agent rules and dozens of skills for GitHub, the browser, macOS, messaging and releases, plus a sync script
14 skills that find the gaps in a task before the code: interviews, plans, assumption tests and proof that a bug fix works
README in short
The document describes the GRACE 4 model as a set of `.grace` artifacts, lists 15 skills and CLI commands, output modes and `.grace-lint.json` configuration. It covers the analysis cache, the built-in list of ignored directories and compatibility with packaging for Claude Code, OpenPackage and generic skill directories.
README badge
Original SKILL.md
--- name: grace-init description: Bootstrap a Full GRACE 4 project by creating the canonical .grace context, graph, verification, and changes skeleton. --- <skill> <task> Create the canonical GRACE 4 project layout from this skill's `assets/` templates: - `AGENTS.md` - `.grace/context/requirements.xml` - `.grace/context/technology.xml` - `.grace/context/principles.xml` - `.grace/context/deployment.xml` - `.grace/context/ux-guidelines.xml` - `.grace/graph/index.xml` - `.grace/graph/main.xml` - `.grace/verification/index.xml` - `.grace/verification/main.xml` - `.grace/changes/active/` - `.grace/changes/archive/` Every XML artifact uses `graceVersion="4.0"`. Semantic anchors are XML tags, never attributes. Do not create dummy `C-*` change bundles. Do not overwrite existing `.grace` artifacts without explicit confirmation. </task> <template_sources> | Template source | Target in project | |---|---| | `assets/AGENTS.md.template` | `AGENTS.md` | | `assets/.grace/context/requirements.xml.template` | `.grace/context/requirements.xml` | | `assets/.grace/context/technology.xml.template` | `.grace/context/technology.xml` | | `assets/.grace/context/principles.xml.template` | `.grace/context/principles.xml` | | `assets/.grace/context/deployment.xml.template` | `.grace/context/deployment.xml` | | `assets/.grace/context/ux-guidelines.xml.template` | `.grace/context/ux-guidelines.xml` | | `assets/.grace/graph/index.xml.template` | `.grace/graph/index.xml` | | `assets/.grace/graph/main.xml.template` | `.grace/graph/main.xml` | | `assets/.grace/verification/index.xml.template` | `.grace/verification/index.xml` | | `assets/.grace/verification/main.xml.template` | `.grace/verification/main.xml` | </template_sources> <steps> 1. Gather project name, annotation, keywords, language/runtime/framework, testing stack, observability constraints, deployment applicability, UX applicability, and any known initial modules. 2. If `.grace` or `AGENTS.md` already exists, stop and ask whether to keep, merge, or overwrite each existing artifact. Never overwrite silently. 3. Create `.grace/context`, `.grace/graph`, `.grace/verification`, `.grace/changes/active`, and `.grace/changes/archive`. 4. Read each `.template` file, replace `$PLACEHOLDER` values with gathered project information, and write the target file.