Onboard your repo to TaskShipyard
Four steps from an empty repo to shipped features. It works with any stack — you describe how your dev environment starts in a taskshipyard/ folder, and the agent runs and screenshots it from there.
1. Connect your repository
Install the TaskShipyard GitHub App on your organization and pick the repositories to watch — a full-page redirect, no tokens to paste. You come straight back to the dashboard’s Integrations tab, which reads your repo and shows the dev-environment setup it detected.
2. Add a taskshipyard/ folder
Like a supabase/ folder, a taskshipyard/ folder in your repo tells TaskShipyard how to run and verify your app. It carries how the dev environment boots and the employee handbook the agent works to — versioned with your code, nothing hard-coded on our side. Copy a template for your stack to start.
- start.sh — brings your dev environment up (npm run dev, sst dev, a migration + seed). The primary, most flexible option.
- compose.yaml — for container-native stacks: the seat runs docker compose up -d instead.
- employeebot.md — your handbook: the company, the stack, and above all how you require a feature to be tested before it is done.
- architecture.md (optional) — a short map of your system, rendered in the dashboard.
3. Tag an issue with @taskship
Comment or label a GitHub issue with @taskship. TaskShipyard boots a dev seat from your taskshipyard/ folder, runs the agent on that one feature, and verifies it — including screenshots of the running app, captured on the machine for any framework (Next.js, Vite, Rails, a container — no Storybook required).
4. Open the running app, then merge
The run pushes a branch, opens a pull request whose body is the agent’s own verification write-up, and reports the still-running app as a preview you can click through. Review it like any other pull request. Production deploys stay a human action.
Which stacks work?
Any framework that serves a dev environment: the taskshipyard/ folder defines how it starts (a shell script or docker compose) and the seat screenshots whatever it renders. SST + AWS + Supabase + React is the most battle-tested path — it is the stack TaskShipyard is built on and dogfoods — but it is no longer the only one.
Questions we get asked
- Do I need Docker, or a specific framework?
- No. If your app runs with a shell command (npm run dev, sst dev, a server), a start.sh is enough. If it is container-native, drop in a compose.yaml instead. The seat has Node, Docker, and a browser for screenshots either way.
- How does the agent screenshot my app if it is not React?
- Screenshots are taken from the machine against your running app’s URL with headless Chromium, so any framework works — it only needs to serve a page. No Storybook or per-component setup.
- Where do I put the taskshipyard/ folder?
- At the root of the repository you connected, alongside your code. Copy one of the examples (Next.js, any npm dev server, or Docker Compose) and change the port to match your app.