Team habits and safety rails

Two developers on the same team both “use Claude Code.” One keeps a personal CLAUDE.md that says never touch production configs, always open a PR, and never paste customer exports into the agent. The other runs high-autonomy mode on Friday afternoons, accepts multi-file edits mid-standup, and once deployed a migration because the agent said the dry run looked fine. Same product. Different blast radius. The difference is not model IQ. It is team habits and safety rails.

This is Part 10 of the Claude Code tutorial, and it closes the series. Parts 1 through 9 got you from first run through exploration, commands, skills, memory, instruction files, plugins, agent loops, and the personal review loop (diffs, undo, not shipping blind). Now the multiplayer layer: shared rules, pull requests, CI, secrets policy, no silent production deploys from an agent, and teaching juniors review skills before high autonomy. Solo discipline does not scale. Written rails do.

What you’ll learn

Why team defaults beat heroic individual caution
A practical set of safety rails: shared docs, PRs, CI, secrets, deploy ownership
A starter habit pack you can adopt in one week without a bureaucracy project
How to ramp juniors (and tired seniors) without banning the tool
What “done” looks like for this series and where Claude Cowork and the map/learn tracks go next

Tool names, plan bundling, and enterprise controls move. Re-check Claude Code docs and your org’s security guidance before you turn this post into a mandatory policy PDF.

Why personal habits are not enough

Part 9 taught a five-step personal loop: read the diff, run tests, check secrets, check scope, human commit. That loop still applies. Teams fail when the loop is optional folklore. New hires never hear it. Contractors never see it. Someone on a deadline skips it once, gets lucky, and teaches the team that luck is a process.

Agentic coding multiplies the cost of uneven habits. One person can generate a 40-file PR in an afternoon. Reviewers cannot “feel” quality from a chat transcript. They need small PRs, green CI, and a culture that treats “the model said it was fine” as a non-reason.

If your company already has secure SDLC, change management, and least-privilege access, Claude Code plugs into those. It does not replace them. If you do not have those rails yet, do not wait for a perfect platform team. Start with the smallest written agreements that prevent the worst Fridays.

Team safety rails (the core set)

Think in three buckets: shared brain, merge gates, and data/deploy boundaries.

1. Shared CLAUDE.md (and shared skills)

One project source of truth for agent-facing rules beats twelve private prompt notebooks. Put build/test commands, stack facts, “never” lists, and review expectations in repo files the whole team sees in git. Parts 6 and 7 of this series covered instruction files and skills; the team version is simple: if it is a rule, it is in the repo.

Minimum shared content:

How to install, build, test, and lint (exact commands)
Code style that actually matters (formatter, package manager, “we don’t use X”)
Safety: secrets, prod deploys, data classes, force-push policy
Where skills live (.claude/skills/…) for repeated workflows (release notes, code review checklist, migration checklist)

Keep it short and true. Aspirational novels rot. When reality changes, update the file in the same PR as the process change so the agent and the humans stay aligned.

