Skip to main content
/plan loads the writing-plans skill and produces a comprehensive implementation plan from your approved design. The plan is the contract between design and implementation — every task in it must be specific enough for an engineer with no prior context to execute without asking questions.
/plan requires Planning Mode to be active. The plan is written in Planning Mode. After the plan is saved you will switch to Fast Mode for the implementation phase.

What the plan contains

Every plan saved to docs/plans/YYYY-MM-DD-<feature-name>.md starts with a structured header:
Followed by a sequence of tasks, each one producing exactly one artifact.

Task granularity

Each step in the plan produces exactly one artifact: a written test, a passing test run output, a code file, or a commit. If a step would produce two artifacts, it is split into two steps. A typical task looks like this:

Plan validation checklist

Before handing the plan to execution, SuperAntigravity reads it from the perspective of an engineer who has never seen the codebase and verifies:
  • Every file path is exact and follows the documented convention
  • Every command includes expected output
  • Every task’s purpose is clear from its name and description alone
  • No task assumes knowledge of a prior conversation or undocumented context
  • Complete code is included in each task — no “add validation” shorthand

Execution options

After saving the plan, SuperAntigravity offers two ways to execute it:

Principles applied

The writing-plans skill enforces three engineering principles throughout every plan:
  • DRY — no duplicated logic across tasks
  • YAGNI — no tasks for features not required by the design
  • TDD — every task begins with a failing test before any implementation code
If the design doc from /brainstorm does not exist, SuperAntigravity will prompt you to run /brainstorm first. Plans written without an approved design are not valid inputs to /implement.