DevStride's build/ship process — select work, plan it, build it, review it, ship it — used to live entirely in ad-hoc prompting: every developer re-explaining the same steps to Claude Code in slightly different words, with no shared record of what "done right" looks like. The /ds-* skill system turns that proven loop into repeatable, checked-in automation.
This page is the first of four covering the skill system:
/ds-* skill: how you invoke it, its arguments, and what it does./ds-plan and its supporting skills./ds-build-item and its supporting skills.Each /ds-* skill is a checked-in Claude Code skill — a SKILL.md markdown file living at .claude/skills/ds-*/SKILL.md in the devstride repo — for example .claude/skills/ds-build-item/SKILL.md or .claude/skills/ds-plan/SKILL.md. They are checked into the repo alongside the application code, not stored in a personal Claude Code config, and are invoked as slash commands (/ds-build-item, /ds-plan, …) or picked up automatically by name/description. That means:
devstride), so improvements to the automation are visible, diffable, and reviewable./ds-build-item I11024, /ds-plan I10992, or any other /ds-* command invokes the markdown file at that path — Claude Code reads it as an instruction set for the current turn.ds- (short for "DevStride") and invoked as a slash command: /ds-build-item, /ds-plan, /ds-pr, and so on. The prefix signals "this skill knows DevStride's specific conventions" — branch naming, item lanes, the completion ritual — as opposed to a generic Claude Code skill.Before this system, shipping a DevStride story meant re-deriving the same sequence by hand every time: figure out which item to work on, move it to In Progress, branch correctly, build the change, self-review, open a PR, get it through CI, merge, update the item, sync develop, and pick the next item. That sequence is well understood — it just wasn't encoded anywhere. Two developers (or the same developer on two different days) would do it slightly differently, and any lesson learned ("always rebase before merging," "don't merge red CI") lived only in that day's chat transcript.
The /ds-* skills exist to fix that: the select → plan → build → review → ship loop is written down once, versioned, and run the same way every time — by a human directly, or autonomously under /loop.
Every skill that touches DevStride items shares one non-negotiable fact, and it is stated explicitly at the top of each of those skill files — ds-build-item, ds-plan, ds-insert-story, ds-insert-defect, ds-create-story, ds-create-defect, ds-rationalize-gantt, and (as a read-only caveat) ds-comprehend-plan. ds-pr also touches the MCP, but only to link_pull_request a finished PR to its item. Skills that never call the DevStride MCP at all — ds-branch-feature, ds-branch-hotfix, ds-push, ds-ultracode-build, ds-review, ds-pr-review, ds-golden, and ds-golden-build — simply don't mention it, because it doesn't apply to them; they operate on git and local/CI infrastructure instead.
api.devstride.com — the real, live production workspace. There is no draft mode, no sandbox, and no dry-run. When a skill calls create_item, update_item, add_relationship, bulk_update_items, or mark_done, that write lands on the real org's roadmap immediately and is visible to every real user of that org. A lane move, a new Capability, a rewritten item description — none of it is a preview. Treat every MCP write as a real, user-visible action, not a test.This has two direct consequences baked into how the skills are written:
/ds-plan runs an entire interactive discovery loop with the user and will not create a single item until the user has explicitly confirmed the full Capability → Epic → Story shape. /ds-insert-story and /ds-insert-defect are direct, single-item writes, and /ds-insert-defect additionally asks for explicit confirmation before queue-jumping a defect ahead of already-planned work, rather than silently reprioritizing the roadmap. /ds-create-story and /ds-create-defect — the one-off entry points for inbound work that isn't part of a plan — likewise confirm where the item lands (which Module/Capability/Epic, which board) before creating it./ds-build-item moves an item to In Progress, and later to Done, as soon as those transitions happen in the loop — those are real changes to a live item, independent of whether the PR has merged. The MCP cannot exercise branch code, so it has no way to "hold" a write until code ships; the write simply happens.Code changes are different, and deliberately so: they go through normal git branches and pull requests, exactly as they would without any of these skills. A feature branch, a PR, CI, and a human-reviewable diff stand between a code change and develop/master. There is no equivalent safety net on the DevStride-item side — which is exactly why the skills that touch items are the ones with the heaviest confirm-first language.
Some actions go a step further than "this is a live write" and are called out as destructive or hard-to-reverse in their own right:
/ds-rationalize-gantt overwrites a plan's stored dates to backfill a compressed cascade. Doing this correctly requires the Gantt dependency auto-scheduler to be OFF first — and there is no API to flip that setting. It is a manual toggle only the user can make, so the skill stops and asks rather than guessing at the state of a setting it cannot read or set itself./ds-reset-db resets the local database from production. It runs strict pre-flight checks (clean working tree, SOURCE_DB_CONNECTION_STRING set) and has safe-restore-on-failure behavior specifically because "reset the DB" is not an action you want half-applied./ds-golden-push hard-refuses to target production outright — there is no confirmation path that overrides that refusal./ds-branch-hotfix resets the local DB from a fresh copy of master before branching, because a hotfix has to be built against what's actually running, not a stale local state.Most /ds-* skills — and especially the top-level delivery orchestrator, /ds-build-item — are written to run end-to-end without pausing. /ds-build-item in particular is explicitly designed to be driven under /loop: select a story, mark it In Progress, branch, build, review, open a PR, address findings, merge, run the completion ritual, sync develop, and move to the next story — all without a confirmation prompt between steps. /ds-plan is the one major exception to this pattern — see the callout below.
That autonomy is bounded, not unlimited. Every orchestrating skill pauses and asks the user only at a genuine fork:
Everything else proceeds on the skill's own judgment, with every deferral recorded explicitly — in the build plan, the PR body, and project memory — rather than silently dropped.
/ds-plan breaks this pattern on purpose, and says so in its own instructions: it is an interactive, loop-based skill throughout, not a one-shot document generator. Planning — scope boundaries, sequencing tradeoffs, what's V1 versus deferred, which stories are hard gates versus parallel — needs real human judgment at every level of the Capability → Epic → Story hierarchy, not just at a final sign-off. /ds-plan asks qualifying questions in rounds and gets explicit confirmation at each level before going deeper; if the user tries to skip that loop entirely, the skill pushes back once before complying, and only then labels every unconfirmed decision as an explicit assumption. Once the shape is confirmed, /ds-plan does fan out heavy drafting work in parallel — but the judgment calls themselves stay in the conversation with the user, never inside that fan-out.The contrast is the important thing to remember: /ds-build-item is a loop that only stops for genuine forks; /ds-plan is a loop that keeps the human in the room throughout, because the thing it's producing — the shape of the roadmap itself — is exactly the kind of decision this system won't make on your behalf.
/ds-plan <item>./ds-plan for this; go straight to The Planning Loop and run /ds-insert-story or /ds-insert-defect directly. /ds-plan is reserved for building/extending a whole hierarchy./ds-build-item <item|next> (drive it under /loop to walk a whole plan)./ds-create-story or /ds-create-defect. They create the item, place it, assign it to you, and then deliver it through the same build loop once (single-shot, no plan walk). See The Delivery Loop.If you're not sure which situation you're in: if there's no Story yet with an implementation-ready spec and dependency edges, you need the planning loop first. If the Story already exists and just needs to be built, go straight to the delivery loop. If the work isn't tracked at all yet and isn't part of a sequenced plan, the one-off /ds-create-* skills create and ship it in one shot.
/ds-plan and its supporting skills for shaping roadmap work/ds-build-item and its supporting skills for shipping codeds CLI these skills drive under the hoodMaintenance & Codebase Checks
Codebase wiring audits, event-system delivery and topology checks, data cleanup and repair scripts, operational toggles, and historical one-off migrations available via ds script.
Skill Audit
A complete reference of every /ds-* Claude Code skill — how you invoke it, the arguments it accepts, and exactly what it does.