Claude Code Operational Patterns

There's a version of Claude Code that's "AI autocomplete with a chat window." There's another version where it's a junior engineer who knows your codebase, follows your conventions, and asks before doing anything dangerous, and a third version where it's infrastructure other systems and other engineers can rely on without you in the room. The difference is roughly eight configuration choices.

1. Plan mode for anything non-trivial

Plan mode is the single biggest behavior change available. Instead of executing immediately, Claude drafts an implementation plan, surfaces choices that warrant your input, writes the plan to a file, and waits for explicit approval before touching code.

The pattern that works:

1. Open the conversation with the task.
2. Add: "Use plan mode. Ask 2–3 clarifying questions if anything is genuinely ambiguous, then write the plan."
3. Review the plan in the file. Edit it directly if needed.
4. Approve.

2. Slash commands for the work you repeat

Anything you've explained twice belongs in a slash command. Conventions, deploy steps, code review templates, "ship this PR" workflows, all of it. The win isn't speed of typing; it's the elimination of which version of the prompt did I use last time?

A useful starter set:

• /ship: formats the diff, writes the PR description, opens the PR
• /review: runs an opinionated review with the project's known pitfalls
• /playbook <name>: loads a project-specific operating doc into context
• /recover: rolls back to the last clean state when an iteration goes sideways

3. Hooks for the safety net

Hooks let the harness intercept tool calls. Perfect for blocking destructive commands in production directories, auto-formatting after edits, or running typecheck on every save. They run outside of Claude's decision loop, so they aren't subject to "the model decided not to."

{
"hooks": {
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [
        { "type": "command", "command": "scripts/block-destructive.sh" }
      ]
    }
  ],
  "PostToolUse": [
    {
      "matcher": "Edit|Write",
      "hooks": [
        { "type": "command", "command": "pnpm format" }
      ]
    }
  ]
}
}

The hook is just a shell script. It can exit non-zero to block the call, write a message to stderr to tell the model why, or modify the input. This is where you encode the rules that should be enforced, not negotiated.

4. Subagents for context isolation

Subagents are the most underused feature. They're independent agent instances spawned by the main conversation. Full tool access, but their work product comes back as a single message, so they don't pollute the main context window.

Use them for:

• Searches that span the codebase ("find every place we read from the SQS queue"). The subagent reads dozens of files; you get a clean summary.
• Independent reviews ("look at this migration with fresh eyes, am I missing a race condition?"). No anchoring bias.
• Parallel work. Kick off three subagents at once for genuinely independent investigations.

5. CLAUDE.md as the project's onboarding doc

CLAUDE.md is read at the start of every session. Treat it the way you'd treat the README for a new hire on their first day:

• The why. What is this codebase trying to be?
• The commands. How do I run, build, test?
• The non-obvious. Anything a thoughtful engineer would still get wrong without context.
• The pointers. Where to find deeper docs (PRDs, runbooks, the gnarly bits).

What does NOT go in CLAUDE.md: things derivable from git log, things obvious from reading one file, generic platitudes ("write good code"), or anything that would rot in a week.

6. MCP servers for connecting Claude to what you already run

Model Context Protocol servers give Claude live access to the systems your team actually uses, Jira, internal APIs, a database, instead of whatever you managed to paste into the context window. The agent calls a tool, gets a real answer, and reasons over current state rather than a stale copy.

{
"mcpServers": {
  "jira": {
    "command": "npx",
    "args": ["-y", "@your-org/jira-mcp-server"],
    "env": { "JIRA_API_TOKEN": "$JIRA_API_TOKEN" }
  }
}
}

Start with read-only servers: search, fetch, lookup. Earn trust before wiring up anything that writes, and put write-capable tools behind the hooks from Section 3.

7. Headless mode for the pipelines nobody watches

claude -p (or --print) runs Claude Code non-interactively: no TUI, structured output on request, safe to call from a script instead of a terminal. That's the difference between a tool an engineer opens and a primitive other systems can call.

claude -p "Summarize the diff between $BASE and $HEAD as a changelog entry" \
--output-format json \
--allowedTools "Bash(git diff:*)" \
> changelog-draft.json

8. Managed settings, Skills, and Plugins: the org-scale primitives

A project's .claude/settings.json is a suggestion an individual engineer can override. Managed settings are enforced at the org level, so the hook policies and permission defaults from Section 3 apply to every seat, not just the ones who remembered to keep them turned on.

{
"permissions": {
  "deny": ["Bash(rm -rf:*)", "Bash(git push --force:*)"]
},
"hooks": {
  "PreToolUse": [
    { "matcher": "Bash", "hooks": [{ "type": "command", "command": "scripts/block-destructive.sh" }] }
  ]
}
}

Skills and Plugins are the newest primitives, and the distinction is the actual point of confusion worth clearing up:

• A Skill is a markdown capability pack, a SKILL.md plus whatever supporting files it needs, that teaches Claude one specific procedure or domain on demand. Lightweight, droppable into a project or a user directory.
• A Plugin is an installable bundle: skills, subagents, hooks, MCP server config, and slash commands, packaged and versioned together, so a team can distribute its whole operating setup as one install instead of fifteen scattered files.

The practical framing: Skills are how you teach Claude one thing. Plugins are how you hand a new hire your entire setup in one command.

What "operational" actually means here

The pattern across all eight: stop using Claude Code as a smarter autocomplete. Start using it like a teammate you've onboarded, then like a system you've productionized. Plan mode is the kickoff meeting. Slash commands are the team conventions. Hooks are the CI guardrails. Subagents are the focused contributors. CLAUDE.md is the wiki. MCP is how that teammate gets read/write access to the systems your team actually runs. Headless mode is what happens when the teammate becomes a primitive other pipelines can call without a human in the loop. Managed settings, Skills, and Plugins are how all of that survives contact with more than one engineer: policy that doesn't rely on everyone remembering it, and a way to hand a new hire the whole operating setup in one install instead of a wiki page and good luck.

The trap is treating these as "advanced features for later." They're the difference between a chat window and infrastructure.