Onboard your repo to TaskShipyard
Four steps from a connected repository to a shipped feature. 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.
Connect your repository
Install the TaskShipyard GitHub App on your organisation and pick the repositories to watch. It is a full-page redirect: there are no tokens to paste and no webhooks to wire up by hand.
You come straight back to the dashboard’s Integrations tab, which reads the repository and shows the dev-environment setup it detected.
INSTALL GITHUB APP →Checkpoint: The Integrations tab lists your repository as connected.
Add a taskshipyard/ folder
Like a supabase/ folder, a taskshipyard/ folder in your repository tells TaskShipyard how to run and verify your app. It is versioned with your code, so the dev seat is configured by the repo rather than by anything hard-coded on our side.
Copy the template closest to your stack and change the port to match your app.
your-repo/ taskshipyard/ ├── start.sh # how your dev environment boots ├── employeebot.md # your handbook: the stack, and how to test └── architecture.md # written by us on your first run, not by you- start.sh
- Brings your dev environment up: npm run dev, sst dev, a migration and a seed. The primary and 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 counts as done.
- architecture.md
- Nothing to write. TaskShipyard maps your system on the first run and redraws it on every run after, rendered in the dashboard’s Architecture tab.
Checkpoint: A seat can boot your stack from a clean checkout, with nobody configuring it by hand.
Tag an issue with @taskship
Write the issue the way you would for a colleague, then mention @taskship in it or in a comment on it. That issue is the whole brief. There is no chat window and no prompt to engineer.
TaskShipyard boots a dev seat from your taskshipyard/ folder, runs one agent on that one feature, and holds it to your handbook, including screenshots of the running app, captured on the machine for any framework.
the entire trigger @taskshipCheckpoint: A run appears in Shipments, bound to a seat and working your issue.
Open the running app, then merge
The run pushes a branch and opens a pull request whose body is the agent’s own verification write-up: the screenshots it took, the API responses it got, the cloud resources it created and the database rows its feature writes. The same write-up goes back on the issue.
The stack it built against stays up as a preview, so reviewing is clicking through a running app rather than reading a hundred-file diff. Merge or close it like any other pull request. Production deploys stay a human action.
SEE THE FULL PIPELINE →Checkpoint: A reviewed pull request, with the running app that proves it still open in a tab.
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, with headless Chromium against your app’s URL. SST + AWS + Supabase + React is the most battle-tested path, because 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.
- How long does the first run take?
- Connecting the repo and adding the folder is about ten minutes. The run itself depends on the feature. You do not wait at the keyboard for it, because the result arrives as a pull request and a preview link.
Connect the repo, commit the folder, tag an issue. The next thing you read is a pull request.