How autonomous development works at TaskShipyard

1. Tag an issue with @taskship

Install the GitHub App on the repositories you want covered, then mention @taskship in an issue or in a comment on one. TaskShipyard creates a run for that issue and queues it against your tenant. Tagging the same issue twice does not start a second run.

2. A workstation picks the run up

A workstation is a machine TaskShipyard runs for one tenant, a numbered slot that owns a cloud stage. It claims the run, binds to your tenant, clones the repository onto a branch named after the issue, installs dependencies, resets a local database from your migrations and starts the dev servers.

If no machine is warm, the fleet starts one; if a workstation already serves your tenant, it takes the work so the checkout stays warm.

3. The agent works one feature

One run, one feature. The agent has the issue, the repository, the running stack, a browser it can screenshot, and scoped cloud credentials. It commits as it goes.

4. It has to prove the work

A run is not finished when the code compiles. The agent has to show a screenshot of every screen it touched, real API responses including the failure cases, the cloud resources it created, and the database rows its feature writes, and the repository’s typecheck and tests have to pass.

5. Pull requests and AI agent preview environments

The run pushes the branch, opens a pull request whose body is the agent’s own summary and verification write-up, posts that write-up back on the issue, and reports the still-running stack as an AI agent preview environment. You click through the live app, then merge or close it like any other pull request.

Limits worth knowing today

You bring the stack: a taskshipyard/ folder tells the agent how to run and verify your app, so any framework that serves a dev environment works (a start.sh or a docker compose). SST + AWS + React + Supabase is the most battle-tested path: the stack TaskShipyard is built on and dogfoods. One issue becomes one run. Production deploys stay a human action.

Questions we get asked

Does TaskShipyard run inside my own AWS account?

The machines do not. A workstation is TaskShipyard infrastructure, bound to one tenant and never shared. What does run in your account is the cloud stage the agent deploys, through an IAM role you grant with an external id, using dev-scoped credentials that expire in an hour.

Which repositories can TaskShipyard see?

Only the ones you grant the GitHub App, and a run only ever holds a token for the single repository it is working in.

What happens if a run runs out of budget mid-feature?

It pauses and resumes on the same branch rather than failing. The pull request keeps its history.

Can I trigger a run without an issue?

Yes. The dashboard can start one directly, but the issue remains the best place to describe the work.