The Delivery Loop

Start with one item:

/devstride:build-item

build-item selects the next unblocked leaf, marks it In Progress, creates a branch, builds and reviews it, merges it through the configured path, updates the DevStride item, and stops after that iteration. Once you trust one pass, /loop /devstride:build-item repeats the process across the plan.

First understand the four paths

A one-off may be filed under a release unit, so the skill does not infer its path from ancestry. It detects the one-off from the leaf type, title numbering, and dependency relationships, then explicitly bypasses release-unit branch derivation.

Selection and branch choice

Empty arguments mean “next.” You can also name a leaf, say next under I1234, or pass a parent item number by itself to scope selection under that plan.

The next item is the highest-priority open leaf whose blockers are Done, inside the earliest-dated open parent item. Relationships are fetched explicitly because normal summary projections omit them.

For planned work, the working-base precedence is:

1. an explicit branch override or non-null integrationBranch;
2. the release-unit integration branch when epicIntegrationBranches.enabled is true;
3. baseBranch.

The release-unit ancestor is found by walking the entire parent chain and fetching each ancestor’s work type. The integration branch is created from a fresh base branch on the unit’s first item and then reused; its date is the creation date, not the current date.

What one iteration does

1. Select and validate. Show the ready set, check for human or infrastructure gates, and compare the item’s full spec with the current code.
2. Move to In Progress. This is a live DevStride update.
3. Create the item branch. branch-feature stops on a dirty tree and branches from the resolved working base.
4. Build and adversarially review. ultracode-build understands the contract, implements in small green commits, and runs a mandatory maximum-effort Claude review whose breadth scales with risk.
5. Settle the configured delivery path. Either local fast review and merge, or a pull request through pr and review.
6. Complete the item. Move it to Done, set the branch-to-merge date window, link the pull request or record the fast-merge commit, and reconcile material differences between the planned and shipped spec.
7. Track discoveries. New out-of-scope work with no existing home becomes an inserted Story or Defect instead of disappearing into pull-request prose.
8. Sync and count down the release unit. A clean working base and the remaining leaf count become the handoff for the next iteration.
9. Release the completed unit when allowed. Automatic cut and merge happens only when epicIntegrationBranches.autoRelease is true. Setup writes it false, so a newly configured repository stops at release-ready for an owner.

The skill renders its own numbered progress table as it moves. Its internal sequence is 0–8 with a 6.5; the list above is a reader-oriented summary, not those internal labels.

Fast merges: no item pull request

With epicIntegrationBranches.fastStoryMerges.enabled: true, a planned leaf on an integration branch receives:

• the Claude adversarial pass from the build engine;
• the configured local CLI reviewer, when present, through review’s local-only mode;
• configured typechecks, the full local test command, and frontend lint when applicable;
• a --no-ff merge onto the release-unit branch after all findings and checks settle.

There is no item pull request, cloud reviewer, CI run, or review-thread bookkeeping. Those gates move to the completed release unit; they are not declared passed on the item.

Fast mode requires at least one local review engine. If no build-time Claude pass covered the diff and no local CLI is available, the item falls back to the pull-request path. Red local checks always stop the merge.

When the unit reaches zero open leaves and automatic release is enabled, the loop:

1. merges the current base branch into the shared integration branch without rebasing it;
2. runs the configured local verification;
3. opens the release-unit pull request;
4. reviews the full accumulated diff, because this is the first cloud and CI pass over fast-merged code;
5. merges only after review and applicable gates settle;
6. deletes the integration branch only when deleteBranchAfterRelease allows it;
7. links the release pull request back to the release unit and its constituent leaves.

With autoRelease: false, none of those release mutations starts automatically; the unit is reported release-ready.

Pull-request path

pr authors the configured body, requests every configured cloud reviewer when it opens the pull request, and delegates findings and CI settlement to review.

In a draft-held repository:

1. The pull request opens as a draft.
2. Claude, the configured local CLI, and configured cloud reviewers run concurrently.
3. Findings are verified, fixed or dismissed with rationale, and cloud threads are replied to and resolved.
4. Qualifying repeatable lessons may be written to lessonsDoc before CI.
5. The head is refreshed against its base when safe.
6. Matching local preShipChecks run against the final reviewed diff while the pull request remains held.
7. Marking the pull request ready releases CI.
8. The final head commit must show every applicable check successful; absent, skipped, pending, or stale results are not green.

The draft hold is conditional on review.openPullRequestsAsDraft, review.readyForReviewReleasesCi, and review.ciHeldUntilReviewSettled. When all three are false, the pull request opens ready and CI runs alongside review. Mixed values take the strictest behavior and are reported.

One-off work

/devstride:create-story add a one-time export
/devstride:create-defect retry creates duplicate records

The create skills ask for a parent, board, and assignee, create the item without plan numbering or dependency edges, and invoke build-item <new-item> once. The one-off ships through its own base-branch pull request and terminates instead of selecting another item.

Use insert-story or insert-defect when the new work belongs in an existing plan and should be reached by the dependency walk.

Hotfixes

/devstride:branch-hotfix fix-login-crash

This creates a branch from a fresh hotfixBaseBranch, so the fix does not carry unreleased development work. It does not open a pull request; build the fix, then use /devstride:pr targeting the production branch.

Production release

/devstride:release

This is separate from a release-unit pull request. It promotes release.releaseSource to release.productionBranch:

1. compute the release delta;
2. open or adopt the production pull request;
3. run the configured review roster;
4. run release-only local pre-ship checks, then settle CI;
5. update the configured sibling docs repository by default, unless suppressed;
6. present the exact release, verification, docs outcome, and release.autoDeployOnMerge consequence;
7. wait for explicit owner approval before merging production.

Passing no docs or skip docs suppresses the docs phase. docs only updates documentation for an already-shipped delta without cutting a production release.

Read next

• Configuration Reference — choose the branch, review, verification, and release behavior
• Skill Audit — invoke any delivery component directly
• The Planning Loop — create the graph this loop selects from