# StellarFirm Coder: tips for your first week

> Get more from the StellarFirm Coder in week one: connect your code, write small goals, set house rules, read the diff, and copy-ready prompts.

By StellarFirm team. Published 2026-10-24. 5 min read.

Keywords: stellarfirm coder, ai coding assistant, ai pull requests, house rules, code review
Tools covered: StellarFirm

## Key takeaways

- Connect one small repository with a narrow token, then give the Coder one small goal that ends in a pull request for review.
- Read the diff in Jobs before you approve the push, and start with the review only merge policy.
- Write short, checkable house rules in your company brief, and widen them only after you have read a handful of diffs.
- Vague goals get questions, and that saves you a wrong turn.

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](/docs/getting-started/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](/docs/trust/security).

```prompt title="Read-only test"
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.

| Weak goal | Strong goal |
| --- | --- |
| "Fix the login." | "Coder, on [repository], users cannot log in with a plus sign in their email. Fix it in the smallest change, add a test, and open a pull request for review." |
| "Make the site faster." | "Coder, the home page loads slowly. Find the biggest cause, fix only that, and tell me what you measured before and after." |

The [CEO prompt guide](/docs/ceo/prompt-guide) has a checklist for writing goals. If you leave something out, the Coder asks before it starts.

```prompt title="Your first real goal"
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](/docs/ceo/approvals).

```prompt title="Explain your change"
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.

| Area | Example rule |
| --- | --- |
| Review | Open every pull request for review. Do not ship anything without my approval. |
| Size | Keep each pull request to one clear change. |
| Tests | Run the tests before opening a pull request, and say what you ran. |
| Safe areas | Never touch billing or authentication without asking me first. |
| Reports | End every job with what changed, what to check, and what is left. |

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](/docs/ceo/house-rules).

```prompt title="Draft my 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.

| Say something like | What happens |
| --- | --- |
| "Review PR #14" | It reads the pull request and its checks and posts a summary. It only reads. |
| "Fix the failing CI on PR #14" | It reads the failing check and fixes it in the smallest change. |
| "Write tests for [module]" | It adds tests, including a regression test. |

The [Coder page](/docs/personas/coder) lists every skill and integration.

```prompt title="Review a pull request"
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.
```

```prompt title="Fix a failing check"
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](/docs/credits/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](/blog/what-is-an-ai-agent-assistant) and [approval workflows for AI agents](/blog/approval-workflows-for-ai-agents).

## Frequently asked questions

### What does the StellarFirm Coder do first?

It clones your repository into its own private workspace, works with a terminal and a browser, runs the project's tests, and shows you the exact changes. By default the first outcome is a draft pull request, and the push waits for your Approve.

### Can the Coder merge or ship on its own?

Only if your house rules allow it. The merge policy is review only by default. Steps that reach other people, such as opening a pull request, always ask today.

### Which repository should I start with?

A small or test repository, with a token limited to chosen repositories. You can create a wider token later.

### How do I keep the Coder focused?

Name the repository, ask for one clear change, say when to stop, and say what to report. Keep each pull request small enough to read in minutes.

## Sources

- [StellarFirm docs: The Coder](https://stellarfirm.ai/docs/personas/coder)
- [StellarFirm docs: Connect your code](https://stellarfirm.ai/docs/getting-started/connect-your-code)

---

Source: https://stellarfirm.ai/blog/stellarfirm-coder-first-week