Claude Code 2.1.138: team conventions check

The situation

Claude Code 2.1.138 shows up in the official changelog as an internal-fix release. That makes it a good checkpoint for teams using Claude Code in shared repositories: does CLAUDE.md still stay focused, do review expectations still match the repo, and are hooks or MCP connections scoped tightly enough?

This matters most for Claude Code teams that rely on persistent project memory, shared instructions, and agent-authored diffs. In that setup, the version is only part of the picture. The real question is whether the team’s conventions are still easy for Claude to load, follow, and review against.

The official docs describe Claude Code as an agentic coding tool that reads the codebase, edits files, runs commands, and works across tools. So even a small changelog entry can be worth a look. For readers following the broader Claude Code team conventions topic, this release is a useful checkpoint, not a feature launch.

Walkthrough

1. Start with the changelog entry, then check whether it changes anything your team depends on operationally. If the note is internal fixes only, treat it as a stability check: no new workflow to adopt, just a reason to re-check the one you already have.

2. Review the files that carry team conventions. For Claude Code, that usually means CLAUDE.md for always-on context, plus any scoped memory or rule files that keep repository-specific behavior local. Keep the instructions short enough that a new teammate can read them quickly and know what Claude should do in this repo.

3. Tighten the review boundary. If Claude is authoring code, reviewers should know what “good” looks like before they trust the diff: correct scope, no hidden repo-wide assumptions, and no drift from the team’s conventions.

A minimal CLAUDE.md fragment can keep the contract visible:

# CLAUDE.md

- Prefer small diffs with one behavioral change per PR.
- Follow existing repo patterns before introducing new abstractions.
- If a change touches shared config, call it out in the PR summary.
- Ask before adding new MCP connections or expanding tool access.

If your team uses skills, keep them narrow and easy to find. A skill works better than a long prompt when the task repeats and needs a clear activation surface.

---
name: repo-review-checklist
description: Use when reviewing Claude-authored pull requests in this repository.
---

# Review checklist

- Does the diff match the stated task?
- Are repo conventions preserved?
- Are tests or validation steps included?
- Are any new permissions or connectors justified?

4. Check hooks and MCP separately. Hooks are deterministic infrastructure; they should enforce lifecycle checks, formatting, or validation without depending on the model’s judgment. MCP should be reviewed as a connector boundary: what external systems are reachable, under what scope, and with what approval path?

5. Use the release as a training moment. A small changelog update is a good excuse to ask whether the team’s Claude Code workshop material still matches reality: do people know where memory lives, when to use a skill, and what reviewers should inspect before merging agent-authored work?

A practical starter checklist for this release:

• Confirm the installed Claude Code version in your team environment.
• Read the changelog entry and note whether any repo workflow is affected.
• Trim CLAUDE.md if it has become a catch-all.
• Audit any new or stale MCP connections.
• Re-run your review checklist on one recent Claude-authored PR.

Methodology note: in the Review step, small releases are useful because they force the team to inspect the contract, not just the code. That keeps the workshop grounded in what actually ships.

Tradeoffs and limits

Internal-fix releases are hard to evaluate from the outside. If the changelog does not name a user-facing behavior change, avoid reading too much into it. The safe move is to treat the release as a prompt to verify your own setup, not as evidence that your workflow needs a redesign.

There is also a limit to how much CLAUDE.md can carry. If the file grows into a policy dump, Claude may still load it, but humans will stop using it well. The same applies to skills: if every task becomes a skill, discovery gets worse. Keep durable rules in memory files, repeatable procedures in skills, and enforcement in hooks.

MCP deserves extra caution. A connector that is convenient in one repo can be too broad in another. Review scope, permissions, and failure modes before you treat it as standard team infrastructure.

Further reading

• https://code.claude.com/docs/en/changelog
• https://code.claude.com/docs/en/overview
• https://code.claude.com/docs/en/memory
• https://code.claude.com/docs/en/hooks
• https://code.claude.com/docs/en/mcp
• https://code.claude.com/docs/llms.txt
• /topics/team-conventions

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.