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.
git clone --depth 1 https://github.com/osovv/grace-marketplace /tmp/grace-setup-subagents && cp -r /tmp/grace-setup-subagents/skills/grace/grace-setup-subagents ~/.claude/skills/grace-setup-subagentsSKILL.md
Create GRACE subagent files for the current shell by reusing the shell's own agent-file conventions. ## Purpose `$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. ## Default Roles By default, create these subagents: 1. `grace-module-implementer` 2. `grace-contract-reviewer` 3. `grace-verification-reviewer` 4. `grace-fixer` The main session remains the controller. This skill does **not** create a controller agent. ## Process ### Step 1: Detect the Current Shell Use the current environment and project structure to determine where the skill is running. Prefer, in this order: 1. explicit environment hints from the shell 2. project-local config directories 3. user-level agent directories Typical examples: - Claude Code projects often use `.claude/` - OpenCode projects often use `.opencode/` - Codex projects often use `.codex/` If detection is ambiguous, ask the user which shell to target. ### Step 2: Find a Real Agent File Example Do **not** guess the target file format if a local example exists. Search for an existing agent file for the current shell: - first in the current project - then in the user's global config for that shell - then in nearby projects if needed Use a real example to infer: - file extension - frontmatter or config structure - model field names - tool/permission layout If no reliable local example exists: - look for official shell documentation - if documentation is still unclear, ask the user for a canonical sample or doc link ### Step 3: Choose Scope and Target Directory 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. ### Step 4: Read the Role Prompts The role prompt bodies live in `references/roles/`: - `references/roles/module-implementer.md` - `references/roles/contract-reviewer.md` - `references/roles/verification-reviewer.md` - `references/roles/fixer.md` These are the shared role bodies. Reuse them. Only the shell-specific wrapper should change. These shared prompts assume the newer multi-agent workflow: - workers receive execution packets instead of rereading full XML artifacts whenever possible - reviewers default to scoped gate review and escalate only when evidence suggests wider drift - verification is split across module, wave, and phase levels - the controller owns `docs/verification-plan.xml` in addition to plan and graph artifacts ### Step 5: Render Shell-Specific Agent Files For each role: 1. wrap the shared role body in the file format discovered in Step 2 2. preserve the shell's conventions for: - metadata fields - model names - permissions or tool declarations - subagent mode flags 3. write the file into the target directory If the shell has no first-class subagent file concept, create the nearest useful equivalent and explain the limitation. ### Step 6: Report What Was Created After scaffolding, report: - detected shell - target directory - created files - any assumptions copied from the local example - any fields the user should adjust manually, such as model aliases ## Rules - Prefer copying the shell's real local format over inventing one - Keep prompts aligned with `grace-multiagent-execute`, `grace-reviewer`, `grace-fix`, and `grace-verification` - Do not overwrite existing files without user intent - Do not create architecture-planning agents here; this skill is for execution support - Do not introduce worker-pool or worker-reuse assumptions into the generated presets - If the shell supports agents differently, create the nearest working equivalent and explain the difference
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.
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 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.