Team AI Workflow — Shared .cursorrules, Cost Control & AI Review in CI

Chapter 17: Team AI Workflow — Shared .cursorrules, Cost Control & AI Review in CI

Using AI coding tools personally versus deploying them across a team are fundamentally different problems. Teams need three things individuals don't: consistency (everyone's AI output follows the same style), security (no production data leaks to AI APIs), and cost control (someone monitors API spend). This chapter gives concrete solutions to all three: layered .cursorrules management, GitHub Actions AI Review integration, API key governance, and a phased rollout strategy.

Chapter goals: Master the layered .cursorrules structure and team PR process; configure GitHub Actions AI Review CI independently; understand API key management and cost monitoring; take away a ready-to-use new hire onboarding checklist.

Why Team AI Differs from Personal Use

Three core problems to solve: (1) How to make everyone's AI output consistent? → Commit a shared .cursorrules to Git. (2) How to control AI costs? → API key management + usage monitoring. (3) How to turn AI Review into a team process? → GitHub Actions CI integration.

.cursorrules Team Management

Layered Structure

project-root/
├── .cursorrules          ← Shared project rules (committed to Git — mandatory)
├── .cursorrules.local    ← Personal preferences (.gitignore'd — not committed)
└── src/
    └── payments/
        └── .cursorrules  ← Payment module extra rules (stricter, sensitive domain)

Each layer has a clear purpose: the root .cursorrules defines tech stack, naming conventions, and security rules for everyone; the personal .cursorrules.local holds individual preferences without polluting the shared config; module-level .cursorrules handles domain-specific rules (e.g., "payment module: never log transaction amounts").

PR Standard for .cursorrules Changes

Every .cursorrules change affects all team members' AI behavior. Treat it like an architecture change. The PR description must include: what changed, why (ideally referencing a specific bug or PR), the exact impact on AI behavior, and approval requirement (at least one Tech Lead).

## .cursorrules Change

### What
Added: React components must use useQuery for API calls, not direct fetch

### Why
Three PRs last two weeks (PR #412, #438, #451) caused duplicate requests and
flicker due to useEffect + fetch in components

### Impact on AI behavior
After this rule, Cursor generates useQuery automatically instead of
useEffect + fetch when writing API calls inside components

### Approval required
At least 1 Tech Lead or architect before merge

API Key Management and Cost Control

The Right Key Flow

Wrong (common): each developer uses their own personal API key, key lives in .env.local, no usage monitoring, no idea what the monthly bill is until it arrives.

Right flow:

Team uses one shared Anthropic Organization account
  ↓
Create a separate API Key per project in Anthropic Console
(Project-A gets its own key, Project-B gets its own — cost attribution is clean)
  ↓
Store keys in company secrets manager
(AWS Secrets Manager / HashiCorp Vault / Doppler)
  ↓
Set a monthly budget cap per key in Anthropic Console
(auto-disable on overage — no runaway spending)
  ↓
Weekly usage report to team Slack channel

AI Review CI Integration: Phased Rollout

Mandating AI Review as a required check on Day 1 will create resistance. Roll it out in three phases so the team builds trust in the value before it becomes mandatory.

Phase 1 (Month 1): Optional Local Review

Add a make ai-review command. Developers use it voluntarily before committing. The goal is familiarity, not enforcement. Use claude-haiku to keep it under 5 seconds — slow tools get skipped.

Phase 2 (Month 2): CI Integration, Automatic PR Comment

GitHub Actions runs on every PR, calls Claude Sonnet, posts the result as a PR comment. It is not a required check — just a reference. This is critical: if AI Review blocks merges before the team trusts its accuracy, you'll get pushback that kills the initiative.

# .github/workflows/ai-review.yml
name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  ai-review:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: read
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install anthropic PyGithub
      - name: Run AI Review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
          REPO: ${{ github.repository }}
        run: python .github/scripts/ai_review.py

Phase 3 (Month 3+): Weekly Full-Codebase Security Scan

Not just diffs — scan the entire codebase weekly for lingering security issues in historical code. Schedule with a cron trigger. High-severity findings create GitHub Issues automatically, assigned to the relevant file's last modifier.

Cursor Business vs Personal: Purchase Decision

Decision rule: If your codebase touches user personal data, financial data, or trade secrets, Business is mandatory — forced Privacy Mode is a compliance requirement, not a nice-to-have. The extra $20/user/month is easily justified. Open-source projects and pure internal tooling can use Personal.

New Hire Onboarding Checklist

Day 1
□ Request Cursor Business seat (contact IT)
□ Initialize .cursorrules from team template:
    curl -sL https://raw.githubusercontent.com/your-org/cursorrules/main/python-fastapi.cursorrules -o .cursorrules
□ Read the entire .cursorrules — understand the reason behind each rule
□ Use Cursor to fix one small bug — experience the AI-assisted workflow

Week 1
□ Master Chat + @file references (for asking code questions)
□ Master Composer multi-file editing (for implementing new features)
□ Run make ai-review once — see what AI Review outputs
□ Learn the security red lines: what data cannot be shared with AI tools

Month 1
□ Build a personal Prompt template library (one each for code review, docs, debugging)
□ Know when to use Composer vs writing by hand
□ Participate in reviewing a .cursorrules change PR — understand how rules evolve

Chapter Key Points

1. .cursorrules must live in Git: Team standards that aren't version-controlled aren't enforced. The layered structure (project / personal / module) lets shared rules and individual preferences coexist without conflict.
2. Treat .cursorrules changes like architecture changes: Every rule affects everyone's AI output. PR descriptions must state the reason for the change and the specific impact on AI behavior.
3. Isolate API keys per project with budget caps: Create separate keys in Anthropic Console per project, set monthly spend limits, store in a secrets manager. Never use personal keys for company workloads.
4. Roll out AI Review in phases — never mandate on Day 1: Optional CLI tool → CI auto-comment → weekly full scan. Building trust before enforcement is what makes the rollout stick.
5. Business plan is mandatory for sensitive codebases: Forced Privacy Mode is a compliance requirement for code touching PII or financial data. The extra $20/user/month buys centralized management and audit capability too.

Next chapter: security review of AI-generated code — identification and fixes for 6 vulnerability classes, with runnable wrong-and-right code examples for each.