Agentic Skills

DevStride for Claude Code

Install the DevStride Claude Code plugin, plan a roadmap, and deliver it one item at a time through build, review, and release.

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.

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

The model in one minute

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

  • A leaf is an executable, roughly one-day item, such as a Story or Defect.
  • 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

Item pathWhat happens
Planned leaf on a release-unit branch, fast merges enabledLocal review and local checks, then a local merge. No item pull request. Cloud review and CI run on the completed release unit.
Planned leaf on a release-unit branch, fast merges disabledThe item gets a pull request into the release-unit branch.
Planned leaf with release-unit branches disabled or no release-unit ancestorThe item gets a pull request into the repository’s base branch.
One-off created with create-story or create-defectThe item always gets its own pull request into the base branch, even if it was filed under a release unit.

The distinction matters: a one-off uses an explicit base-branch bypass. It is not safe to infer that one-offs have no release-unit ancestor, because the create skills allow them to be filed under one.

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.

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.

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

GoalCommand
Check the installation and repository/devstride:doctor
Understand an existing plan without changing it/devstride:comprehend-plan I1234
Create or extend a roadmap/devstride:plan I1234
Add one item to an existing plan/devstride:insert-story ... or /devstride:insert-defect ...
Deliver the next planned item/devstride:build-item
Create and deliver unplanned work once/devstride:create-story ... or /devstride:create-defect ...
Promote the release source to production/devstride:release