Getting the Skills

This is the only page you need for a first run. The rest of the section explains the loop in more depth.

1. Install

From the root of the repository you will use it in, run:

claude plugin marketplace add devstride/claude-plugin
claude plugin install devstride@devstride --scope project

Confirm the install and version:

claude plugin list

The current published version is 3.9.0, with twenty /devstride:* skills. The DevStride repository requires 3.9.0 or newer: an older plugin silently ignores the configuration keys it does not know, so the protections they turn on are simply absent.

2. Connect DevStride

Run:

/mcp

Connect plugin:devstride:devstride, sign in, and choose the organization the skills should use.

Until you connect, the server contributes no DevStride tools and nothing prompts you. The usual symptom is “I can’t find DevStride tools,” not an authentication error.

Keep only one DevStride MCP server signed in. A plain devstride entry is a separately configured server, not the bundled one; two active servers can point the skills at different organizations. To switch the bundled connection to another organization:

claude mcp logout plugin:devstride:devstride

Then reconnect through /mcp.

3. Set up your repository

Open Claude Code in the repository and run:

/devstride:setup

Setup detects your branches, package manager, verify commands, CI shape, conventions file, and available review engines. It asks about anything it cannot prove, maps your DevStride work types to the release-unit and leaf roles, then writes and validates:

.claude/ds-config.json

Setup also offers two things outside that file, each only when you accept it: the local documentation skills it scaffolds, and a repository status line (.claude/statusline.sh plus a statusLine entry in .claude/settings.json). It never edits application code, CLAUDE.md, or .gitignore, and it touches CI workflows only in /devstride:setup ci, as a diff you review.

Next run the broader read-only check:

/devstride:doctor

Doctor checks the plugin, DevStride connection, git and GitHub CLI access, config, CI draft gate, and merge gates. Diagnosis is read-only. It then offers, as one batch, the repairs that are safe to automate — writing inside this repository's .claude/, or running the command that already owns a fix, such as gh auth login or /devstride:setup — and re-verifies each one. It never repairs a workflow file, git state, a DevStride record, or anything on a deployed stage, and it repairs nothing when it is not run interactively.

4. Plan, then build once

Plan under an existing DevStride parent item:

/devstride:plan I1234

The plan skill reads what already exists, asks about scope and sequencing, shows you the proposed hierarchy, and creates nothing until you approve it.

Then deliver one item:

/devstride:build-item

Start with one. Once the branch, review, test, merge, and item-update behavior matches your expectations, walk the remaining plan with:

/loop /devstride:build-item

/loop belongs to Claude Code, not this plugin. It repeatedly invokes build-item; the delivery skill itself remains serial and selects one item at a time.

Delivery prerequisites

Planning needs the DevStride connection. Code delivery additionally assumes:

• git, with a pushable remote named origin;
• GitHub as the forge;
• GitHub Actions for the plugin’s draft-held CI ordering;
• an installed and authenticated gh CLI with repository write access.

Other forges can still use the planning skills, but the branch, pull-request, review-thread, and merge flow has no adapter for them. /devstride:setup and /devstride:doctor check these prerequisites before your first real delivery.

Optional: make CI run after review

The shipped review settings use draft pull requests so reviewers settle before CI starts. To use that ordering, each workflow triggered by pull_request needs all four events:

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

Gate the jobs, or an upstream job they depend on, while the pull request is a draft:

jobs:
  test:
    if: github.event.pull_request.draft == false
    # ...

Setup detects this shape but does not edit it. Doctor tells you which event or job gate is missing. If your repository intentionally runs CI during review, set all three review ordering flags to false; mixed values use the strictest behavior and are reported.

The ds install alias

The marketplace also offers a shorter install spelling:

claude plugin install ds@devstride --scope project

It changes only the install identifier. The plugin manifest is still named devstride, so commands remain /devstride:plan, /devstride:build-item, and so on — never /ds:plan.

