The Config That Makes Claude Code Feel Like a Teammate

In an earlier post I described building from my phone: a cheap always-on server, Tailscale, a terminal app, and Claude Code doing the actual work while I direct it in scattered minutes. A few people wrote back with a fair question. They installed Claude Code, tried it, and it felt more like fancy autocomplete than the teammate I described. What was I doing differently?

The honest answer is that a fresh install is only the starting point. The thing that behaves like a capable colleague is the layer I have built on top of it over months: the tools I gave it, the workflows it knows to reach for, the rules about what it can do without asking me, and the guardrails that catch its mistakes. None of it is complicated. It is all things any Claude Code user can set up, and all of it is worth copying. Here is what is actually in my setup.

MCP servers: giving the agent senses

Out of the box, Claude Code can read and write files and run commands. MCP servers extend that: each one plugs in a new capability, and the agent decides when to use it. This is the single biggest jump in usefulness, so it is where I would start.

The ones I lean on most:

Live documentation. An agent trained months ago will confidently use an API that changed last week. A docs server (I use Context7) pulls the current documentation for a library into the session on demand, so the code it writes matches the version I actually have installed rather than the one it half-remembers.
A real browser. I give Claude a real, controllable browser through Playwright, which I wrote about separately in giving Claude Code eyes. It can open a page, click through a flow, and check what actually rendered, and I can watch it happen and take over when it hits a login. For anything with a UI, this is the difference between guessing and knowing.
A lightweight way to read the web. Driving the full browser is overkill when I just need the agent to read a page. For that I run crawl4ai, which fetches a page and hands back clean, readable markdown instead of a wall of raw HTML. It is faster, it does not clutter the session with markup, and it is the right tool whenever the task is research rather than clicking. The browser is for acting on a page; this is for reading one.

There is one more that still feels like science fiction to me: a small server that lets a session place and receive real phone calls to run errands. That one deserves its own post, so I will leave it there.

The pattern to take away is that every MCP server you add is a new sense. Start with live docs and a browser. Those two alone change how much you can trust the output.

Skills: playbooks the agent reaches for

The second layer is skills. A skill is a packaged, named playbook for a kind of task: how to debug systematically, how to write tests first, how to plan a larger change before touching code. When a task matches, the agent loads the relevant playbook and follows it, so I get a consistent, considered approach instead of whatever the model improvises that day.

I run a collection called superpowers that covers most of my day to day: brainstorming a feature before building it, test-driven development, systematic debugging, writing and then executing a plan, splitting work across parallel sub-agents, using git worktrees, and running a code review before I merge. On top of that I have added and written my own for the patterns I hit repeatedly.

The benefit is not that I memorized forty workflows. It is the opposite. I describe what I want, and the agent picks the right playbook. The good habits are baked into the tools rather than dependent on me remembering to ask for them.

The agent brings in help

Something that surprised me is how much the agent can parallelize itself, and it maps neatly onto the teammate idea. Two things make it real.

Within a single task, Claude can split the work across sub-agents that run at the same time, each taking an independent slice and reporting back. A long serial job becomes several short ones happening at once. So a broad task like checking every page for the same issue fans out across workers instead of crawling through the files one by one.

For a bigger piece of work it can go further and stand up a whole separate session of its own: a fresh agent in its own workspace, handed a written brief, working in a safe read-only mode where it researches and proposes but changes nothing until I look in on it. I use that to park a meaty sub-topic with its own dedicated agent while I keep moving on the main thread, then review what it came back with.

Put that together with how I actually work, usually around twenty of these sessions running at once, one per project, each surviving a reboot, and “teammate” starts to undersell it. It is closer to a small team that all happens to be the same tool.

Auto-approve: deciding what it can do without me

This is the setting I have tuned more than any other, and it is the one that most changes how the whole thing feels. By default, an agent asks permission before most actions. Approve everything blindly and it is reckless. Approve nothing and you are back to babysitting a terminal, which defeats the point of working from a phone.

The rule I settled on is simple to say: auto-approve anything local and reversible, and stop to ask for anything that installs, publishes, deletes, or reaches out to the world.

In practice that means reading files, editing and writing code, running local commands, and searching the web all happen without interrupting me. But a specific set of actions always pauses for a yes:

Deleting or moving files, changing permissions
Anything that pushes or rewrites git history: git push, reset --hard, force-deleting a branch, rebases, merges
Creating or merging pull requests, or hitting the GitHub API
Cloud and infrastructure commands: aws, gcloud, terraform, kubectl, pushing a container image
Installing or publishing packages

That one boundary is why the loop feels fast without feeling dangerous. The agent moves freely inside the sandbox of my local repository, where any mistake is a git checkout away from undone, and it taps me on the shoulder the moment it wants to do something that leaves the machine or cannot be walked back. When I am directing five projects from my phone, I am not approving hundreds of file edits. I am approving the handful of moments that actually matter.

Hooks: guardrails that run themselves

Skills and permissions shape what the agent does. Hooks catch what slips through. A hook is a script that runs automatically at a certain point, and it can block an action if something is wrong.

My favorite is small and boring and has saved me many times. Before any commit in a TypeScript project, a hook runs the type checker, and if the code does not compile, it blocks the commit and hands the errors back to the agent to fix. The heart of it is just this:

# Only act on `git commit`, only in a TypeScript repo with a local tsc.
tsc --noEmit
if [ $? -ne 0 ]; then
  echo "tsc-gate: TypeScript errors found, commit blocked." >&2
  exit 2   # exit 2 blocks the action and shows the agent why
fi

The effect is that a broken commit simply cannot happen while I am not looking. The agent writes code, tries to commit, the gate catches a type error, and it fixes it and tries again, all without me. It is a few lines of shell, and it turns “trust the agent” from a leap of faith into something with a net under it.

CLAUDE.md: the memory that persists

The last piece is the least technical and easy to underrate. Claude Code reads a CLAUDE.md file for standing instructions, and I keep two layers of them.

A global one holds the rules I want everywhere: my responsive-design defaults, hard rules about never deleting protected git branches, coding discipline like matching the existing style of a file rather than imposing my own, and one line that pays for itself daily, do not ask me to do something you are capable of doing yourself. Then each project gets its own CLAUDE.md for local rules. This site’s file, for instance, tells the agent exactly how I want commit messages written for it.

Written down once, these stop being things I re-explain in every session. The agent starts each conversation already knowing how I work, which is most of what makes it feel less like a tool and more like someone who has been on the team a while.

The layer that makes the difference

None of this is a fresh install, and none of it happened in a day. It accumulated: a server added here, a permission rule tightened there, a guardrail written the day after something broke. But if you tried Claude Code and it felt like autocomplete, this is the gap. Give it senses through MCP servers, teach it playbooks through skills, draw a clear line around what it can do unattended, and put a few guardrails underneath. That is the difference between an agent you supervise and one you delegate to.

I am writing a separate step-by-step guide that walks through standing the whole environment up from scratch, and this configuration layer is where it ends up. If you want me to email you when it goes live, sign up below.

Notify me when the guide is out

If you run a setup of your own and configure it differently, I would genuinely like to compare notes. Use the contact form below or reach out on LinkedIn.