GRACE Marketplace and CLI

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.

This repository ships the GRACE skills plus the optional grace CLI. It is a packaging and distribution repository, not an end-user application.

Current packaged version: 4.0.5

What This Repository Ships

• Canonical GRACE skills in skills/grace/*
• Packaged Claude marketplace mirror in plugins/grace/skills/grace/*
• Marketplace metadata in .claude-plugin/marketplace.json
• Packaged plugin manifest in plugins/grace/.claude-plugin/plugin.json
• OpenPackage metadata in openpackage.yml
• Optional Bun-powered CLI package @osovv/grace-cli

GRACE 4 Model

GRACE 4 uses .grace as the durable project model:

GRACE 4 does not dual-validate legacy GRACE 3 project docs as current state. Existing GRACE 3 projects use $grace-migrate; the CLI validates the generated .grace result but does not convert legacy docs itself.

Verification commands run from the project root by default. A V-M-* entry may declare one contained project-relative <Cwd>packages/example</Cwd> while keeping <TestFiles><File>...</File></TestFiles> paths project-root-relative. Absolute paths, .. escapes, and symlink escapes fail closed.

TypeScript/JavaScript semantic analysis is bundled and compiler-backed. Governed Python and Dart files require their respective runtimes on PATH; Python export analysis is exact when a static __all__ is present (including Unicode identifiers) and otherwise emits heuristic confidence. A missing runtime fails closed with actionable analysis.runtime-missing; an installed adapter that fails emits analysis.adapter-failed. Neither failure state is presented as exact MODULE_MAP parity.

Install

Install skills first. The CLI is optional but recommended once skills are installed.

OpenPackage

opkg install gh@osovv/grace-marketplace
opkg install gh@osovv/grace-marketplace -g
opkg install gh@osovv/grace-marketplace --platforms claude-code

Claude Code Marketplace

/plugin marketplace add osovv/grace-marketplace
/plugin install grace@grace-marketplace

Agent Skills-Compatible Install

git clone https://github.com/osovv/grace-marketplace
cp -r grace-marketplace/skills/grace/grace-* /path/to/your/agent/skills/

CLI

Requires bun on PATH. GRACE skills invoke the installed stable grace binary directly; they do not default to bunx, npx, or a prerelease dist-tag.

# Install the current stable release from npm `latest`
bun add -g @osovv/grace-cli
grace --version
grace lint --path /path/to/grace4-project

GRACE 4 Quick Start

For a new GRACE 4 project:

1. Run $grace-init to create .grace.
2. Fill .grace/context artifacts with your agent.
3. Run $grace-spec for a change.
4. Run $grace-plan after spec approval.
5. Before observed writes begin, run the active-baseline preflight: grace lint --path /path/to/project --assertions current.
6. Run grace lint --path /path/to/project --change C-ID --assertions baseline before execution; add --run-commands when the baseline declares MustPassCommand.
7. Run grace status --path /path/to/project --json.
8. Run $grace-execute and choose sequential or parallel-safe mode. Parallel-safe mode additionally requires grace lint --path /path/to/project --parallel-preflight.
9. Before apply/archive, run grace lint --path /path/to/project --change C-ID --assertions final; add --run-commands when the target declares MustPassCommand.

Existing GRACE 3 projects should run $grace-migrate and review the migration report before writing .grace artifacts.

Migration cleanup is separately gated: successful current lint, fresh status proving GRACE 4 with no integrity errors, git/worktree inspection, exact cleanup paths, and explicit cleanup confirmation are mandatory. Dirty or non-git cleanup requires an additional acknowledgement naming that risk; any cleanup failure stops without automatic destructive retry.

Skills Overview

CLI Overview

MustPassCommand entries are leaf project evidence such as tests, typecheck, build, format, or package checks. Do not nest grace lint, grace status, or another GRACE lifecycle command inside plan assertions; selected target/final lint is the external orchestration gate.

Output modes:

• grace lint: text, json
• grace status: text, json
• grace module find: table, json
• grace module show: text, json
• grace verification find: table, json
• grace verification show: text, json
• grace file show: text, json

Lint, status, and projection-backed navigation fail closed: invalid options, invalid grammar, malformed active assertions/scopes, duplicate ownership, missing routed files, or ambiguous targets produce structured results or a nonzero error envelope. JSON command failures emit one stable { "schemaVersion": "1.0.0", "ok": false, "error": { ... } } envelope on stdout; text failures emit one concise actionable line without a stack trace.

Lint Configuration

An optional .grace-lint.json file at the project root (next to .grace) controls how grace lint and the query commands collect code files:

{
  "ignoredDirs": ["generated", "fixtures-output"]
}

• ignoredDirs lists directory names to prune from file collection, on top of the built-in set below. Names match at any depth; globs and paths are not supported.
• The file must be a JSON object with supported keys only. Broken JSON, a non-object shape, an unknown key, or a non-array ignoredDirs is a config.* lint error, and query commands refuse to run until the file is fixed.
• A directory that cannot be listed (restrictive permissions, sandbox leftovers) is skipped with a walk.unreadable-directory warning instead of aborting the run; add its name to ignoredDirs to prune it silently. Explain any of these codes with grace lint --explain <code>.

Built-in ignored directories:

• VCS metadata: .git, .svn, .hg
• JavaScript/TypeScript output and caches: node_modules, dist, build, coverage, .next, .nuxt, .output, out, .turbo, .vite, .parcel-cache, .svelte-kit, .astro, storybook-static, .cache, .yarn, .nyc_output, bower_components, jspm_packages, .stryker-tmp, .serverless, .docusaurus
• Python bytecode, virtualenvs, and tool caches: __pycache__, venv, .venv, .tox, .nox, .pytest_cache, .mypy_cache, .ruff_cache, .pyre, .pytype, htmlcov, .eggs, .hypothesis, .ipynb_checkpoints, __pypackages__, .pixi, cover
• Test reports and artifacts: test-results, test-reports, playwright-report, blob-report, allure-results, allure-report, test-output, newman, cucumber-report, cucumber-reports
• JVM and Rust build output: target, .gradle, .idea
• Vendored dependencies (Go modules, Ruby bundler, PHP Composer): vendor
• Swift/Apple toolchain output and dependencies: .build, Pods, Carthage, DerivedData
• Dart/Flutter tooling cache: .dart_tool
• Ruby/general scratch space: tmp, .bundle
• Editor metadata: .vscode

Analysis Cache

Successful per-file language analyses are cached across runs, so unchanged governed files are not re-analyzed. Entries are keyed by file content and extension plus a schema version: any file edit or analyzer logic change invalidates the entry automatically, and failed analyses are never cached, so fixing a missing runtime takes effect immediately.

• Location: $XDG_CACHE_HOME/grace-cli/analysis, falling back to ~/.cache/grace-cli/analysis. Override the base directory with GRACE_CACHE_DIR.
• Disable caching with GRACE_NO_CACHE=1.
• The cache lives outside the project: it never touches .grace and produces no drift noise.

Grep-First Navigation

Prefer this order when narrowing scope:

1. Search .grace/graph/index.xml for graph document routing.
2. Open routed graph documents for M-* and DF-* anchors.
3. Search .grace/verification/index.xml for verification routing.
4. Open routed verification documents for V-M-* entries.
5. Search .grace/changes/active/C-* for in-flight specs and plans.
6. Search source/test files for LINKS:, START_MODULE_CONTRACT, START_CONTRACT:, and START_BLOCK_.

Common anchors:

• GD-* graph document wrappers
• M-* module IDs
• DF-* data-flow IDs
• VD-* verification document wrappers
• V-M-* verification IDs
• C-* change bundles
• T-* implementation plan tasks

Repository Layout

Development

bun test
bun run ./scripts/validate-marketplace.ts
bun run validate:packed
bun run validate:release

For CLI changes, keep tests in src/grace-lint.test.ts, src/grace-status.test.ts, and src/grace-query.test.ts aligned with the GRACE 4 .grace fixture model.

Stable releases use a protected-main two-stage flow. release:bump runs on a clean release branch that contains current origin/main, updates and validates the version surfaces, commits them, pushes the branch, and finds or creates the release PR without creating a tag. After its required checks pass and the PR is merged, release:finalize X.Y.Z runs from clean synchronized main, revalidates the exact stable state, creates the annotated tag, and pushes only that tag. CI independently requires the stable tag commit to equal fetched origin/main and gates npm latest publication through the reviewer-protected stable-release environment, whose explicit deployment policies allow only branch main and tags v*. Protected main requires Linux, Windows, and real-Dart checks without requiring a separate PR approval, while an active ruleset keeps v* tags immutable. bun run release:checklist verifies those controls and, after publication from the exact release tag commit, verifies HEAD == tag, npm/GitHub channel metadata, and that the local npm pack shasum matches the immutable published tarball.