mcpField
G
grace-plan

grace-plan

github.com/osovvDevelopment25640 installsUpdated 5w ago
Repository

About grace-plan

grace-plan is a GRACE workflow skill for turning one approved active GraceChangeSpec into a draft or explicitly approved executable GraceChangePlan. It guides planning without implementing source code or modifying existing approved plans and project state.

Key features

  1. 01Validate approved change specifications
  2. 02Run active-baseline lint preflight
  3. 03Create plans from the XML template
  4. 04Define scopes, assertions, and tasks
  5. 05Check task dependencies for cycles
  6. 06Protect approved plans and project state

Use cases

  1. 01Plan an approved GRACE change
  2. 02Specify testable baseline and target conditions
  3. 03Define task dependencies before implementation
  4. 04Review stale-state and parallel-safety warnings

MCP support

This skill produces GraceChangePlan artifacts for use in the GRACE workflow. It runs GRACE lint and can recommend checking status after approval.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/osovv/grace-marketplace --skill grace-plan

After installing, type/grace-planin Claude Code to confirm it loaded.

Bundled filesagents/openai.yamlreferences/change-plan-template.xml

Details

From the project README
Convert one approved active `GraceChangeSpec` into the executable `GraceChangePlan`; do not implement source code. - Required: `.grace/changes/active/C-CHANGE-ID/spec.xml` - Optional: sibling `design-context.xml` - Current state: `.grace/context`, graph and verification indexes, and their routed documents - Require `.grace/changes/active/C-CHANGE-ID/spec.xml` with `GraceChangeSpec`, status `approved`, and exactly one matching direct `C-*` wrapper. - Refuse draft, rejected, cancelled, applied, or superseded specs. - Treat optional `design-context.xml` as explanatory; `spec.xml` wins on conflict. - Run `grace lint --path PROJECT --assertions current` before planning and surface stale or invalid active baselines.

<approved_plan_immutability>

  • If plan.xml already exists with status approved, stop before writing.
  • Do not refresh BaselineAssertions, TargetAssertions, DurableScope, ObservedWriteScope, or tasks in place.
  • Create a new C-* bundle and mark the old bundle superseded with an explicit replacement reference. </approved_plan_immutability>

<must_do> Produce plan.xml from references/change-plan-template.xml as draft unless the user explicitly approves the completed plan. Require a matching C-* wrapper, meaningful intent, non-empty machine-checkable baseline and target assertions, explicit durable and observed scopes, and unique acyclic T-NNN tasks. A scope with no writes must use an explicit <None /> marker; prose such as "none" is invalid. Every task has one Title, one DependsOn element listing zero or more predecessors as canonical comma-separated T-NNN values (for example <DependsOn>T-001, T-002</DependsOn>), non-empty acceptance criteria, and non-empty verification commands. Dependencies form a directed acyclic graph: list only true predecessors and never linearize independent tasks into a chain to express ordering. Surface stale-state and coexistence warnings, and reject unsupported scope glob syntax instead of guessing. </must_do>

<command_phase_rules>

  • current is an active-baseline preflight and is valid only before observed writes begin.
  • baseline is the selected pre-edit gate, target is selected post-edit evidence, and final is the outer apply/archive gate owned by grace-execute.
  • MustPassCommand contains leaf project evidence such as tests, typecheck, build, format, or package checks. Never place grace lint, grace status, or another GRACE lifecycle command inside it.
  • Never put --assertions current in TargetAssertions or in task verification that runs after writes. Use selected target/final lint externally instead.
  • A MustPassCommand must complete within its declared budgetSeconds (absent, the global --command-timeout applies) on the reference host; declare the budget you have measured rather than inheriting a default that will kill the command mid-gate.
  • A whole-suite command whose runtime is dominated by substrate startup — containers, databases, browsers, emulators — belongs in an acceptance tier, not in the gate; never declare both a whole-suite command and the file-level commands it already re-runs. </command_phase_rules>
- Active-baseline preflight: `grace lint --path PROJECT --assertions current` - Parallel safety: `grace lint --path PROJECT --parallel-preflight` - Recommend `grace status --path PROJECT --json` after approval.

<hard_rules> Do not implement code, silently approve a plan, overwrite an approved plan, or mutate current graph/verification artifacts while planning. Semantic anchors are canonical XML tags, never attributes. </hard_rules>

Comments

Markdown supported