The Planning Loop

The fastest useful entry point is:

/devstride:plan I1234

Pass an existing DevStride parent item. The skill reads what is already below it, asks about the plan, shows the proposed hierarchy and specs, and creates nothing until you approve them.

What a finished plan contains

• Your organization’s actual work types for grouping items, release units, and leaves.
• Self-contained release units that are safe to merge as complete increments.
• Roughly one-day executable leaves with implementation-ready descriptions.
• A real blocked_by/blocks graph with no orphan leaves.
• Synthetic dates derived from that graph.
• Stable [N] execution-order prefixes on leaf titles.

The goal is not a long planning document. It is a live roadmap that /devstride:build-item can walk in the correct order.

How plan works

1. Read before changing. It invokes comprehend-plan and classifies the root as empty, an existing plan to extend, or shallow placeholder content that needs your decision.
2. Discover the shape with you. It asks about source material, scope, release boundaries, sequencing, risk, and deferrals. Human decisions remain in the main conversation.
3. Draft after the shape is approved. Parallel agents may draft descriptions for grouping items, release units, and leaves, but they do not make unresolved architecture or scope decisions and do not write DevStride data.
4. Create the approved hierarchy. It creates every intermediate work-type level your organization requires.
5. Wire the dependency graph. Foundation work fans out, convergent work fans in, and genuinely independent work stays parallel. Every new leaf must have at least one dependency relationship.
6. Rationalize dates. It delegates the cascade and invalid-edge review to rationalize-gantt.
7. Number the execution order. Only after graph and dates are stable does it add [1], [2], and so on. Existing numbered items are never renumbered on an extension pass.
8. Remember the handoff. It stores the plan root in Claude Code project memory for a later bare /devstride:build-item.

What makes a good release unit

A release unit is also the delivery loop’s branch and release boundary. If only that unit shipped, a user should gain something coherent. Pure foundation work normally belongs in the first value-delivering unit that needs it; a genuinely shared foundation can remain separate when it is clearly marked as an internal enabler.

Each release-unit spec records:

• the user value and architectural scope;
• contracts it establishes for later work;
• blast radius and feature gating;
• billable or externally visible infrastructure that needs an owner decision;
• deploy-order hazards inside the unit;
• the delivery order of its leaves.

Deferred work belongs in a separate deferred unit. Parking it under an active value unit prevents that unit from reaching zero remaining leaves and becoming release-ready.

Read an existing plan safely

/devstride:comprehend-plan I1234

This reads the full descendant tree, descriptions, comments, statuses, and dependency relationships. It reports contradictions between a description and later comments instead of silently choosing one. Add a focus question after the item number when you need a specific answer.

Use it before a surgical plan edit when the current state is unclear.

Add one planned item

/devstride:insert-story I1234 add rate limiting to webhook intake
/devstride:insert-defect I1234 retries duplicate requests after a 429

The insert skills:

• find what the delivery loop would select next;
• create an honest spec or repro;
• splice the new item between its upstream dependency and the previous next item;
• assign a dotted stable number such as [23.1];
• re-run the selector and tell you if an earlier-dated parent item still wins.

They do not build code and do not re-date the whole plan. A Defect asks before jumping further ahead than a normal next insertion.

Use create-story or create-defect instead when the work is a standalone request that should not join a plan’s dependency chain.

Rationalize the timeline

/devstride:rationalize-gantt I1234

The result is a synthetic critical-path view: each leaf is one day, dependencies precede dependents, and parent items span their descendants. It is not a delivery forecast.

DevStride’s organization-wide Enable Link Mode must be off. The skill reads the setting and, when existing dependent dates are involved, performs and restores a probe-date write before the mass update to verify that the backend will not reschedule the plan behind it.

Cycle detection happens before the cascade dates are written. A cycle stops the mass update and reports the actual strongly connected cycle, not every innocent item that feeds it. The earlier probe may still have occurred and been restored.

After dating, invalid dependency lines are reviewed as:

• Remove — redundant or wrong;
• Repoint — real intent, but attached to a parent item or the wrong leaf;
• Keep with offset — the rare case that truly must wait for the entire target.

rationalize-gantt never changes execution-order titles. Dates can move; [N] identifiers stay stable.

Next step

Once the plan is approved and numbered, run one item:

/devstride:build-item

See The Delivery Loop before handing the plan to /loop.