DevStride for Claude Code

The devstride Claude Code plugin turns a DevStride roadmap into a delivery loop: plan the work, select the next unblocked item, branch, build, review, merge, update the item, and continue.

To understand why the loop is shaped this way before learning the commands, read The Idea Behind the Loop.

Version 3.9.0 ships twenty skills. The source and release history live in devstride/claude-plugin.

Each skill states its goal, the rules that must hold while it works, and the hard floors that no profile, override or shortcut removes — rather than a numbered script to follow line by line. That is how every loop skill reads from 3.6.0; what each one guarantees did not change.

The model in one minute

The skills use three roles instead of assuming your work-type names:

• A leaf is an executable item, such as a Story or Defect, sized by the delivery profile.
• A release unit is the parent item whose completion produces a release pull request, usually an Epic.
• A grouping item is any parent level above those, such as a Capability, Module, or Solution.

/devstride:setup maps your organization’s real work types to those roles and records repository-specific settings in .claude/ds-config.json.

When an item gets a pull request

The distinction matters: a one-off never uses a release unit's branch, even when it was filed under one — the create skills allow that — so its path is never inferred from ancestry. The train exists because every merge into the base branch runs paid CI and often a deploy; batching one-offs gives them one full review and one CI pass per release, as an epic's release pull request does. Deploy configuration and migrations stay off it because the train reaches production soon after it merges; they deserve their own pull request and an earlier deploy to a development stage. Which branch an item lands on is decided by one runnable helper, skills/build-item/scripts/routing.py — see Where work lands.

Review first, CI last — when your repo supports it

In the shipped draft-hold configuration, pull requests open as drafts. Local and cloud reviewers settle first; marking the pull request ready releases CI on the final reviewed diff. A per-use cloud reviewer can be limited to pull requests into chosen branches (baseBranches) and asked only once, at the final reviewed head (requestPolicy: "final-head") — the DevStride repository requests Copilot only on pull requests into master, because it is billed per review.

That ordering depends on your GitHub Actions workflows listening for ready_for_review and declining to run their gated jobs while the pull request is a draft. Repositories that configure all three draft-hold settings as false intentionally run CI alongside review instead. /devstride:setup detects the current shape, and /devstride:doctor reports mismatches without editing a workflow.

Choose a delivery profile

One setting decides how much rigor the loop spends on each item: how finely a plan is sliced, how deep each spec goes, how wide the adversarial review fans out, how many local review rounds run, and which local checks gate a merge. Those knobs are coupled — coarse items with a wide review fan-out cost more than fine items would — so you pick one word and they move together.

• prototype — a small team validating an idea, with no production users yet, where a small error is cheap.
• standard — the default for a working product; the middle ground.
• extended — a working product built as fewer, larger items. It buys size, not lower rigor: only the size-shaped knobs move — leaf size, spec depth, how many readers the build engine fans out, and how wide the merge review may go. Every safety knob and every floor is exactly standard’s.
• enterprise — regulated, revenue-bearing, or shared-platform code, where a missed defect is expensive.

From finest to coarsest leaf size the order is enterprise, standard, prototype, extended.

A configured local CLI reviewer runs at merge boundaries — a direct pull request or a release pull request — and never on a fast-merged item that has no pull request, under any profile. The rounds above are its budget within the normal cycle target.

Some floors hold under every profile, and no override removes them:

• Every item gets a bounded self-check and a green local gate before it merges.
• Changes to authentication, migrations, irreversible state, or deployed contracts get immediate focused verification, even on a fast-merged item. A security finding is always verified by its own agent, never batched with others.
• Full adversarial review runs at the merge boundary rather than twice per item: a direct item pull request is a boundary, and otherwise the release pull request reviews the batched full diff with every configured engine before CI.
• Two adversarial cycles is the normal target, not a safety cap. After it, a verified P1 — or a serious P2, meaning likely to occur and material if it does — opens another cycle, and that repeats until a cycle finds none. No numeric target can stop those safety cycles.
• Every follow-up reviewer receives the cumulative ledger of prior findings, verdicts, dispositions and fixes, so settled findings are not rediscovered or reversed.
• Review comes first and CI last, on the final reviewed diff, in every repository whose workflows support the draft hold.

