> ## 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.

# Skills overview

> 11 skills — one orchestrator, one standing-context skill, a preflight check, 6 phases, a repair loop, and a status view.

Every skill below is a self-contained `SKILL.md` — invokable on its own (`/feature-verify AB#1234`)
or run in sequence by the orchestrator (`/shipflow AB#1234`). These pages summarize what each does;
the installed `SKILL.md` itself is the canonical, complete source your host actually reads.

<CardGroup cols={2}>
  <Card title="shipflow" icon="diagram-project" href="/shipflow/skills/shipflow">
    Orchestrator. Runs the phases in order, holds state, stops at gates.
  </Card>

  <Card title="product-context" icon="book" href="/shipflow/skills/product-context">
    Creates/maintains `product.md`, the standing team context.
  </Card>

  <Card title="feature-preflight" icon="stethoscope" href="/shipflow/skills/feature-preflight">
    Phase 0 — environment readiness (config, MCP, CLI auth, clean tree). Read-only.
  </Card>

  <Card title="feature-context" icon="magnifying-glass" href="/shipflow/skills/feature-context">
    Phase 1 — reads the work item, normalizes acceptance criteria. Read-only.
  </Card>

  <Card title="feature-plan" icon="map" href="/shipflow/skills/feature-plan">
    Phase 2 — a plan + task list grounded in your actual code.
  </Card>

  <Card title="feature-implement" icon="code" href="/shipflow/skills/feature-implement">
    Phase 3 — branch + conventional commits, task by task.
  </Card>

  <Card title="feature-tests" icon="flask" href="/shipflow/skills/feature-tests">
    Phase 4 — a test per acceptance criterion, run until green.
  </Card>

  <Card title="feature-verify" icon="clipboard-check" href="/shipflow/skills/feature-verify">
    Phase 5 — AC-by-AC gap report. Read-only; gates the PR.
  </Card>

  <Card title="feature-repair" icon="wrench" href="/shipflow/skills/feature-repair">
    Phase 5.5 — scoped fix loop for a NOT READY verdict. No full re-plan.
  </Card>

  <Card title="feature-pr" icon="git-pull-request" href="/shipflow/skills/feature-pr">
    Phase 6 — pushes and opens the linked PR(s). Never merges.
  </Card>

  <Card title="feature-status" icon="list-check" href="/shipflow/skills/feature-status">
    Read-only status/resume view. Invocable any time; never advances the flow.
  </Card>
</CardGroup>

## Side effects at a glance

| Skill               | Side effects                                         |
| ------------------- | ---------------------------------------------------- |
| `shipflow`          | coordinates the rest                                 |
| `product-context`   | writes one doc (`product.md`)                        |
| `feature-preflight` | read-only                                            |
| `feature-context`   | read-only                                            |
| `feature-plan`      | writes plan files (`plan.md`, `tasks.md`)            |
| `feature-implement` | branch + commits                                     |
| `feature-tests`     | commits                                              |
| `feature-verify`    | read-only                                            |
| `feature-repair`    | branch + commits (only when invoked after NOT READY) |
| `feature-pr`        | push + open PR                                       |
| `feature-status`    | read-only                                            |

## The governance gates

Three phases pause for human approval by default (`shipflow.config.md` → `governance.gates`):
after context, after plan, after verify. Pushing, opening a PR, and updating the work item's
tracker state are **never** autonomous, regardless of gate settings — see
[Governance & gates](/shipflow/reference/governance) for the full model.