Structured plan format for manual planning and navigator-led execution. Use when charting multi-step plans intended for @gnd-navigator to dispatch as legs via runSubagent in any project.
Plan multi-step work as structured legs for @gnd-navigator to dispatch to gnd-diver.
Break the user's goal into bounded, reviewable legs. Project constraints come from project guidance sources, not hidden assumptions.
If LOCAL.md exists in this skill's directory, read it and apply its contents as project-specific extensions or overrides to these instructions. Local overrides take precedence when they conflict with base instructions.
Identify authoritative guidance in priority order:
README.md and area docsRead only what matters. Record useful sources in the plan's ## Project Context.
Discovery → Alignment → Draft → Workshop → Refinement
Explore the codebase: read relevant files, run searches, identify affected modules. Skim archived plans or critiques for prior corrections if they exist. Do not write legs yet.
One round after Discovery. Summarize findings, then ask scope/approach questions. At minimum: (a) in-scope vs out-of-scope, (b) non-obvious tradeoffs, (c) genuine ambiguities. Skip only when the task maps to a single unambiguous leg.
Present a plan outline — not full legs:
After the draft, automatically workshop each leg:
Confirmed: yes.Do not advance until all legs are confirmed or removed.
User Intent confirmation. Present a 2–4 sentence summary of the user's goal distilled from the conversation. Ask: "Does this capture your goal?" Options: Looks right (recommended), Needs revision. Update and re-confirm if revised.
Then write the full plan with all fields. Output only:
The plan file is the source of truth — do not paste the full plan into chat.
"review" or "walk me through it": re-enter workshop for unconfirmed legs, or ask which confirmed leg to revisit. Confirmed legs are not re-presented unless a subsequent change significantly alters their scope.
Plans live in .planning/ as active-plan-YYYY-MM-DD-HHmm-<slug>.md.
gnd-critique appends findings then archives.# Plan: [Short Title]
## Project Context
- Sources:
- `path/to/doc.md` - why it matters
- Constraints:
- [Derived rules]
- Full validation:
- `command` or checklist
- Delivery verification:
- deployed URL, package check, artifact check, local-only, or `none`
## User Intent
[2-4 sentences confirmed by user during Refinement. Navigator and critique
reference this to evaluate alignment.]
## Legs
### LEG-1: [Area] - [Short description]
- Status: pending
- Confirmed: yes | no
- Goal link: [How this leg serves the User Intent]
- Depends on: none | LEG-N
- Owned files:
- `path/to/file.ts`
- Read-only:
- `path/to/reference.ts` - reason
- Deferred shared edits:
- `shared/file.ts` - what to change
- Verification: `command`
- Intent: [Detailed implementation description]
## Dispatch Order
Sequential via runSubagent (navigator reviews between each):
1. LEG-1 (label) - no dependencies
2. LEG-2 (label) - depends on LEG-1
After all complete: deferred edits → full validation → delivery verification → commit → push.
| Field | Notes |
|---|---|
| Status | pending, in-progress, done, failed. Only navigator updates during dispatch. |
| Confirmed | yes/no. Set to yes on user approval in workshop. Navigator won't dispatch no. |
| Depends on | none or a leg ID. Dispatch Order makes the sequence explicit. |
| Dispatch agent | Always gnd-diver. If a leg seems too vague, tighten the intent or split it — don't assign a different agent. |
| Owned files | Exhaustive list the sub-agent may modify. No globs. One leg per file — never split. Grep during Draft/Workshop to confirm targets exist. |
| Read-only | Reference files the sub-agent reads but must not modify. Include a reason. |
| Deferred shared edits | Changes to shared files (package.json, routers, etc.) the navigator applies after all legs complete. Be precise. |
| Verification | Single shell command covering only this leg's files. Not the project's full gate. For test legs: list explicit per-file expected assertions. |
| Intent | The critical field. Must be specific (name functions, interfaces, selectors), self-contained (embed needed constraints), outcome-oriented (what code does when done), and bounded (number sub-tasks). |
package.json, build.ts, routers, shared styles) never appear in owned sets. Use deferred shared edits.Leg intents must embed relevant project constraints so sub-agents don't rediscover them. Common categories: performance/bundle budgets, layout checkpoints, accessibility, content/copy rules, state/persistence, styling/design-system, build/test/release, motion/audio/media. Include only what affects each leg.
List legs in dispatch order. Note dependencies and parallelism. The dispatch order must be acyclic — no circular dependencies between legs. End with:
After all complete: deferred edits → `## Project Context` full-validation → delivery verification → commit → push.
Project-specific sync, packaging, or publish steps belong in ## Project Context.