> ## Documentation Index
> Fetch the complete documentation index at: https://kowshik-93.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Quickstart

> From npx install to your first opened pull request.

## 1. Install into your repo

Run this inside the repo you want shipflow to work in:

```bash theme={null}
npx shipflow-skills init
```

This installs the 11 skills into **both** `.claude/skills/` and `.github/skills/` (Claude Code and
Copilot don't share a skills directory — see [Installation](/shipflow/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.

<Tip>
  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.
</Tip>

## 2. Edit `shipflow.config.md`

This file is the single source every skill reads first. At minimum, set:

```yaml theme={null}
requirements:
  provider: ado   # or: jira

code_host:
  host: github    # or: azure_repos
```

See [Configuration](/shipflow/configuration/overview) 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](/shipflow/configuration/mcp-setup) for the exact fields and the Claude-vs-Copilot
file/key difference.

## 4. (Optional but recommended) Set up standing context

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](/shipflow/configuration/product-context).

## 5. Run it

In Claude Code or Copilot chat:

```
/shipflow AB#1234
```

<Info>
  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.
</Info>

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:

```
/feature-context PLAT-567
/feature-verify AB#1234
```

## Multiple repos?

If the work item might touch more than one repo, see [Polyrepo](/shipflow/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).