StellarFirm Coder: tips for your first week

The StellarFirm Coder is the AI Agent Assistant that writes software for you: it works in its own workspace, runs your tests, and shows you the changes before anything is published. This playbook is a practical plan for your first week with the Coder, with the habits that make its pull requests easy to trust.

Day 1: how do I connect my code?#

Connect one small repository with the narrowest token that works. The Coder needs a token from your code host, that token connected in StellarFirm, and a repository to work in.

1. Create a token on GitHub, GitLab, or Bitbucket with only the permissions you need. A fine-grained GitHub token limited to chosen repositories is the narrowest option.
2. Open Integrations in StellarFirm, pick your code host, paste the token, and press Connect.
3. Tell the Coder its repository in your message, or once under Settings, Coders.

The full checklist and a permissions table are in Connect your code. In cloud mode the token is stored encrypted and never shown back, and you should never paste a token into chat. See security.

Coder, look at the open issues on [repository] and tell me which one you would pick up first, and why. Do not change anything.

Day 2: what should my first goal look like?#

Make the first goal small, specific, and ending in a pull request for review. A good goal names the outcome, the place, what done looks like, the limits, and what to report.

The CEO prompt guide has a checklist for writing goals. If you leave something out, the Coder asks before it starts.

Coder, on [repository], fix [one small problem]. Keep the change small, run the checks, and open a pull request for review. Tell me what you changed and what I should check.

Day 3: how do I read what the Coder did?#

Open the job in Jobs and read the actual diff and the commands it ran. This is the habit that matters most, because you approve the risky step on the strength of that diff.

• Chat shows short updates and a final report.
• Jobs shows each job, with the Coder's changes when you expand it.
• Computer shows the assistant's own computer, including its terminal, read only.

When the Coder reaches the push, the request appears in Approvals. Approve carries out that one step. Reject cancels it, and nothing is sent. See approvals.

Coder, explain the change you just made on [repository] in plain words: what it does, which files it touches, what you tested, and what could go wrong.

Day 4: how do I set house rules?#

Write a few short, checkable rules in your company brief. House rules are the rules in your brief plus what you allow without asking, and they decide what the Coder does after the work.

The merge policy has three options: review only (the default), merge after CEO approval, and auto merge on green. Start with review only and move on once you have read a handful of diffs. See house rules.

CEO, help me write house rules for how the Coder works on [repository]. Ask me up to five questions about pull requests, tests, and releases, then draft the rules as a short list.

Day 5: what other jobs can the Coder do?#

The Coder does more than write features. It reviews pull requests, fixes failing checks, writes tests, plans a test strategy, and refactors without changing behavior.

The Coder page lists every skill and integration.

Coder, review pull request #[number] on [repository]. Summarize what it changes, point out risks and missing tests, and say whether you would approve it. Do not change the code.

Coder, the checks on [pull request or branch] in [repository] are failing. Find the cause first, fix it in the smallest change, and tell me what was wrong.

Weekend: how do I scale up safely?#

Add more work in small steps, and keep goals small. Several small pull requests are easier to review than one huge one, and they use fewer credits. Each answer shows the model used and the credits it cost, and Usage shows spend by assistant and job. See how credits work.

You can run more than one Coder, each with its own name, focus, repository, and login, for example a UI Coder and an API Coder. Each works in its own private workspace, so they do not collide.

Good habits to keep:

• Name the repository every time, or set it per Coder.
• State when to stop: "open a pull request for review".
• The Coder works on its own branch, never force-pushes, and your host's branch protection still applies.
• If the Coder asks a question, answer in one line.

For a view of the wider picture, read what is an AI agent assistant and approval workflows for AI agents.