grace-plan
Run the GRACE architectural planning phase.
Prerequisites
docs/requirements.xmlmust exist and have at least one UseCasedocs/technology.xmlmust exist with stack decisionsdocs/verification-plan.xmlshould exist as the shared verification artifact template- If requirements or technology are missing, tell the user to run
$grace-initfirst - If the verification plan template is missing, recreate it before finalizing the planning artifacts
Architectural Principles
When designing the architecture, apply these principles:
Contract-First Design
Every module gets a MODULE_CONTRACT before any code is written:
- PURPOSE: one sentence, what it does
- SCOPE: what operations are included
- DEPENDS: list of module dependencies
- LINKS: knowledge graph node references
More from osovv/grace-marketplace
grace-explainer
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.
49grace-multiagent-execute
Execute a GRACE development plan in controller-managed parallel waves with selectable safety profiles, verification-plan excerpts, batched shared-artifact sync, and scoped reviews.
30grace-execute
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.
28grace-status
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.
27grace-fix
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.
27grace-refresh
Synchronize GRACE shared artifacts with the actual codebase. Use targeted refresh after controlled waves, or full refresh after refactors and when you suspect wider drift between the graph, verification plan, and code.
27