Install either devstride@devstride or ds@devstride, not both. The two marketplace entries point to the same source, but Claude Code installs them separately; installing both puts every skill in the picker twice. Updates must use the identifier you installed.

Staying in sync

The plugin releases often, and a session serves whatever it loaded at startup. Three commands keep you current, and all three are safe to run as often as you like — they are read-only until you accept something:

A good habit is /devstride:doctor at the start of a working session and again after editing config — it is the one command that checks everything at once, and it costs nothing to run when all is well.

Let Claude Code update the plugin for you

The least effort is to stop updating by hand. Claude Code can refresh a marketplace and update its installed plugins in the background:

1. Run /plugin
2. Go to Marketplaces
3. Choose the devstride marketplace
4. Select Enable auto-update

Claude Code checks after your session starts, with a random delay of up to ten minutes, so the running session keeps the versions it launched with. If anything updated you are prompted to run /reload-plugins; otherwise the new version loads at your next launch.

Administrators can enable it for everyone instead of asking each person to toggle it, by setting "autoUpdate": true on the marketplace's entry in managed settings:

{
  "extraKnownMarketplaces": {
    "devstride": {
      "source": { "source": "github", "repo": "devstride/claude-plugin" },
      "autoUpdate": true
    }
  }
}

To turn automatic updates off again, use the same menu, or set the DISABLE_AUTOUPDATER environment variable. That variable also disables Claude Code's own updates; to keep plugin updates while stopping those, set FORCE_AUTOUPDATE_PLUGINS=1 alongside it.

Updating by hand

/devstride:update is the simplest path from version 3.5.1 onward. It updates the exact installation that loaded the command — preserving whether you installed as devstride or ds, and at user or project scope — verifies the installed files against the published tag, and tells you whether /reload-plugins is enough or Claude Code needs a restart. It stops rather than guessing when an install is pinned, administrator-managed, or ambiguous. On 3.1.0 through 3.5.0 the skill exists but can stop with plugin-root-missing on current Claude Code; use the two commands below once to get past it.

The plugin also checks for a newer release at every session start and tells you when you are behind — silently when you are current or offline. A repository can have it apply the update at session start (plugin.autoUpdate in .claude/ds-config.json; setup writes it true, and the check treats an absent block as false) or hold a version deliberately (plugin.pin). That automatic path only ever updates an install scoped to that repository; a shared user-scope copy is handed to /devstride:update, and an administrator-managed one is left alone. See the configuration reference for the block.

The two-command form still works, and is what an installation older than 3.1.0 needs, because /devstride:update does not exist there — and the fallback for 3.1.0–3.5.0 when the skill stops:

claude plugin marketplace update devstride
claude plugin update devstride@devstride --scope <scope>

For an alias install, the second command is:

claude plugin update ds@devstride --scope <scope>

Use the scope claude plugin list shows for your install: project for the recommended install, user for an older machine-wide one. Without the right scope, claude plugin update reports the plugin as not installed and changes nothing.

Running only marketplace update refreshes the catalog but leaves the installed plugin unchanged. claude plugin list is the final check — though note it reads what is on disk, while the session-start check reports what your session actually loaded, which is the drift that matters.

Team installation

A repository can declare and enable the marketplace in .claude/settings.json:

{
  "extraKnownMarketplaces": {
    "devstride": { "source": { "source": "github", "repo": "devstride/claude-plugin" } }
  },
  "enabledPlugins": { "devstride@devstride": true }
}

That does not install the plugin: each teammate runs claude plugin install devstride@devstride --scope project once, from the repository. (In the DevStride repository, ./setup does this for them.) Make sure .claude/settings.json and .claude/ds-config.json are tracked if your repository normally ignores .claude/.

For headless API-key setup, release pinning, and marketplace removal behavior, use the plugin’s README. Those are operational exceptions, not first-run steps.

Read next

• Guided Setup — what setup detects, asks, writes, and validates
• The Planning Loop — turn an initiative into executable work
• The Delivery Loop — understand the item and release paths
• Configuration Reference — customize the repository contract