Set the profile once with /devstride:setup, which asks for it and writes "profile" plus matching defaults into .claude/ds-config.json, or add the key by hand. A plan can carry its own choice: /devstride:plan I1234 prototype writes a Delivery profile: marker line into the root item’s description, and that marker wins over the repository’s profile setting for everything under it. With no profile anywhere, the loop runs standard. /devstride:doctor reports the effective profile, where it came from, and any config key that contradicts it.

One item, end to end: a worked example

Suppose your DevStride organization has a Capability I2000 — Webhook intake, your repository is set up, and the plugin is connected. The loop looks like this.

1. Plan. You run /devstride:plan I2000 standard. The skill reads what already sits under I2000, then asks: what source material exists, what is in and out of scope, where the release boundaries fall, what must ship first. You answer that signature verification must land before any retry logic. It shows a proposed hierarchy and creates nothing until you approve it:

I2000  Capability  Webhook intake
└─ I2010  Epic   Verified intake                    ← one release unit
   ├─ I2011  Story  [1] Verify webhook signatures
   ├─ I2012  Story  [2] Persist accepted payloads
   └─ I2013  Story  [3] Retry failed deliveries     (blocked by [1] and [2])

Every Story has blocked_by/blocks links, dates cascade from them, and the root's description carries Delivery profile: standard. You /clear, because planning and building are different job classes and the session gate keeps them apart.

2. Build the first item. You run /devstride:build-item. It fetches origin, selects I2011 as the only unblocked leaf, moves it to In Progress, and cuts the Epic's integration branch (jane/26-10-06/epic-I2010-verified-intake) off your base branch, then I2011's own branch off that. ultracode-build reads the spec against the real code, implements it in small green commits, and runs the risk check — the diff touches an authentication boundary, so the security verifier is forced. Your configured local gate runs. With fast merges on, the Story merges onto the Epic branch with no pull request of its own; the item moves to Review with a comment naming the merge commit and what actually shipped. It becomes Done when the Epic's release pull request merges. The handoff ends with two lists: what the loop did, and what you must do (nothing, this time).

3. Keep walking. /loop /devstride:build-item repeats that for I2012, then I2013 once both blockers have merged onto the Epic's branch. Along the way a reviewer notes a logging gap that is unlikely to matter; it is dismissed with a one-line reason in the merge commit, and nothing is filed. Had it been worth filing (a P1, a security finding, or one both likely to happen and material) and deliberately put off, it would have been filed as a Defect in the plan's Deferred defects container, related to I2013, outside the chain. When I2013 lands the Epic has zero remaining leaves. Under standard, autoRelease is false, so the loop stops and reports the Epic release-ready instead of cutting anything.

4. Release the unit. You say yes (or run /devstride:build-item I2010 and approve the cut). The loop merges the base branch into the Epic branch, opens the Epic's release pull request as a draft, and runs the full review over the whole Epic diff — Claude's adversarial pass plus whatever review.localCommand and review.automatedReviewers you configured — because this is the first time any reviewer outside the build has seen that code. Findings are verified, fixed or dismissed with a reason, threads resolved. Then the pull request is marked ready, CI runs once on that final head, and it merges. The Epic branch is deleted.

5. Promote to production. When you want it live, /devstride:release cuts release/26-10-06 from your release source (if release.releaseBranchPattern is set), opens the production pull request, runs the same full review and the release-only pre-ship checks, settles CI, and then stops with a summary that quotes your release.autoDeployOnMerge text. Nothing merges until you answer yes. After the merge it waits for the deploy to be confirmed, runs your post-deploy health skill if you registered one, updates your documentation through your local docs skill, and writes a release note only if you passed --release-notes.

That is the whole loop: one planning conversation, one command repeated per item, one owner decision per release unit, one per production release.

Two important safety boundaries

Planning therefore asks for sign-off before creating a hierarchy. rationalize-gantt separately confirms scope because it overwrites stored dates and may remove or repoint dependency edges.

Code changes keep the normal git safety net: branches, diffs, review, tests, and merge history.

Pick the right entry point

Read next

• Getting the Skills — install, connect, set up, and run your first item
• Guided Setup — what /devstride:setup reads, writes, and validates
• The Planning Loop — shape a buildable roadmap
• The Delivery Loop — understand item, release-unit, and production paths
• Skill Audit — all twenty commands at a glance
• Configuration Reference — every supported setting