Agency

An agency lives or dies on trust. Clients must never see work you did not check. This playbook gives each client project its own Coder and keeps every client-facing step behind your Approve.

Who this is for#

Your assistants#

Why one Coder per client#

Each Coder has its own name, focus, repository, login to the source host, and private workspace. That separation is what keeps client work apart.

• Client A's code never sits in the same workspace as client B's.
• Each Coder uses a login that only reaches its own client's repository.
• You can address one by name, so a request about a client goes to the right place.
• Approvals and retries go back to the Coder that ran the job.

Add Coders under Coders in Settings. See the Coder.

Suggested house rules#

Keep these strict. You can relax them for internal projects later.

House rules
1. Each Coder works only in its own client's repository.
2. The Coder always works on its own branch and opens a pull request for review. A person on our team merges after review.
3. Nothing is published, deployed, or sent to a client until I approve it.
4. Every pull request description says what changed, how it was tested, and what to check.
5. No client names, secrets, or personal data in prompts or pull request descriptions.
6. For internal projects (our own site, our own tools), the Coder may merge small fixes after checks pass.

Preflight#

• Sign in at https://stellarfirm.ai/app with your invitation.
• Connect your source host on Integrations. If clients keep code in their own accounts, connect a login that has access to just those repositories.
• List your active client projects and their repositories.
• Decide who on your team reviews each client's pull requests.
• Write the house rules in your company brief.

Launch: Day 1#

1. Add a Coder for your most active client. Name it after the client or the project, and give it a short focus, such as "Acme storefront, React".
2. Point it at the client's repository. Add the repository in the Coder's settings.
3. Run a small first goal.

[Client] Coder, look at [repository] and tell me what the project is, how to run its tests, and what the open issues are. Do not change anything yet.

[Client] Coder, pick up the smallest open issue on [repository]. Build it, run the checks, and open a pull request for review with a clear description.

4. Review in Jobs. Read the diff in Jobs. Approve the push in Approvals when it looks right.
5. Review the pull request the way you would any teammate's.

First week#

[Client] Coder, the checks on pull request #[number] in [repository] are failing. Find the cause and fix it in the smallest change. Open a pull request for review.

[Client] Coder, the client asked for: [request]. On [repository], build it in a way that matches the existing code style. Check the page in the browser and attach screenshots to the pull request.

[Client] Coder, review pull request #[number] on [repository] as a careful senior developer. List risks, missing tests, and anything the client would notice.

[Client] Coder, write a short, plain-language summary of the changes in pull request #[number] on [repository], suitable for me to paste into an update for the client. Do not send anything.

[Client] Coder, before we change [area] on [repository], write tests that lock in how it works today. Open a pull request for review.

Team, for each client Coder, summarize what shipped this week, what is waiting for my review, and what is blocked.

Steady orbit#

• Monday. Choose each client's top goals and brief the Coders.
• Daily. Clear the waiting items in Approvals.
• Before each client call. Ask the client's Coder for a summary of what shipped.
• Monthly. Review house rules per client. Some clients may earn more freedom than others.
• When a client leaves. Remove its Coder and its login.

Pitfalls#

• One Coder for many clients. Mixing clients in one Coder blurs repositories and logins. Give each client its own.
• Shared logins. Use a login that reaches only the repositories that Coder needs.
• Naming the client in prompts when it should stay private. Use short project names if your contract requires confidentiality.
• Letting speed beat review. Client trust is the product. Keep client-facing steps behind Approve.
• Vague client requests. Paste the request as written and ask the Coder to list its questions before it starts.