GRACE Contract Engineering Toolkit
Guide AI code changes with explicit project contracts, graph context, and verifiable plans.
- Source repo
- osovv/grace-marketplace
- Stars
- ★ 251
- Last updated
- 15d ago
- License
- MIT
- Primary language
- TypeScript
- FA score
- 74/100 · Some gaps
At a glance
- How it runs
- Works with
- Portable with changesCodex · Claude Code
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Engineering teams that want a specification and implementation plan approved before Claude Code, Codex CLI, or Kilo Code makes code changes.
- Not a fit if
- Teams needing export-parity analysis for Go, Rust, Java, or other unregistered languages
- CLI users unable to install Bun or a required language runtime
- Source review
- 74/100 · Some gaps
What does this agent do, and when should you use it?
GRACE is a contract-first AI engineering method built around semantic markup, `.grace` XML artifacts, knowledge-graph navigation, assertions, scopes, and log-driven verification. This repository distributes GRACE Agent Skills and an optional Bun-powered `grace` CLI; it is a packaging and distribution repository rather than an end-user application. GRACE 4 uses `.grace` as the durable project model for context, graph and verification projections, and change bundles. The skills guide an agent from initialization through specification, planning, execution, and verification, while the CLI provides linting, status checks, and projection-backed queries. The README documents Claude Code Marketplace and Agent Skills-compatible installation, and names Claude Code, Codex CLI, and Kilo Code as supported environments; use each environment's documented installation path.
For a new project, $grace-init creates the .grace skeleton, then $grace-spec and $grace-plan produce a change specification and plan. Plans define assertions, scopes, tasks, and verification gates. Before implementation, grace lint --path <root> --assertions current checks the current baseline, and grace status --path <root> --json reports project health. $grace-execute carries out an approved plan sequentially or in parallel-safe mode; grace lint can check baseline, target, and final assertions, with MustPassCommand execution enabled explicitly through --run-commands. The CLI also offers grace module find/show, grace verification find/show, and grace file show to inspect graph modules, verification entries, and file-local markup. It produces lint and status results, projection query output, and run logs; test-like commands run only when opted into.
- Engineering teams that want a specification and implementation plan approved before Claude Code, Codex CLI, or Kilo Code makes code changes.
- Teams maintaining
.graceproject state who need checks across context, graph, verification, and active changes. - Developers who want baseline assertions checked before implementation and final assertions checked before applying a change.
- Maintainers who need to find modules, dependencies, or verification entries through the
grace moduleandgrace verificationcommands. - Teams migrating GRACE 3 projects that want an agent-applied migration followed by CLI validation.
How do you install or deploy this agent?
Install the skills first; the CLI is optional but recommended for checks and queries. For Claude Code, add the marketplace and install the plugin. In an Agent Skills-compatible environment, copy the repository's skill directories. The CLI requires Bun on PATH and installs the stable package from npm latest. The README does not provide a Kilo Code-specific installation command or document account and model charges.
How do you use this agent?
The following is the documented flow for a new GRACE 4 project; $grace-* names are Agent Skill invocations. After installing the optional CLI, run checks from the project root:
What are this agent's strengths and limitations?
- The
.gracemodel keeps requirements context, graph, verification, and change artifacts in a durable project structure. - The workflow has explicit stages for spec approval, planning, baseline checks, execution, and final assertions.
- The CLI covers lint, status, module, verification, and file-markup queries, with a stable JSON error envelope for command failures.
- TypeScript/JavaScript semantic analysis is compiler-backed; Python and Dart have runtime adapters.
- The CLI requires Bun; governed Python and Dart files also require their respective runtimes.
- Languages without registered analyzers receive structural checks only;
MODULE_MAPis trusted and export parity is not analyzed. - GRACE 4 does not treat GRACE 3 project docs as current state; migration uses
$grace-migrateand requires report review. - The repository packages skills and an optional CLI rather than providing a standalone end-user application.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| GRACE Contract Engineering Toolkit This agent | 74 · Some gaps | Agent plugin / skillFree | ★ 251 | 15d ago | TypeScript | Codex · Claude Code |
| WUPHF — A Collaborative Office for AI Employees with a Shared Brain | 66 · Some gaps | CLIFree + model costs | ★ 1.5k | today | Go | Codex · Claude Code |
| Cognee Memory Platform | 47 · Major gaps | Library / SDKFree + model costs | ★ 32k | today | Python | Claude Code · OpenAI API |
| Pilot Shell | 53 · Major gaps | CLIPaid | ★ 2.1k | 1d ago | JavaScript | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The README says verification commands run from the project root by default, reject absolute and escaping paths, and require several preconditions plus explicit confirmation for migration cleanup. Command execution is opt-in, and the cache is outside the project and can be disabled. These details support limited, visible side effects. Deductions: the supplied files do not explain access controls or redaction for sensitive data, credentials, or run logs; recovery after cleanup and risks from external commands or publishing are not fully described. Publisher identity is unknown, and the materials do not establish a clear maintainer or trusted-source attribution.
The README describes fail-closed behavior, distinguishes missing runtimes from adapter failures, and specifies structured JSON errors and concise text errors. CI configuration covers Linux, Windows, and a real Dart adapter check; the package manifest also specifies Bun and dependencies. Deductions: these files support the design and intended checks, but this static review did not execute them, and the materials make no dependency availability commitment.
The skills list covers initialization, specification, planning, execution, migration, review, and queries. The README explains supported languages, runtime requirements, governance boundaries, and the GRACE 3 migration path. Deduction: the supplied materials do not state skill trigger conditions or when not to invoke them, so trigger precision is limited; environment fit also depends on Bun and, for some languages, their runtimes.
The README provides a clear layout, installation methods, quick start, command tables, and limitations. LICENSE and package.json identify MIT, and the packaged version is 4.2.1. Deductions: the supplied materials contain no changelog content or named maintenance responsibility; the version and release process are described, but they do not establish a complete change history or long-term maintenance commitment.
The CLI offers linting, status, module and verification queries, with text and JSON output. The skills cover the workflow from project modeling through change verification, and project checks and caching can reduce repeated analysis. Deductions: the materials do not quantify time savings, operating costs, or adoption effort, and Bun plus some language runtimes add user setup costs.
The README, package manifest, license, CI, and publishing workflow provide multiple repository sources for installation, version, dependency, and validation-process claims. The documentation also distinguishes exact analysis, heuristic confidence, and structural checks for unsupported languages. Deductions: workflow and script configuration does not prove successful execution in this review; several feature and safety claims remain repository assertions without independent corroboration.
- This low-confidence assessment uses only the supplied static files; the CLI, skills, and CI workflows were not run.
- The supplied materials do not clearly describe sensitive-data handling, credential management, or run-log protections.
- Running declared MustPassCommand entries executes project commands; users should inspect those commands and their side effects.
FAQ
Do I need Bun to use the CLI?
PATH. Install the skills first; the CLI is optional but recommended.Will it run tests or project commands automatically?
MustPassCommand, but those commands run only when you pass --run-commands. The documented examples include tests, type checks, builds, and formatting checks.Which languages get semantic export analysis?
Can GRACE 3 project docs be used directly as GRACE 4 current state?
$grace-migrate and review the migration report. The CLI validates the generated .grace result but does not convert the legacy docs itself.