Skip to main content

​
1. Install into your repo

Run this inside the repo you want shipflow to work in:
This installs the 11 skills into both .claude/skills/ and .github/skills/ (Claude Code and Copilot don’t share a skills directory — see Installation for why), seeds a working shipflow.config.md, seeds .mcp.json + .vscode/mcp.json from ready-to-edit examples, and copies the templates the skills render into.
Already have skills installed elsewhere and just want the config/MCP scaffolding? init is additive and non-destructive — it never overwrites a shipflow.config.md, .mcp.json, or .vscode/mcp.json that already exists.

​
2. Edit shipflow.config.md

This file is the single source every skill reads first. At minimum, set:
See Configuration for every field — provider IDs, branch/commit conventions, linking, tests, and the governance gates.

​
3. Connect your MCP server

init already seeded .mcp.json (Claude Code) and .vscode/mcp.json (Copilot) with placeholder entries for Azure DevOps and Atlassian/Jira. Fill in whichever your provider needs — see Connecting MCP servers for the exact fields and the Claude-vs-Copilot file/key difference. Run /product-context once to create product.md — a short “constitution” (domain glossary, architecture boundaries, house-rule conventions, non-negotiables) that every phase reads afterward, so no single work item has to restate your team’s context. See Product Context.

​
5. Run it

In Claude Code or Copilot chat:
The orchestrator stops at gated points (after context, after plan, after verify) and waits for your approval before continuing — nothing pushes, opens a PR, or touches the work item’s tracker state without you saying so.
You’ll see, in order: a normalized requirement + acceptance criteria to confirm, a plan + task breakdown to approve, then implementation and tests happen automatically, then an AC-by-AC verify report, and finally a linked, opened pull request. Only need one phase? Every phase is also a standalone skill:

​
Multiple repos?

If the work item might touch more than one repo, see Polyrepo before your first run — it changes how you fill in repos: in the config and what “done” looks like (one PR per touched repo instead of one).