Team Workflows & Best Practices

From a personal tool to a team practice

A single developer using Claude Code gets faster. A team using it well gets something more valuable: a shared, versioned definition of how work is done — encoded in CLAUDE.md, settings, commands, and hooks, and improved by everyone. This final module is about that transition, and about the judgment that keeps speed from turning into liability.

Git and pull-request habits

Claude Code can drive git, and good habits here matter more with an agent, not less, because changes arrive faster.

• Branch first. Have Claude work on a feature branch, never straight on main. A simple rule for the agent: “if we’re on the default branch, create a branch before making changes.”
• Commit in coherent slices. As in Module 6, one logical change per commit keeps review, bisect, and revert all usable.
• Let Claude draft the PR, you own the description. It writes an accurate first draft of what changed and why from the actual diff; you add the intent and the trade-offs a diff can’t show.

> Create a branch `feature/loyalty-discount`, commit the work in
  logical steps with clear messages, push, and open a PR. In the
  description, summarise the change and explicitly list what a
  reviewer should scrutinise — the discount-stacking logic especially.

That last instruction — tell the reviewer where to look hardest — is a small habit that meaningfully raises review quality on agent-authored changes.

Use an agent to review code — including its own

Claude is a strong reviewer, and a second agent reviewing a change is one of the highest-value patterns in this course. Run a review pass before a human ever opens the PR:

> Review the diff on this branch as a skeptical senior Java engineer.
  Look for concurrency bugs, N+1 queries, missing transaction
  boundaries, broken null handling, and tests that assert nothing.
  Report findings by severity. Don't fix anything — just report.

Asking it to only report keeps you in the decision seat. A dedicated review subagent (Module 7) makes this a one-command habit. The principle from Module 5 holds: an independent verifier — even another agent — catches what the author (human or AI) misses.

But know its ceiling. An agent reviewing agent-written code shares some of the author’s blind spots: it reliably flags mechanical problems — N+1 queries, missing null handling, tests that assert nothing — and is far weaker on architectural fit, intent, and whether the change is the right thing to build at all. Use it as a fast first pass that clears the noise before a human looks, never as the last word.

The author is the worst reviewer of their own work — and that's as true for an agent as for a person. Always put a second set of eyes, human or agent, between a change and main.

Run Claude headless in CI

Claude Code isn’t only interactive. Headless mode runs a single prompt non-interactively and prints the result, which makes it scriptable in CI:

claude -p "Review the diff against origin/main for security issues
  and exit non-zero if you find a high-severity problem." \
  --output-format json

There’s also an official GitHub Action, so you can have Claude triage issues, draft fixes, or review pull requests automatically — for example, responding when someone mentions it on a PR. Useful CI patterns for a Java team:

• A review job that comments on PRs with potential bugs before a human looks.
• A nightly job that attempts a dependency bump on a branch, runs mvn verify, and opens a PR only if it’s green.
• Triage that labels and summarises new issues.

Treat CI agents as untrusted-input handlers. A job that reads pull-request descriptions or issue text is processing input from anyone. Scope its permissions tightly, never give it secrets it doesn’t need, and require human approval before anything it produces is merged or deployed.

Security and review discipline

The speed is real; so is the responsibility. A few non-negotiables for a professional team:

• Every line still gets human review before merge. “Claude wrote it” is not a review. The accountability for merged code is the human’s, full stop.
• Mind the supply chain. When Claude adds a dependency, check that it’s a real, maintained library at a sane version — don’t let an unfamiliar Maven coordinate into your pom.xml unexamined.
• Keep secrets out of context. Don’t paste credentials into a session; reference config by name. Hooks and MCP servers run with real access — least privilege, always.
• Pin the destructive behind a human. Database migrations that drop data, artifact publishes, deploys: the agent prepares, a person approves.

Cost, limits, and rolling it out

Adopting an agent across a team is partly an economic decision, so be clear-eyed about it. Usage isn’t free: a subscription meters work against your plan’s limits, while an API key bills per token. The things this course taught you to do for capability are also the things that drive cost — a large context, spawning subagents, hooks that run on every edit, and headless CI jobs all consume tokens.

The levers that control spend are the same ones that improve quality, which is convenient:

• Keep CLAUDE.md lean and /clear between tasks — a tight context is both cheaper and sharper.
• Reserve subagents for large, parallel work, not three-file changes (see Module 6).
• Keep hooks fast — format and compile, not the full integration suite (see Module 7).
• Scope CI agents so a triage job isn’t re-reading the whole repo on every run.

For rollout, start small and let trust compound: commit a good CLAUDE.md and a build-command allow-list so the whole team gets a low-friction setup, add one or two shared slash commands for your most common workflows, and only then reach for subagents, hooks, and CI automation. The team’s shared config becomes the institutional memory of how you work — versioned and improved like any other part of the codebase.

A rule of thumb for what to delegate

Use the price of verification as your guide — the thread running through this whole course:

• Delegate freely when a cheap, reliable verifier exists: code with good tests, a compile step, a lint rule. Claude can iterate against the check and you review the result.
• Stay hands-on when verification is expensive or absent: architectural decisions, security boundaries, public API contracts, anything where “looks right” is the only available check. Here Claude is a research assistant and a drafter, not a decider.
• Don’t bother delegating the trivial — and don’t delegate what you can’t review. Shipping a diff you don’t understand is how speed becomes incident.

Where to go next

You’ve gone from installing Claude Code to running it across a team with shared config, reviewed by agents and humans, integrated into CI, and governed by a clear sense of what to delegate. The best next step is the obvious one: open a real task in a real repository, write a tight CLAUDE.md, and run the loop. Revisit the Quick Reference when you need a command, and keep refining your project’s setup as you learn what your team gets wrong — that file is the course, applied.

Key takeaways

• Branch first, commit in slices, let Claude draft PRs while you own intent — and tell reviewers where to look hardest.
• Put a second reviewer (human or agent) between every change and main; the author can’t review their own work.
• Use headless mode (claude -p) and the GitHub Action for CI review, dependency bumps, and triage — treating CI agents as untrusted-input handlers.
• Non-negotiables: human review before merge, supply-chain vigilance, secrets out of context, humans gate the irreversible.
• Delegate by the price of verification: freely where checks are cheap, hands-on where they’re not, never what you can’t review.