planning

Translates approved architecture designs into phased implementation plans with dependency rules.

1|1|Updated Jun 24, 2026
One-click install
npx skills add https://github.com/growmax/growmax-skills --skill planning-growmax
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: planning
Source: https://github.com/growmax/growmax-skills/tree/main/gmax/skills/planning
Command: npx skills add https://github.com/growmax/growmax-skills --skill planning-growmax

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Turning an approved architecture design into an actionable build plan is error-prone: phases overlap, files get double-owned, dependencies are vague, and failure states are forgotten until review. This Skill enforces a strict plan format and phase rules so every design element lands in exactly one verifiable phase. ## Core Features & Use Cases - Structured plan format: Generates void/plan/<slug>.md with a failure/edge-state table, phase DAG (depends:/shared:), and verification section inheriting the design's acceptance criteria. - Phase governance rules: Enforces one-concern-per-phase, file disjointness for parallel builds, checkable done when: criteria, and a proven-reuse rule that blocks premature abstraction. - Use Case: After an architecture design is approved, invoke this Skill to produce a phase plan where a builder can execute P1–P4 in order, knowing exactly which files each phase owns and what each phase consumes from prior phases. ## Quick Start Use the planning skill to turn the approved design at void/<task-slug>/architecture-design.md into a phase plan at void/plan/<slug>.md.

Frequently Asked Questions about planning

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I turn an architecture design into an implementation plan?▼

Read the approved design first, then write a plan file with a failure/edge-state table and phases. Each phase lists exact files, dependencies on prior phases, and an observable done-when criterion. Never redesign the architecture inside the plan.

How to split a software design into build phases?▼

Assign every file to exactly one phase, keep each phase to one concern with typically five or fewer files, and order phases by project layering such as types, data access, logic, then UI. Merge tiny phases and split oversized ones.

Can two implementation phases be built in parallel safely?▼

Two phases may build in the same wave only when their file lists are disjoint and neither touches a shared file the other names. Any overlap must be resolved by ordering them with an explicit depends contract instead.

What should a phase dependency declaration include?▼

A depends entry must name what the later phase actually consumes, such as a prior phase's hook return shape, not just the phase number. This makes the contract explicit between independent builder runs.

When should code be extracted into a shared module?▼

Extraction is justified only by proven reuse: one consumer keeps code local, two or more consumers move it to the area's shared location, and universal use goes to the generic library. Premature extraction is treated as a planning defect.