I maintain a CLAUDE.md at the root of each project repository. This file is committed to source control and shared across the whole engineering team. It contains everything Claude needs to understand our codebase: architecture decisions, domain-specific conventions, environment setup notes, and the kinds of tasks we frequently ask it to help with.

The payoff is consistency. Every engineer on the team gets the same baseline context automatically — there's no onboarding "prompt ritual" to pass around or forget to update. When someone new joins the project, Claude already knows the project's conventions from day one. It's the closest thing to a living, executable README for your AI collaborator.

Alongside the shared file, I keep a CLAUDE.local.md that is gitignored and never committed. This is my personal layer: commit message style (conventional commits), PR workflow preferences, code style opinions that differ from the team defaults, and — importantly — British English spelling throughout all generated content and comments.

The separation of concerns here is deliberate. Team conventions go in the shared file; personal preferences stay local. You never impose your quirks on teammates, but you also never lose them. Claude applies both layers together without you having to specify anything per session.

The global file at ~/.claude/CLAUDE.md is the foundation beneath everything else. This is where I encode preferences that apply everywhere: general coding philosophies, preferred patterns for error handling, how I like tests structured, and personal working style rules.

Claude Code reads these files in a clear hierarchy — global, then project, then local — with each layer able to override or extend the one below it. The result is that you never start a session without context. Every project inherits your baseline, every project customises it, and you as an individual customise it further on top. There is no blank slate.

When I begin any piece of work, I activate Plan mode first. Claude Code fetches the relevant Linear ticket, reads its description and acceptance criteria, updates the ticket status to "In Progress", and checks out a new branch following our agreed naming convention — all in a single orchestrated step.

If there's no ticket yet, Claude creates one in Linear before proceeding. This means I don't have to tab out to a project management tool, don't have to remember our branch naming format, and don't have to manually update status. The administrative overhead of starting a task collapses to near zero.

What makes Plan mode specifically valuable here is that Claude proposes its intended approach before executing anything. I can see the plan, push back, refine it, and then let it run. This is the difference between a thoughtful collaborator and an overeager code generator that runs before you've agreed on direction.

Our engineering team maintains an internal marketplace of Claude Code plugins. I've enabled the ones relevant to my work, and these plug into Claude's tool lifecycle at specific points:

PreToolUse hooks fire before a tool runs. One of the most useful is a hook that intercepts any attempt to read .env files, checking that access is appropriate before it happens. This is a practical security guardrail that operates automatically — no manual discipline required.

Skill-checking hooks inspect the current task and surface relevant pre-built skills from our internal library before Claude plans its approach. This means Claude is aware of patterns we've already solved and encoded, rather than reinventing them.

PostToolUse hooks fire after tool calls complete. A key one for us triggers auto-lint after any file edit. The code I commit has already been linted by the time I review it — the feedback loop is tight and automatic.

Sharing plugins through a team marketplace means everyone benefits from automation improvements immediately. When one engineer improves a hook, the whole team picks it up without a manual distribution step.

I've connected three MCP servers — Linear, Slack, and GitHub — configured in settings.local.json so they're specific to this project's context and not globally applied everywhere.

Linear MCP means I can retrieve issues, update statuses, and add comments from within Claude Code as part of any task — not just at the start. As I discover scope changes or blockers mid-implementation, the ticket reflects that in real time.

Slack MCP means I can communicate with my team — send updates, ask questions, share links — without leaving the tool. This sounds like a small thing until you realise how much of the cognitive cost of switching tools is not the switch itself, but the re-establishment of focus afterwards.

GitHub MCP enables interactions with pull requests and repository state directly. Scoping it to settings.local.json rather than the global config keeps it project-specific, which matters when you're working across repositories with different workflows.

The theme across all three is the same: I have not left Claude Code to do any of this. Every tool call, status update, and team message happens from a single environment.

Beyond the MCP connections, I've built two custom skills that encode specific multi-step workflows my team runs repeatedly:

The ticket planning skill handles the full flow of breaking down work and creating well-structured Linear tickets. It applies our team's template, infers acceptance criteria from the description, assigns estimates based on scope cues, and sets the right labels. What used to be five minutes of manual ticket grooming is now a single command.

The PR review request skill composes and posts a formatted message to our team Slack channel when a pull request is ready for review. It populates our review request template — PR title, link, description summary, which areas need particular attention — and sends it in the right format without me having to think about it.

Custom skills are essentially saved, parameterised workflows. The value compounds: each skill you write reduces a category of repeated friction permanently, not just once.