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

In Claude Code, run:

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

Confirm the install and version:

claude plugin list

The current published version is 0.9.0, with seventeen /devstride:* skills.

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

That is setup’s only write target. It does not edit application code, CLAUDE.md, .gitignore, or CI workflows.

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. It reports fixes; it never applies them.

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:

/plugin install ds@devstride

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.

Updates

Unless you enable marketplace auto-update in /plugin, update with both commands and restart Claude Code:

claude plugin marketplace update devstride
claude plugin update devstride@devstride

For an alias install, the second command is:

claude plugin update ds@devstride

Running only marketplace update refreshes the catalog but leaves the installed plugin unchanged. claude plugin list is the final check.

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 still runs the install command once. 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