Skip to content
Documentation
Claude Code
Advanced Guide
Rules Playbook: Encode Team Bottom Lines

Rules Playbook: Encode Team Bottom Lines

If you want Claude Code to be stable and controllable in a team, Rules often matter more than “tips”: they encode bottom lines for security, testing, code style, and Git workflow, reducing repeated correction.

This page presents a team-friendly structure for organizing rules (security, testing, style, Git workflow) so they can be reviewed and evolved over time.

1) Suggested rule split (start with 5 files)

Keep rules in small files so they can be reviewed and iterated:

  • security.md: secrets, input validation, injection/XSS/CSRF bottom lines
  • testing.md: TDD cadence and critical-path testing requirements
  • coding-style.md: immutability, file structure, error handling, validation
  • git-workflow.md: commit format, PR process, change scope
  • performance.md: model selection, context window management, troubleshooting cadence

Tip: don’t start with “idealized” rules. Rules your team can actually follow are better than rules that only look impressive.

2) coding-style: immutability and organization (example)

Encode immutability as a hard rule:

// WRONG: Mutation
function updateUser(user, name) {
  user.name = name
  return user
}

// CORRECT: Immutability
function updateUser(user, name) {
  return { ...user, name }
}

And add actionable structure guidelines:

  • prefer many small files over a few huge ones (high cohesion, low coupling)
  • keep functions small (e.g. < 50 LOC)
  • keep files focused (e.g. < 800 LOC)

3) security: a pre-merge checklist (example)

Treat security.md as a merge-gate checklist:

  • no hardcoded secrets
  • validate all user input
  • parameterized queries to prevent SQL injection
  • prevent XSS on HTML output
  • CSRF protections
  • authN/authZ checks for sensitive operations
  • rate limiting
  • don’t leak sensitive info in error messages

To turn this into a workflow, pair with:

4) testing: make TDD a team default (example)

Core requirements:

  • unit/integration/E2E cover critical journeys
  • follow Red → Green → Refactor cadence

For E2E rollout details, see E2E testing workflow.

5) git-workflow: improve review input quality (example)

Two high-impact constraints:

  • standardize commit types (feat/fix/refactor/docs/test/…)
  • review the full diff for a PR: git diff [base-branch]...HEAD

This reduces “review only saw the last commit” misses.

6) performance: treat context as a finite resource

Two practical rules:

  • don’t run the context window down to the last ~20% (drift/forgetting increases)
  • use Plan Mode + critique loops for complex tasks

Related pages:

7) How to roll this into a team repo

Minimal rollout:

  1. put rule files in .claude/rules/ and commit them
  2. in CLAUDE.md, link to the rules and state they’re mandatory
  3. codify workflows via /command (plan/tdd/build-fix/code-review)

For a quick template, see: Team Starter Kit.

Reference

Hooks Recipes: Turn Lessons into Automated Guardrails