# The Coder

> The Coder turns your goals into tested code changes in its own workspace, then ships them as far as your house rules allow, with Approve on risky steps.

The Coder is the StellarFirm assistant that writes software. You give it a goal or a ticket, it works in a private workspace with a terminal and a browser, runs the tests, and shows you the exact changes. What happens next depends on your [house rules](/docs/ceo/house-rules): it can open a pull request for you to review, or merge and ship when your house rules allow it. Risky steps wait for your Approve.

> [!NOTE]
> The Coder is available now. It is the one persona open at launch.

## Mission brief

| | |
| --- | --- |
| Status | Available |
| Best at | Features, bug fixes, failing checks, tests, refactors, pull request reviews |
| Works with | GitHub, GitLab, Bitbucket |
| Works in | Its own private workspace (files, terminal, browser) |
| You watch it in | [Jobs](https://stellarfirm.ai/app/jobs) and [Computer](https://stellarfirm.ai/app/computer) |
| You approve in | [Approvals](https://stellarfirm.ai/app/approvals) |

## How it works

1. **You set a goal.** Write it in chat: "Fix the login redirect" or "Pick up the top ticket on [repository]".
2. **The CEO briefs the Coder.** The CEO assistant routes the goal and passes along the details, such as the repository and the issue. If something is vague, the Coder asks before it starts.
3. **The Coder clones the repository into its own workspace.** It does not work in a copy on your own machine. The clone and the work happen in the assistant's private computer, using the login you connected under [Integrations](https://stellarfirm.ai/app/integrations).
4. **It works with a terminal and a browser.** It reads the code, edits files, and runs commands. For a change you can see on screen, it opens the page in a real browser and checks it.
5. **It runs the tests.** It runs the project's own checks and reports what ran and what passed.
6. **You see the changes.** Open the job in [Jobs](https://stellarfirm.ai/app/jobs) to read the actual diff and the commands it ran. Open the session's Terminal tab to watch it live.
7. **What happens next follows your house rules.**

### What happens after the work

The last step depends on your company, not on a fixed setting of the Coder.

| If your house rules say | The Coder |
| --- | --- |
| Nothing special (the default first run) | Pushes a branch and opens a pull request, by default a draft, for you to review. You Approve the push first. |
| Review only (the default merge policy) | Opens a pull request and leaves the merge to you or your team. |
| Merge after CEO approval | Opens a pull request, then merges once the CEO approves that step. |
| Auto merge on green | Merges once every check passes, with no extra ask. |
| Shipping | Follows its own rule: never (the default), after CEO approval, or automatically after a merge. |
| A step is risky or reaches other people | Waits for your Approve before it goes ahead. |

Your house rules are the rules in your company brief plus what you allow without asking under Auto-approve in [Settings](https://stellarfirm.ai/app/settings). Nothing is auto-approved until you turn it on yourself. See [approvals](/docs/ceo/approvals) and the [merge policy](/docs/ceo/house-rules#merge-policy) options.

> [!IMPORTANT]
> The first time you try the Coder, expect this path: you set a goal, the Coder works, you approve the risky step, and you get a pull request. A draft pull request is the default first-run outcome, and that is fine. Write your house rules when you want the Coder to go further.

## What you can ask for

| Say something like | What the Coder does | Asks first? |
| --- | --- | --- |
| "Pick up the top ticket" | Takes the oldest open issue, builds it, prepares the change | Before it pushes and opens a pull request |
| "Implement #42" | Builds that issue | Before it pushes and opens a pull request |
| "Fix the failing CI on PR #14" | Reads the failing check, fixes it in the smallest change | Before it pushes |
| "Build the pricing page" | Builds from your message | Before it pushes and opens a pull request |
| "Debug the flaky upload" | Investigates and finds the cause, with no write to your source host | No |
| "Review PR #14" | Reads the pull request and its checks, posts a summary | No, it only reads |
| "What is in the backlog?" | Lists open issues | No, it only reads |
| "Open an issue for the flaky test" | Files a well-formed issue | See your house rules |
| "Merge PR #14" | Merges when your house rules allow it, otherwise asks you first | Per your house rules |

> [!TIP]
> Be specific about the outcome. "Fix the login redirect and open a pull request for review" tells the Coder where to stop. "Fix it and ship it" tells it you expect the house rules to carry it further.

## Skills

Skills are the Coder's step-by-step playbooks. It picks the right one from your message, so you rarely need to name them.

| Skill | What it does, in plain words |
| --- | --- |
| First draft pull request | Takes the top ticket (or one you name), builds it, and prepares a pull request. The usual first win. |
| Implement a change | Builds, adds, or changes something in the repository from your description. |
| Fix CI | Reads the failing check first, reproduces the failure, finds the cause, and fixes it in the smallest change. |
| Debug a failure | Investigates a bug, crash, error message, or regression and finds the root cause before fixing it. |
| Review a pull request | Reads a pull request and its checks and replies with a summary and notes. It only reads. |
| Write tests | Adds or improves automated tests for a function, a module, or a bug fix, including a regression test. |
| Test strategy | Decides what to test before any test is written, ranked by risk, and plans how to keep tests steady. |
| Refactor safely | Cleans up or reorganizes code without changing behavior, with tests guarding the change. |
| Design decision | Weighs the options for a technical choice and recommends one with trade-offs before any code is written. |
| Set up CI | Creates or tightens a pipeline on GitHub, GitLab, or Bitbucket with fast feedback, caching, and safe defaults. |
| Draft a PR description | Writes or tidies a pull request title and description: summary, changes, testing, risks. |
| Open an issue | Files a clear issue with the context a teammate needs. |
| Verify in the browser | Checks a page, form, or flow in a real browser and reports with screenshots. |

## Integrations

| Integration | Status | What the Coder uses it for |
| --- | --- | --- |
| [GitHub](/docs/integrations/github) | Available | Issues, pull requests, checks, and pushing branches |
| [GitLab](/docs/integrations/gitlab) | Available | Issues, merge requests, pipelines, and pushing branches |
| [Bitbucket](/docs/integrations/bitbucket) | Available | Pull requests, build results, issues, and pushing branches |
| [Linear](/docs/integrations/linear), [Jira and Confluence](/docs/integrations/jira-and-confluence), [Asana](/docs/integrations/asana), [Notion](/docs/integrations/notion) | Coming soon | Reading tickets and specs |
| [Sentry](/docs/integrations/sentry), [Datadog](/docs/integrations/datadog), [PagerDuty](/docs/integrations/pagerduty) | Coming soon | Reading errors and incidents to debug them |
| [Slack](/docs/integrations/slack), [Telegram](/docs/integrations/telegram), [Discord](/docs/integrations/discord), [Microsoft Teams](/docs/integrations/microsoft-teams) | Coming soon | Handing work to the Coder from your team's chat. See [delegate work](/docs/ceo/delegate-work) |
| [Code editors](/docs/integrations/code-editors) | Coming soon | Handing a task to your editor |

Connect your source host under Integrations in the StellarFirm desktop app. [Connect your code](/docs/getting-started/connect-your-code) lists which token to create and the permissions each step needs. Only the Coder can change code.

## Example goals

- Build a small feature from an issue, such as a settings toggle or a new page.
- Fix a bug from a report, including a regression test.
- Get a red pull request green again.
- Review a teammate's pull request before you read it yourself.
- Add tests to a module nobody dares touch.
- Set up CI on a repository that has none.
- Tidy a messy function without changing what it does.

## Prompts to copy

Replace each `[bracket]` with your own details.

```prompt title="Pick up the top ticket"
Coder, pick up the top open ticket on [repository]. Build it, run the checks, and show me the changes. Follow our house rules for what happens next.
```

```prompt title="Implement a specific issue"
Coder, implement issue #[number] on [repository]. Keep the change small, add tests, and open a pull request for review.
```

```prompt title="Build a feature from a description"
Coder, on [repository], add [feature]. It should [behavior]. Check it in the browser and send me screenshots with the pull request.
```

```prompt title="Fix a failing check"
Coder, the checks on [pull request or branch] in [repository] are failing. Find the cause, fix it in the smallest change, and tell me what you changed.
```

```prompt title="Debug a bug from a report"
Coder, users report that [symptom] on [repository]. Find the root cause first and explain it. Then fix it with a regression test.
```

```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.
```

```prompt title="Write tests for a module"
Coder, write tests for [file or module] in [repository]. Cover the edge cases and one bug-style regression. Do not change the behavior.
```

```prompt title="Plan a test strategy"
Coder, look at [repository] and propose a test strategy. Rank the riskiest areas first and tell me what to test, what to skip, and why.
```

```prompt title="Refactor safely"
Coder, refactor [function or module] in [repository] to remove duplication. Behavior must not change, and the existing tests must still pass.
```

```prompt title="Weigh a design decision"
Coder, we need to decide between [option A] and [option B] for [problem]. Compare them for our codebase, recommend one, and write no code yet.
```

```prompt title="Set up CI"
Coder, set up CI on [repository] so every pull request runs lint, tests, and the build. Use caching and keep the permissions minimal.
```

```prompt title="Improve a pull request description"
Coder, rewrite the description of pull request #[number] on [repository] with a summary, the changes, how it was tested, and the risks.
```

```prompt title="Open a clear issue"
Coder, open an issue on [repository] for [problem]. Include steps to reproduce, what you expected, and what happened.
```

```prompt title="Verify a page in the browser"
Coder, open [page or flow] from [repository] in the browser, click through it, and report anything broken with screenshots.
```

## Several Coders

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

- Address one by name: "API Coder, add the endpoint."
- Or write the goal without a name, and the CEO assistant picks the Coder whose focus or repository fits. If it cannot tell, the default Coder takes it.
- Approvals and retries go back to the Coder that ran the job.

A Coder can also take on up to three roles, such as frontend, backend, devops, mobile, QA, or security, so it loads the skills that fit. Add a separate Coder when you need a fourth.

Set Coders up in [Settings](https://stellarfirm.ai/app/settings). Assistants spend credits when they work, so see [Usage](https://stellarfirm.ai/app/usage) for what your team used.

## Limits and good habits

> [!WARNING]
> The Coder follows your house rules, so check them before you allow merging. A rule such as "merge small fixes after checks pass" is powerful. Start narrow and widen it as you build trust.

- **Name the repository.** The Coder needs to know where to work. Connect your code host first, see [Connect your code](/docs/getting-started/connect-your-code).
- **State when to stop.** Say "open a pull request for review" or "merge once checks pass". If you say nothing, your house rules decide.
- **Keep goals small.** One clear change per goal gives you a diff you can read in minutes.
- **Read the diff.** Open the job in Jobs before you approve a risky step.
- **Work happens on its own branch.** The Coder never force-pushes, and your source host's own branch protection still applies.
- **Secrets stay out of prompts.** Never paste passwords or tokens into chat. Connect services through Integrations.
- **Vague goals get questions.** If the Coder asks, it is saving you a wrong turn. Answer in one line.

## Next steps

- Learn how routing picks an assistant in [routing](/docs/ceo/routing).
- Write your [house rules](/docs/ceo/house-rules) so the Coder knows how far to go.
- See a full plan for your company type in the [playbooks](/docs/playbooks).

---

Source: https://stellarfirm.ai/docs/personas/coder