The Coder

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

Mission brief#

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

Your house rules are the rules in your company brief plus what you allow without asking under Auto-approve in Settings. Nothing is auto-approved until you turn it on yourself. See approvals and the merge policy options.

What you can ask for#

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.

Integrations#

Connect your source host on Integrations. Connected services share context with every assistant, but 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.

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.

Coder, implement issue #[number] on [repository]. Keep the change small, add tests, and open a pull request for review.

Coder, on [repository], add [feature]. It should [behavior]. Check it in the browser and send me screenshots with the pull request.

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.

Coder, users report that [symptom] on [repository]. Find the root cause first and explain it. Then fix it with a regression test.

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

Coder, write tests for [file or module] in [repository]. Cover the edge cases and one bug-style regression. Do not change the behavior.

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.

Coder, refactor [function or module] in [repository] to remove duplication. Behavior must not change, and the existing tests must still pass.

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.

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

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

Coder, open an issue on [repository] for [problem]. Include steps to reproduce, what you expected, and what happened.

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. Assistants spend credits when they work, so see Usage for what your team used.

Limits and good habits#

• Name the repository. The Coder needs to know where to work. Connect it under Integrations first.
• 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.
• Write your house rules so the Coder knows how far to go.
• See a full plan for your company type in the playbooks.