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.

An optional bare profile word anywhere in the arguments — prototype, standard, extended, or enterprise — sets the plan’s delivery profile, which decides how finely the plan is sliced and how deep each spec goes. Without one, the repository’s profile setting applies, and standard when that is absent too.

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.
• Executable leaves sized to the plan’s delivery profile — one visible vertical slice under prototype, roughly one to two loop-hours under standard, about one release-unit-day under extended, about one loop-hour under enterprise — with descriptions as deep as that profile asks for.
• 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

The skill is written as a goal — a plan build-item can walk unattended — plus the rules and hard floors that hold while it gets there. In practice a run goes like this:

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.

At the sign-off that closes discovery, plan also writes a Delivery profile: marker line into the root item’s description. The profile travels with the plan, so one repository can run a prototype plan and an enterprise plan side by side, and the delivery loop reads the marker before it reads the repository config.

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.

Rebalancing a plan

/devstride:rebalance I1234 prototype

Use this when a plan was sliced for more rigor than the work turns out to need — or less — or when you want the same plan as fewer, larger items: /devstride:rebalance I1234 extended keeps standard’s safety knobs and floors and changes only the size. Successors are sized to the target profile’s leaf size. It re-slices only the leaves that have not started; Done and In Progress items, and leaves merged onto their epic's branch awaiting its release, are never touched. The skill shows a before/after table of the leaves it would merge or split and changes nothing until you sign off. Then it:

• creates the successor leaves, embedding the specs of every leaf they absorb;
• archives each absorbed original with a pointer to its successor — nothing is deleted;
• rewires the blocked_by/blocks edges so the graph still walks in order;
• numbers successors with the dotted splice convention, so existing [N] identifiers stay stable;
• rewrites the root’s Delivery profile: marker to the new profile;
• runs rationalize-gantt over the not-done items.

It refuses to run while a build loop is active on the same plan; finish or stop the loop first.

Next step

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

/devstride:build-item

Run /clear before switching from planning to execution: the session gate keeps authoring and execution commands in separate sessions. See The Delivery Loop before handing the plan to /loop.