Team Patterns

A situation you may recognize

Standup. Three people say some version of:

“The AI ran root tests again.”
“It tried to force-push on my branch.”
“It added a dependency I did not ask for.”

Everyone has a personal preamble in their clipboard. Nobody has updated a shared file in months.

That standup pattern is a signal: the team is paying a recurring tax in chat because infrastructure never absorbed the lesson. Session 3 showed the fix for one person. Session 5 asks what it looks like when five people share one repo, and when leadership makes the boring files official.

Good AI habits start individual, at the keyboard, in your brief, in your verification notes. They scale through shared artifacts: rules files, CI scope, review questions, skills. Without those, even strong engineers repeat the same corrections because the repository never learned.

Shared files are shared agreements

Asset	Helps one person…	Helps a team…
Agent rules file	Stop retyping corrections	Stop everyone retyping the same corrections
Skills	Repeat a trusted workflow	Onboard humans and AI sessions to the same playbook
Layout and tests	Guide the AI to boundaries	Show boundaries everyone shares

Treat AGENTS.md (or your tool’s equivalent) like lint config, reviewed in pull requests, versioned, boring. Boring is the goal. When someone says “the AI keeps doing X,” the fix is usually one new line in the rules file, not a thirty-minute thread on which model to use.

The snippets below are examples, not copy-paste law. Adapt the shape: scoped tests, forbidden git commands, sensitive paths called out by name.

## Before commit
- Run `pnpm test` in the package you touched, not root only
- Never force-push to main

## Forbidden
- `git clean`, credential files, `.env*`

For payment work:

## Payments
- Run `pnpm --filter payments test` after touching payment helpers
- Include declined-card coverage for behavior changes
- Ask for adversarial review before merging auth, payment, or migration changes

Review for evidence, not authorship

Pull requests still have human authors. The question for reviewers is unchanged in substance: is this safe to merge? What changed is volume, AI-assisted diffs can be larger and more articulate, which makes “skim and approve” more tempting.

The checkpoint below separates questions that perform accountability from questions that protect users.

Helpful team habits:

• Label agent-assisted PRs if transparency matters, not for shame, so reviewers calibrate effort.
• Ask for evidence: test output or short reproduction notes for behavior changes. Session 4’s verification note is a good template.
• Keep pull requests reasonably sized: sessions already split work; Git should not recombine everything into one unreviewable blob.

CI as the floor, not the ceiling

Session 4’s ladder is personal judgment. Teams still need a minimum enforced when someone is tired, new, or rushing, that is CI’s job.

CI is not full verification. It is the floor: the worst merge you prevent when nobody has energy for curiosity. Flaky CI teaches people to trust green lights they should not trust; fix the pipeline before debating model choice.

Gate	What it helps catch
Required checks on main	Merge without test/lint/typecheck
Path-scoped workflows	Running tests in the wrong package
Secret scanning	Credentials accidentally committed
Protected branches	Changes that skip human review

Skills as team infrastructure

Skills are Session 3’s idea at team scale: reviewed instructions for a repeated job, checked into the repo or synced like any other config. One skill per repeated job, PR review, release checklist, incident triage, pinned or synced like ESLint config, updated when the job changes.

Stale skills teach stale rituals. When the team changes how it verifies payment work, update the skill in the same pull request, or retire it openly so nobody follows a checklist from last year.

Individual contributors and leads

Role	Emphasis
IC	Small sessions, careful verification, improving agent rules
Lead / EM	CI floors, shared skills, review culture, clear policy

Notes for team leads

ICs can write rules and verification notes. Some things need leadership air cover, not because engineers cannot read Session 4, but because policy and culture decide whether good habits survive busy quarters.

• Policy: what data may enter which tools; whether PRs disclose AI assistance; legal guidance on generated code.
• Onboarding: pair early sessions on low-risk tasks; use Session 4’s assertion example in a lunch conversation.
• Patterns worth discouraging early: vanity metrics, skipping review because “the AI is smart,” private mega-prompts instead of one reviewed rules file.

A simple team floor many teams aim for:

1. Agent rules in the repo, reviewed like code
2. CI runs the right scope for each change
3. Behavior-changing PRs include verification notes
4. At least one shared skill or checklist for review or refactor

A gentle team exercise (optional)

In standup or review, name one repeated correction. Ask together: agent rules, skill, CI, or PR template? If nobody owns it, the correction will keep appearing in chat.

Before the wrap-up

Session 6 offers a short quiz and the full story in one place. The quick reference there replaces the old overview cheat sheet, bookmark it when you want tables without rereading every session.

Next: Session 6: Check + Carry Forward