con un clic
grace-setup-subagents
// Create GRACE subagent presets for the current agent shell. Use when you want GRACE worker and reviewer agent files scaffolded for Claude Code, OpenCode, Codex, or another shell.
// Create GRACE subagent presets for the current agent shell. Use when you want GRACE worker and reviewer agent files scaffolded for Claude Code, OpenCode, Codex, or another shell.
| name | grace-setup-subagents |
| description | Create GRACE subagent presets for the current agent shell. Use when you want GRACE worker and reviewer agent files scaffolded for Claude Code, OpenCode, Codex, or another shell. |
Create GRACE subagent files for the current shell by reusing the shell's own agent-file conventions.
$grace-multiagent-execute works best when the shell already has GRACE-specific worker and reviewer presets.
This skill scaffolds those presets into the correct local agent directory for the current shell.
The controller remains in the main session. Workers should expect compact execution packets, fresh one-module ownership, scoped reviews, and controller-managed graph updates.
By default, create these subagents:
grace-module-implementergrace-contract-reviewergrace-verification-reviewergrace-fixerThe main session remains the controller. This skill does not create a controller agent.
Use the current environment and project structure to determine where the skill is running.
Prefer, in this order:
Typical examples:
.claude/.opencode/.codex/If detection is ambiguous, ask the user which shell to target.
Do not guess the target file format if a local example exists.
Search for an existing agent file for the current shell:
Use a real example to infer:
If no reliable local example exists:
Default to project-local setup unless the user explicitly asks for global setup.
Create the GRACE presets under the shell's local agent directory in a grace/ subfolder when the shell supports subfolders cleanly.
If the shell does not support nested subfolders for agents, place the generated files directly in the local agent directory with GRACE-prefixed names.
The role prompt bodies live in references/roles/:
references/roles/module-implementer.mdreferences/roles/contract-reviewer.mdreferences/roles/verification-reviewer.mdreferences/roles/fixer.mdThese are the shared role bodies. Reuse them. Only the shell-specific wrapper should change.
These shared prompts assume the newer multi-agent workflow:
docs/verification-plan.xml in addition to plan and graph artifactsFor each role:
If the shell has no first-class subagent file concept, create the nearest useful equivalent and explain the limitation.
After scaffolding, report:
grace-multiagent-execute, grace-reviewer, grace-fix, and grace-verificationOperate 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`.
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.
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.
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.
Execute a GRACE development plan in controller-managed parallel waves with selectable safety profiles, verification-plan excerpts, batched shared-artifact sync, and scoped reviews.
Show the current health status of a GRACE project. Use to get an overview of project artifacts, codebase metrics, knowledge graph health, verification coverage, and suggested next actions.