## Team safety (example CLAUDE.md section)
- Open a PR for all shared-branch work. No direct pushes to main.
- CI must be green before merge. Do not “merge and fix later” on red typecheck.
- Never commit secrets, customer PII, or production .env files.
- Never deploy to production from an agent session alone. Humans run/approve release.
- Prefer smallest diff. Do not reformat unrelated files.
- Do not delete tests without a linked ticket and reviewer OK.
- Force-push only on personal branches you alone use; never on main or release/*.

2. Pull requests required, CI green

A PR is not bureaucracy theater. It is a forced pause where a second human (or a designated reviewer rotation) sees the same diff you should have read in Part 9. Require PRs into protected branches. Require status checks: tests, lint, typecheck, security scans if you have them. “Claude wrote it” is not a status check.

Practical norms that keep agent PRs reviewable:

Small PRs. One ticket, one main idea. Split refactors from features.
Honest titles and descriptions. Include what you asked the agent, what you verified, and known risks.
No “AI generated, LGTM.” Reviewers still own the merge button.
CI green means green on this branch, not “green last week on main.”

If your team is tiny (two people) you still benefit from PRs as a personal audit log and a place for CI. Self-merging after a waiting period is better than silent pushes when something breaks at 11 p.m.

3. Secrets and data policy

Write down what may never enter an agent session: production credentials, unrestricted customer PII, raw HR files, unreleased financials if policy says so, anything under legal hold. Point people at the approved secret manager and the approved enterprise AI path if you have one. Personal Pro accounts and shadow IT do not become compliant because the model is helpful.

Also write the boring technical rules:

.env and key files stay gitignored; pre-commit hooks or secret scanning when available
Example configs use obvious fakes (sk_test_xxx, REPLACE_ME), not almost-real strings
Logs and fixtures use synthetic data for demos
Incident path if a secret lands in git (rotate, notify, do not freestyle history rewrites alone)

Claude Code permissions can deny certain bash patterns and paths; use them. Product permission rules are not a complete data governance program, but they catch foot-guns. See Configure permissions.

4. No silent production deploys from the agent

This one deserves its own line in every team doc: no silent production deploys from an agent session alone. An agent can help draft a deploy script, prepare a changelog, or open a PR that triggers a pipeline. A human still owns the production button (or the formal approval in your CD system). If your pipeline auto-deploys from main, then protecting main and requiring review is how you keep the agent out of the blast zone.

Same spirit for destructive ops: dropping tables, rotating traffic, bulk-updating customer rows, force-pushing release branches. Capability in the terminal is not the same as authorization in the org chart.

Team habit starter pack

If you need something you can introduce on Monday without a six-week “AI governance program,” start here.

Habit	What good looks like	Failure mode
Branch per task	One ticket → one branch → one PR	Main becomes a scratchpad of half agent runs
Small PRs	Reviewable in one sitting	800-line “misc fixes” nobody reads
Test before merge	Local + CI both green for risk paths	“Works on my machine / the model said so”
Document in CLAUDE.md	Commands and never-dos stay current	Tribal knowledge only seniors remember
Retro on agent fails	5-minute note: what slipped, what rule to add	Same secret leak pattern every quarter

Retros do not need ceremony. A shared doc titled “Agent incidents” with date, what happened, and one process change is enough. Example: “Agent deleted flaky test to green CI → rule: no test deletion without ticket; CI fails if coverage drops on path X.”

Agree out loud on autonomy levels

Part 8 framed autonomy as watch, steer, or walk away with rails. Teams need a shared map so juniors are not copying a staff engineer’s high-trust setup on day three.

Level	Who	Typical mode	Required gates
Watch	Everyone learning the repo	Approve each sensitive tool use	Read every diff; no push without local tests
Steer	Comfortable with stack + review loop	Accept batches of edits; still review	PR + CI; no prod deploy alone
Walk away (limited)	Experienced, isolated sandbox only	Longer agent loops on throwaway branches	No secrets, no prod creds, human merge later

Write which level is default for production repos. “Walk away” on a laptop that has prod kube credentials is not a level. It is a story for the incident channel.

Teach juniors review before high autonomy

The kindest onboarding is not “here is the most powerful flag.” It is “here is how we refuse a bad patch.” Teach the Part 9 loop as a first-class skill:

How to read git diff --stat and spot scope creep
How to restore unrelated files without panicking
How to run the project’s test commands cold (no senior standing behind them)
How to write a PR description that admits what the agent did
How to say “I am not merging this” without drama

Pairing idea: junior drives Claude Code, senior only reviews the diff and asks questions. After a few sessions, swap. The goal is not to police enthusiasm. The goal is to make review muscle memory so autonomy is earned, not assumed.

Managers: measure outcomes that matter (incident rate, review latency, escaped defects), not “lines generated by AI.” Lines are easy to game. Customer trust is not.

A one-week rollout plan (lightweight)

You do not need a task force. You need five working days of deliberate defaults.

Day 1: Create or refresh root CLAUDE.md with commands + safety section. Open a PR. Discuss in standup.
Day 2: Turn on branch protection for main (or confirm it): PR required, CI required.
Day 3: Add or document secret scanning / .env gitignore checks. Share the “never paste” data list.
Day 4: Write one shared skill (for example /team-pr-checklist) that prints the review loop and smell list from Part 9.
Day 5: 30-minute team demo: messy agent diff, restore extras, open a clean PR. Capture questions in the agent incidents doc.

If you already have strong engineering hygiene, Day 1 and Day 5 may be enough. The point is explicit agreement, not new tools for their own sake.

Sample PR template for agent-assisted work

Paste something like this into PULL_REQUEST_TEMPLATE.md so every agent-heavy change leaves an audit trail:

## Summary
- Ticket:
- Intentional human goal (one sentence):

## Agent assist
- [ ] Claude Code (or other) used
- Prompt / skill used (short):
- Files I asked it to touch:
- Files it also touched (if any) and what I did about them:

## Verification
- [ ] I read the full diff (not only the chat summary)
- [ ] Tests run (commands):
- [ ] No secrets or PII in the patch
- [ ] Scope matches the ticket

## Risk
- What could break:
- Rollback plan:

## Deploy
- [ ] No production deploy from agent alone
- Human owner for release:

Templates feel fussy until the second time a PR includes a surprise dependency bump. Then they feel cheap.

What teams argue about (and a default stance)

Debate	Default stance for most product teams
Ban agents on prod repos?	No. Require rails. Ban only if you cannot get PR+CI+secrets under control yet.
Allow high-autonomy modes?	Yes on sandboxes and personal experiments; default lower autonomy on shared prod code.
Must every line be human-typed?	No. Every merge should be human-understood.
AI-only code review?	Useful assist, not a sole approver for high-risk paths.
Same rules for seniors?	Yes for secrets and prod. Seniors model the review loop; they do not skip it.

Your regulated industry may need stricter defaults. That is fine. Write them down. Unwritten strictness is just uneven enforcement.

Common mistakes

Private super-prompts instead of repo rules. When the author leaves, the rails leave.
PR required in theory, direct push in practice. Protect the branch in the host settings, not only in a wiki.
CI optional “when we are busy.” Busy is when you need CI most.
Teaching juniors the fastest flags first. Teach restore and review first.
Silent prod deploys because the agent can run the script. Capability is not approval.
No place to record agent failures. You will relearn the same lesson with new names.
Assuming chat products and Code share the same risk model. Code edits repos. Rails must match that power.
Copying another company’s 40-page AI policy without local commands. Your npm test line matters more than their philosophy appendix.

Practice: team session (45 minutes)

Pick one real repo. Open current CLAUDE.md (or create a draft).
As a group, write five never-dos and three exact test commands.
Confirm branch protection and required checks on the default branch (screenshot for the team doc).
Run a controlled messy agent task on a throwaway branch. Practice the Part 9 restore + review path live.
Add one entry to an “agent incidents / lessons” doc (even if the lesson is “our first drill went fine”).
Assign a human owner for monthly CLAUDE.md truth checks (15 minutes on a calendar).

What this series covered

Claude Code tutorial was the deep coding-agent track for people who will touch a project:

Part	Focus
1	Install / open Claude Code and first run
2	Talking to a codebase: ask, explore, change
3	Slash commands and common patterns
4	Skills: add and use
5	Memory and context: what sticks, what resets
6	Markdown and project instruction files
7	Plugins, connectors, and tools
8	Loops and agentic runs
9	Reviewing diffs, undoing, not shipping blind
10	Team habits and safety rails (this post)

If you only keep one idea from ten parts: Claude Code is a strong pair-programmer with tools, not an unsupervised release engineer. The more autonomy you grant, the more your review loop and team rails have to be real.

What comes next on AMS

This closes the Claude Code tutorial series. Next deep track on the content plan is the Claude Cowork tutorial: agent-style help for broader office work (files, folders, docs, spreadsheets, connectors), aimed at non-developers and mixed roles, still with judgment and data boundaries. Cowork is not “Code but easier.” It is a different surface with different jobs. Do not import terminal habits blindly; do import the verify habit.

If you still need product orientation rather than a deep tutorial:

Learn Claude from scratch for everyday chat, Projects, privacy, and wrong-tool judgment
Claude product map for chat vs Code vs Cowork vs other flavors and when each is the default
Learn hub for the wider AMS path list (SQL, Python, quality, metrics, and more)

For analysts who use Code or chat to draft queries, keep the verify path close: How to check AI-written SQL before you ship it.

Quick recap

Shared CLAUDE.md + skills beat private folklore.
PR required and CI green are merge gates, not niceties.
Secrets and data classes need written never-dos and technical enforcement where possible.
No silent production deploys from an agent alone; humans own release.
Teach review (Part 9) before high autonomy; seniors model the same rails.
Starter habits: branch per task, small PRs, test before merge, document, retro on fails.
Series complete; next deep track is Claude Cowork, with Learn Claude and the product map for orientation.

Ship the rails, then raise autonomy. The other order makes exciting demos and quiet outages.

Sources

Docs and related reading for team rails, permissions, and verify culture:

Claude Code documentation: Overview (product scope; re-check when writing org policy)
Claude Code documentation: Configure permissions (team-distributable permission rules and modes)
Anthropic Engineering: How we built Claude Code auto mode (default permission posture and tradeoffs of skipping approvals)
Anthropic Engineering: How we contain Claude across products (different agentic surfaces need different containment)
Pro Git: Distributed workflows (branch and integration patterns teams still rely on)
GitHub Docs: About protected branches (PR and status-check gates; adapt if you use GitLab/Bitbucket equivalents)
OWASP Top 10 for LLM Applications (sensitive information, over-reliance, and supply-chain themes for agent tooling)
Analytics Made Simple: How to check AI-written SQL before you ship it (verify habit for fluent wrong outputs)
Analytics Made Simple: Learn Claude from scratch (everyday orientation series)
Analytics Made Simple: Claude product map (which Claude product for which job)
Analytics Made Simple: Learn (related paths on this site)