Plan a feature
Turn an idea into a measurable spec, break it into stories and tasks your agent can build, and pick what fits the next release cut.
Planning in OpenPlanr happens in 3 steps: a spec that says what and why, a plan of stories and tasks that says how, and a sprint that says what fits next. Each step writes files under .planr/ that you review like code.
1. Write the spec
Invoke /spec$spec@planr-spec with the change you want and the problem it solves. The skill reads your repository first and asks only about decisions that would change the scope, at most 3 short questions at a time. It writes one specification with observable requirements and acceptance criteria, each with a stable ID.
The walkthrough is in Write your first spec.
2. Break it into stories and tasks
Invoke /planr:plan$plan@planr-plan with the spec ID. Plan reads the spec, the repository instructions, the relevant code and tests, and any design handoff, then writes stories and tasks next to the spec:
- Every story gets acceptance criteria with stable IDs, starting at AC-001.
- A story gets one Tech task, or one UI task and one Tech task when it has a design surface. It never gets more than 2.
- Every task names the files to create, modify, and preserve, the checks that prove it is done, and the acceptance IDs it delivers.
- A task depends on another only when it consumes that task's output. File overlap and numbering never create a dependency.
Plan validates the frontmatter and the acceptance coverage, then stops. It hands you the next ready task and the exact command to build it, and it never starts building on its own.
When the request is already clear, you can skip the spec: Plan also accepts a clear product request and reads the repository for the rest.
3. Pick what fits the next cut
Invoke /sprint$sprint@planr-sprint before a sprint or a release cut. Sprint reads every open backlog item in full, checks the code each item names before believing its claim, and sorts what is stale, blocked, or ready. Then it fits the surviving items to your capacity and the next cut, tests its picks, and writes the sprint.
Ask for a refine-only run to get the refinement without a sprint. Any run can be repeated and compared with the previous one.
Keep the plan consistent
When stories, tasks, and statuses may have drifted apart, invoke /sync$sync@planr-sync. It audits read-only by default and repairs only when you ask. From the terminal, openplanr sync --dry-run previews the cross-reference fixes and openplanr sync applies them.
Prompts for this stage
- Turn a rough idea into a spec
- Pin down acceptance criteria before planning
- Break a spec into stories and tasks
- Plan straight from a clear request
- Pick the next sprint against the real code
- Refine the backlog without picking a sprint
- Audit the plan for drift
Next: Design before you build when the work has screens, or Build one task at a time.