From grace
Runs GRACE architectural planning phase: designs module architecture, contracts, data flows, verification references. Outputs development-plan.xml, verification-plan.xml, knowledge-graph.xml. Use after defining requirements and technology.
npx claudepluginhub osovv/grace-marketplace --plugin graceThis skill uses the workspace's default tool permissions.
Run the GRACE architectural planning phase.
Creates Architecture Decision Records (ADRs) in MADR format, arc42 documentation, and plan-context.md as context bridge to Claude Code. For architecture, tech stack, system design, or technical structuring.
Guides architecture design via Socratic questioning, generates technical docs like overview.md, domain-model.md, and ADR for new features, systems, or project structuring.
Advanced — End-to-end architectural design flow: ADR → spec → plan. Best for significant technical decisions that require a formal specification and an implementation plan. For a decision without a spec, use /archcore:decide. For codifying standards, use /archcore:standard-track.
Share bugs, ideas, or general feedback.
Run the GRACE architectural planning phase.
docs/requirements.xml must exist and have at least one UseCasedocs/technology.xml must exist with stack decisionsdocs/verification-plan.xml should exist as the shared verification artifact template$grace-init firstWhen designing the architecture, apply these principles:
Every module gets a MODULE_CONTRACT before any code is written:
Classify each module as one of:
Structure docs/knowledge-graph.xml for maximum navigability:
M-xxx NAME="..." TYPE="..."fn-name, types as type-NamePlanning is incomplete if modules cannot be verified.
For every significant module, define during planning:
verification-ref like V-M-xxxRead docs/requirements.xml. For each UseCase, identify:
Propose a module breakdown. For each module, define:
verification-refPresent this to the user as a structured list and wait for approval before proceeding.
Before finalizing the plan, derive the first verification draft:
DF-xxx data flowsV-M-xxx verification entries for important modulesPresent this verification draft to the user as part of the same approval checkpoint. If the verification story is weak, revise the architecture before proceeding.
Run "mental tests" for 2-3 key user scenarios step by step:
Present the walkthrough to the user. If issues are found — revise the architecture.
After user approval:
docs/development-plan.xml with the full module breakdown, public module contracts, target paths, observability notes, data flows, and implementation order. Use unique ID-based tags: M-xxx for modules, Phase-N for phases, DF-xxx for flows, step-N for steps, and V-M-xxx references for verification.docs/verification-plan.xml with global verification policy, critical flows, module verification stubs, and phase gates.docs/knowledge-graph.xml with all modules (as M-xxx tags), their public-interface annotations (as fn-name, type-Name, etc.), verification-ref links, and CrossLinks between them.$grace-verification to deepen tests and trace expectations, $grace-execute for sequential execution, or $grace-multiagent-execute for parallel-safe waves."Always produce: