grace-init
Bootstrap GRACE framework structure for a new project. Use when starting a new project with GRACE methodology - creates docs/ directory, AGENTS.md, and XML templates for requirements, technology, development plan, verification plan, knowledge graph, and operational packet contracts.
git clone --depth 1 https://github.com/osovv/grace-marketplace /tmp/grace-init && cp -r /tmp/grace-init/skills/grace/grace-init ~/.claude/skills/grace-initSKILL.md
Initialize GRACE framework structure for this project.
## Template Files
All documents MUST be created from template files located in this skill's `assets/` directory.
Read each template file, replace the `$PLACEHOLDER` variables with actual values gathered from the user, and write the result to the target project path.
| Template source | Target in project |
|------------------------------------------|-----------------------------|
| `assets/AGENTS.md.template` | `AGENTS.md` (project root) |
| `assets/docs/knowledge-graph.xml.template` | `docs/knowledge-graph.xml` |
| `assets/docs/requirements.xml.template` | `docs/requirements.xml` |
| `assets/docs/technology.xml.template` | `docs/technology.xml` |
| `assets/docs/development-plan.xml.template`| `docs/development-plan.xml` |
| `assets/docs/verification-plan.xml.template`| `docs/verification-plan.xml` |
| `assets/docs/operational-packets.xml.template`| `docs/operational-packets.xml` |
> **Important:** Never hardcode template content inline. Always read from the `.template` files — they are the single source of truth for document structure.
## Steps
1. **Gather project info from the user.** Ask for:
- Project name and short annotation
- Main keywords (for domain activation)
- Primary language, runtime, and framework (with versions)
- Key libraries/dependencies (if known)
- Testing stack (test runner, assertion style, mock/fake approach)
- Observability stack (logger, structured log fields, redaction constraints)
- High-level module list (if known)
- 2-5 critical flows or risky surfaces that must be verifiable early
2. **Create `docs/` directory and populate documents from templates:**
For each `assets/docs/*.xml.template` file:
- Read the template file
- Replace `$PLACEHOLDER` variables with user-provided values
- Write the result to the corresponding `docs/` path
3. **Create or verify `AGENTS.md` at project root:**
- If `AGENTS.md` does not exist — read `assets/AGENTS.md.template`, fill in `$KEYWORDS` and `$ANNOTATION`, and write to project root
- If `AGENTS.md` already exists — warn the user and ask whether to overwrite or keep the existing one
4. **Print a summary** of all created files and suggest the next step:
> "Run `$grace-plan` to design modules, data flows, and verification references. Then use `$grace-verification` to deepen tests, traces, and log-driven evidence before large execution waves. Use `docs/operational-packets.xml` as the canonical packet and delta reference during execution and refactors."Answer a question about a GRACE project using full project context. Use when the user has a question about the codebase, architecture, modules, or implementation — loads all GRACE artifacts, navigates the knowledge graph, and provides a grounded answer with citations.
Operate the optional `grace` CLI against a GRACE project. Use when you want to lint GRACE artifacts, explain/remediate lint issues, check autonomy readiness, inspect project or module health, inspect verification entries, resolve modules from names or file paths, inspect shared/public module context, or inspect file-local/private markup through `grace lint`, `grace status`, `grace module`, `grace verification`, and `grace file show`.
Execute the full GRACE development plan step by step with controller-managed context packets, verification-plan excerpts, scoped reviews, level-based verification, and commits after validated sequential steps.
Complete GRACE methodology reference. Use when explaining GRACE to users, onboarding new projects, or when you need to understand the GRACE framework - its principles, semantic markup, knowledge graphs, contracts, testing, and unique tag conventions.
Debug an issue using GRACE semantic navigation. Use when encountering bugs, errors, or unexpected behavior - navigate through the graph, verification plan, and semantic blocks to analyze the mismatch and apply a targeted fix.
Execute a GRACE development plan in controller-managed parallel waves with selectable safety profiles, verification-plan excerpts, batched shared-artifact sync, and scoped reviews.
Run the GRACE architectural planning phase. Use when you have requirements and technology decisions defined and need to design the module architecture, create contracts, map data flows, and establish verification references. Produces development-plan.xml, verification-plan.xml, and knowledge-graph.xml.
Refactor GRACE-governed code safely: rename, move, split, merge, or extract modules while keeping contracts, graph, verification, and semantic markup synchronized.