Claude Code for Teams: Planning, Tickets and Shared Context

Claude Code reads a repository, proposes a plan and edits files in a working tree. On a team, claude code earns its place when that plan sits next to the ticket, the repo rules and the review. A private chat on one laptop gives nobody else any of that. What you need is one ticket, one branch, a definition of done, and the same review you already give a human pull request.

What claude code is for a software team

Treat the agent as a fast pair who missed the last three meetings. It can search the repo, sketch a plan and apply a patch. It has no idea which customer complained, which release is frozen, or which flag is load-bearing. Those facts belong in the ticket and in files the repo already keeps for humans.

Anthropic ships it as a terminal and editor tool. Install steps and permission modes are in the official docs. This article is about the team habit around those commands.

Step	Owner	Output
Intake	Whoever got the request	One ticket: outcome, constraints, non-goals
Plan	Agent, from the repo plus the ticket	File list, risks, test plan
Edit	Agent on a branch	Diff limited to the plan
Review	A human who did not write the ticket	Approve, or send back with a note
Ship	Your normal release path	Merged PR, ticket moved

Skip the plan and standup gets a diff nobody can explain. Skip the ticket and the plan has no way to tell success from drift. If you already run a light process, have the agent read it. AI project management works when the board stays the source of truth and the agent works one card at a time.

Shared context before anyone writes code

Every session should start from the same facts, kept in files and a ticket. A chat is gone when the laptop sleeps, but files stay in git.

Put the stable rules in the repo: branch naming, off-limits paths (generated code, migrations, secrets), the test command that must pass before a PR, and the style rules a reviewer will reject. A short CLAUDE.md is enough. "Run npm test, do not edit vendor/, ask before a new dependency" beats a wiki nobody opens. When the same review note shows up twice, add a line for it.

For the ticket itself, attach only its error, acceptance notes and API contract.

MCP (Model Context Protocol) lets the agent call a tool such as "read ticket 481" instead of reading a screenshot. Start with a plain guide to MCP servers. Add only the tools a reviewer would trust, and keep production writes out of planning. Start read-only, then allow edits on the branch. A human pushes after review.

Tickets as the brief

If two engineers could disagree about what done means, the ticket isn't ready. The agent will follow the card literally.

1. Outcome: what a user or operator can do once this ships.
2. Constraints: response shapes, flags, no new dependency.
3. Non-goals: nearby work this branch will not touch.
4. Evidence: a failing test, an error sample, or a suspected file. Redact customer data.
5. Done when: the commands a reviewer will run, plus a manual check if the UI changed.

Write that before the session starts. Keep the path short: Triage, Ready, Planning, In review, Done. Planning means a human agreed to the file list. Don't merge from Triage just because the agent offered to do it. Recurring work comes back as a card that a person checks first, and call notes become a ticket. The agent sees the ticket, not the transcript.

A worked example: flaky checkout retry

Ticket 481: on a provider timeout, checkout retries once with the same idempotency key. It must not double-charge. Don't change the response shape or add a dependency. Touch only api/payments/ and its tests. Done when npm test -- api/payments passes and a test shows the same key on the second call.

Branch ticket-481-payment-timeout. First message: "Plan only. Do not edit yet." A sound plan names charge.ts and charge.test.ts, flags a new key on retry, and lists timeout-then-success, timeout-then-failure, and a 400 that must not retry. A webhook refactor is out of scope. Say no, then allow edits. You run the tests. The PR links 481. A teammate who did not steer the session asks for one more assertion. Merge, then move the ticket to Done.

The failure looks like taking on the webhook, or pushing because the tests "probably" pass. The same gate works for a copy change. See how teams use coding agents without losing control and where AI code review still needs a human.

claude code tips for planning together

Plan, then edit. Ask for files, risks and tests, cut the scope, and only then allow writes.

Name a budget. "At most four files" and "no new modules" work, while "keep it clean" doesn't.

Point at the check. Give the agent the repo's test or lint command, then run it yourself, because the agent saying tests passed is not a log.

One session, one ticket. A second bug gets its own card, since folding it in hides scope from review.

Put the plan on the PR: the files, the risk, and how you tested. If the thread has turned into defending an old mistake, start over from the ticket and the current diff.

Hold other agents to the same bar. Codex on the same repos uses the same ticket, branch rules and review (see OpenAI Codex for software teams). Name the env var, and keep the secret in the project env and in CI.

Review, rules and version-checked writes

Bad writes usually land on a stale file. Someone else merged, the agent edited an old copy, and the patch looks right but is wrong. Branch from the default branch before the session. Reject a commit that does not apply on current main, and leave out generated files a script can rebuild.

A version-checked write is tied to the version the agent read. If the file has moved, the write fails instead of clobbering a teammate. By hand, that's git status and git pull before you accept a patch. A tool can refuse the same clash.

A human still reviews customer-facing changes and anything that touches money, permissions or data. The agent drafts the PR text and the test, and the reviewer checks the diff against the ticket. DORA's four keys (deployment frequency, lead time, change fail rate, failed deployment recovery time) are a reminder that a shorter lead time with more failed changes is not a win. Once a quarter, delete the rules you no longer mean, because the agent will follow a stale line with full confidence.

Where a workspace helps

A tracker, git and a terminal are enough until copy-paste becomes the bottleneck: Slack into the ticket, the error onto the card, the plan back onto the card.

A workspace keeps the ticket, the plan and the repo rules where the agent can read them. Falrow is one option, currently in private beta. It turns Slack, call notes and Sentry errors into tickets. This agent or Codex can then plan from the git repo through MCP tools under the team's rules, including version-checked writes. The MCP tool catalogue lists those tools. Pricing is on request. If your board, repo and review already line up, keep them. The bar stays the same: one ticket, a plan a human accepted, and a diff a second human can explain.

FAQ

Is Claude Code only for solo developers?

No. Solo use is one person, one repo, one branch. A team adds a ticket, repo rules and a reviewer who did not steer the session. The agent shortens the path from a clear card to a diff, but it doesn't replace triage or release.

How is this different from pasting code into a chat?

A chat reply is text you copy back by hand. This agent reads and edits the working tree, runs project commands, and follows repo instructions. You still want a ticket and a pull request, because a transcript is not a reviewable history.

What should we put in the repo instructions file?

Only the rules review will enforce: test commands, directories to avoid, dependency policy, and how a PR is described. Skip architecture essays. A wrong line gets followed too. Add a line when the same note repeats, and delete rules you no longer mean.

Can several people run agents on one repository?

Yes, on separate branches and tickets. Two sessions on one branch will collide. Update from the default branch before planning, and stay inside the files the plan named. Prefer writes that fail when the file is no longer the version the agent read.