Startup

A startup wins by shipping quickly without breaking the product. This playbook lets the Coder move fast on staging, while production stays behind your Approve.

Who this is for#

Your assistants#

Suggested house rules#

House rules
1. The Coder works on its own branch and opens a pull request for every change.
2. If all checks pass and the change touches only [areas, such as docs, copy, or tests], the Coder may merge to [staging branch] and tells me afterwards.
3. Changes to [payments, sign-in, database changes, or infrastructure] are opened as pull requests for a teammate to review. A person merges them after review.
4. A deploy to production always waits for my Approve, with a summary of what is in it.
5. If a check fails twice, the Coder stops and asks instead of trying a third time.
6. Every bug fix includes a regression test.

Preflight#

• Sign in at https://stellarfirm.ai/app with your invitation.
• Connect your source host on Integrations.
• Make sure your repository has checks that run on every pull request. If not, make "set up CI" your first goal.
• Name the staging branch, and say who reviews what.
• Write your house rules in the company brief.

Launch: Day 1#

1. Check the safety net. Ask the Coder how healthy your checks are.

Coder, look at the checks on [repository]. Tell me what runs on each pull request, how long it takes, what is missing, and what is flaky.

2. Run a first ticket.

Coder, pick up the top open ticket on [repository]. Build it, run the checks, and open a pull request. Follow our house rules for what happens next.

3. Watch it in Jobs. Read the commands and the diff in Jobs.
4. Approve the risky step in Approvals.
5. Have a teammate review the first pull request like any other.

First week#

Coder, on [repository], build this ticket: [title]. Acceptance criteria: [list]. Add tests that prove each criterion and open a pull request.

Coder, the pipeline on [branch or pull request] in [repository] is red. Find the cause, fix it in the smallest change, and explain what went wrong.

Coder, [test name] on [repository] fails now and then. Find out why, fix the cause, and do not just add a retry.

Coder, list what is on [staging branch] but not yet in production on [repository]. Group it by risk and tell me what I should check before I approve a deploy.

Coder, review pull request #[number] on [repository]. Summarize it, flag risks and missing tests, and say what you would ask the author.

Coder, make the checks on [repository] faster without making them weaker. Show me the before and after times in the pull request.

Steady orbit#

• Every ticket. Name the Coder, the repository, and where to stop.
• Every day. Clear Approvals, then read the staging summary.
• Before each production deploy. Ask for the release summary, then approve with the summary in hand.
• Every sprint. Add a second Coder for a second area, for example UI and API, each with its own focus.
• Every month. Widen or narrow what the Coder may merge, based on how the last month went.

Coder, look at the pull requests you opened on [repository] this sprint. Which needed changes, why, and what should we change in our house rules?

Coming soon for your company#

• Product owner: keeps the backlog in shape so the top ticket is always buildable.
• Marketing: turns each release into a changelog entry.
• Accountant and Legal: keep the books and the policies tidy as you grow.

Pitfalls#

• Merging without checks. Letting the Coder merge only makes sense with checks that mean something. Fix CI first.
• Production by default. Keep production deploys behind Approve until you have a long track record.
• One giant Coder. Add a second Coder with its own focus before one Coder becomes a bottleneck.
• Unclear tickets. A ticket with no acceptance criteria gets a guess. Add criteria, or ask the Coder to propose them first.
• Not reading summaries. The Approve card is only useful if you read what it says.