Shipyard

Parallel Feature Harness

Build, QC, and ship multiple features in parallel in isolated lanes—full app clones with dedicated ports, databases, and Redis instances. Describe a feature in a sentence, and /ship-feature takes it from implementation to delivery while leaving your own checkout untouched.

PRs base on and target development; a human merges them. The harness never
pushes development — it validates the feature branch, publishes the PR only
after every gate passes, then verifies the deployed result post-merge and opens
follow-up fix PRs until dev is clean.

The harness is project-agnostic: everything stack-specific lives in a
profile (profiles//, scaffolded from profiles/_template — profiles
stay local to each install and are never committed). To run it against your own
repo, see Adopting for your own project.

Setup

Prerequisites

Your app repo must already clone, install, and run locally on its own — the
harness builds on top of it.

Configure — the config files

Everything you set lives in config/:

- config/local.env — machine-local topology (untracked; create the file).
  Set at least PROFILE and SOURCE_REPO; use ${VAR:-…} fills so explicit
  env exports still win:

  Shared defaults (ports, Postgres/Redis endpoints, COMPOSE_FILE) live in the
  tracked config/lanes.env; override them here only if they clash.
- config/secrets.env — credentials (gitignored). Copy the example and fill
  it in:

  Your app's own LLM/API keys stay in your repo's backend/.env — each lane's
  .env is seeded from it with DATABASE_URL / REDIS_URL / UPLOAD_DIR
  rewritten per lane, so isolation holds.

One-time setup

Run from the harness repo root:
install-claude-assets.sh *copies* the skills/agents (it bakes in install-time
paths), so re-run it after editing any source skill/agent…