Power Using Claude Code

Three install paths

Claude Code ships in three flavors. All three run the same underlying engine and share the same CLAUDE.md, skills, permissions, MCPs, and memory. They differ only in interface.

Pick the one that matches the editor you already live in. The rest of this page applies regardless of which path you choose.

Sign in

First run prompts you to authenticate. Three options:

• Claude.ai account (Pro or Max plan). OAuth flow in your browser. Easiest for individuals.
• Anthropic API key from console.anthropic.com. Pay-as-you-go pricing. Useful if your workplace VPN breaks the OAuth flow.
• Enterprise: AWS Bedrock, Google Vertex, or your company's Claude gateway. Set the relevant environment variables per your org's docs.

Drop in your first CLAUDE.md

Before you do anything else in a new repo, create a CLAUDE.md file at the root. Even a 10-line version pays off immediately:

Or run the built-in /init command inside Claude and it'll generate a starter CLAUDE.md for you based on the repo it sees.

Common gotchas in the first week

Skip the prompt storm with permissions

By default Claude Code asks before running shell commands, editing files, or hitting the web. The first day feels like a firewall. Two ways to reduce the prompts:

• Approve as you go. When prompted, choose "Always allow" for safe commands. After a few sessions the prompts get rare.
• Pre-populate settings.json. Add a permissions.allow array with the commands you trust:

There are also tools that automate this. The fewer-permission-prompts skill (and others like it) scans your past sessions for commands you keep approving and writes them to settings.json for you. Conservative defaults are good. The point is to skip the prompts you would always click yes to anyway, not to disable safety.

Claude Code becomes a coworker the moment it can read your calendar, post to Slack, query your database, browse the web, edit your repos, transcribe your meetings, and trigger your deploys.

Most of that ships free as MCPs (Model Context Protocols). The rest is a 20-line skill away.

If you find yourself copy-pasting from one tool into Claude and then copy-pasting Claude's output into another tool, you have already failed. Wire it directly.

What you can wire in

Anything with an API or CLI is reachable. Common categories:

• Calendar and email (Google Workspace, Outlook)
• Chat (Slack, Teams, Discord)
• Code hosts (GitHub, GitLab, Bitbucket)
• Databases (Supabase, Postgres, SQL Server)
• Browser automation (Playwright, Puppeteer, Chrome DevTools)
• Cloud platforms (Cloudflare, Netlify, Azure, AWS)
• Audio recording and transcription (Plaud, Otter)
• Secret managers (1Password, Vault, environment files)

You are connecting a powerful automation tool to admin tasks. Treat the access boundary the way you would for a junior employee: give it the systems it needs to do the work, withhold the ones where the blast radius is too high, and audit what it does.

Skills turn multi-tool workflows into one-line invocations

Skills (slash commands) are reusable workflows. Each is a markdown file with a prompt and a few rules. Examples of what people define:

They exist because typing the long version was annoying enough that defining the skill paid back inside a week.

Plugins bundle skills, hooks, and commands

Plugins are how power-user setups travel. A plugin is a bundle of skills, hooks, and commands shipped as one installable unit. The Claude ecosystem has plugins for code review, git operations, Supabase work, browser automation, and more. Install one and you inherit a small workflow library someone else built.

You can also publish your own. Once you have ~5 skills you reuse across projects, packaging them as a plugin is the difference between you having a personal stash and your team having a shared toolkit.

Your runtime is the privileged environment. The AI is a process running inside it.

This inverts the usual framing. AI is not replacing you. AI is a userspace program that calls your kernel only when it needs to touch a system it cannot reach: production credentials, your physical signature, a judgment call about a client relationship. The AI is compute. The human is the kernel.

That makes one habit non-negotiable: when the AI keeps asking you to do things it could do itself, tell it to knock it off.

Every time you do work the AI could have done, you train it to keep deferring. Every time you push back, you train it to use the privileges it has.

The same principle applies in reverse. When something genuinely needs the kernel (your credentials, your signature, your judgment), the AI delegates and waits. That handoff is the system working correctly. The handoff for things the AI could do itself is the system being lazy.

Sub-processes: the same idea, one layer down

The AI can spawn its own sub-processes (subagents) for the same reason you delegate to it: a sub-process protects the parent context.

Why subagents matter:

• Save tokens. A research task that reads 30 files in a subagent returns 200 words to the main thread. The same task in the main thread eats your whole session.
• Parallelize work. Three independent questions can run as three subagents at once. The main thread waits for all three answers, then proceeds.
• Stay specialized. Some subagents are tuned for one job (code search, security review, planning). They beat general-purpose for their specialty.
• Quarantine bad context. If a research thread goes down a rabbit hole, the subagent absorbs the mess and you only see the final answer (or the failure).

When to send one: any time you catch yourself thinking "let me check..." Stop and consider whether you can hand it off and keep your main thread clean.

Documentation is not overhead. It is the persistence layer for AI collaboration.

Every session starts cold. The model has no memory of what you decided last week, why you rejected the obvious approach, who the stakeholders are, or what the constraints really are. The documentation IS that memory. Without it, you re-explain the project on every session and the AI guesses at the parts you skipped.

The good news: AI is excellent at writing the documentation it needs. Ask it to summarize your decisions, draft the ADR, write the runbook, capture the architecture. Read what it wrote, fix what is wrong, commit. Docs are rocket fuel for AI, and AI is rocket fuel for docs.

The minimum viable doc layer

• CLAUDE.md / AGENTS.md at the repo root: who you are, what the project is, your style, your hard rules. The AI reads this on every session start. The filename depends on the tool — Claude Code reads CLAUDE.md, other agents (Cursor, Cline, Aider) read AGENTS.md or .cursorrules. Same idea, different filename. Some tools read both. Mine is ~400 lines. Yours can start at 20.
• STATE.md at the root: current blockers, in-flight decisions, what changed last session, what needs to happen next.
• ADRs in docs/adr/: why we chose X over Y. Dated. Immutable. Supersede, never delete.
• Wiki / notes: people, projects, domain concepts, anything that took time to learn the first time.

CLAUDE.md vs memory: not the same thing

These get conflated. They are different mechanisms with different purposes.

• CLAUDE.md is the repo handshake. Lives in the project, gets committed, applies to anyone working in that repo. Use it for project context, conventions, and shared rules.
• Memory is personal and persistent. Lives outside the repo (Claude Code stores it under ~/.claude/projects/.../memory/), auto-loads at session start, and follows you across every session in that project. Use it for things about you — your preferences, lessons learned, things to never do again — rather than about the project.

A correction like "Medallus runs on Azure" goes in CLAUDE.md (project fact, applies to anyone). A correction like "Bert prefers tables over prose" goes in memory (personal preference, follows you everywhere).

Sample CLAUDE.md fragment:

The rule that matters most

Every time you correct the AI, write down the correction. Whatever made you frustrated this session is what will make you frustrated next session unless you capture it.

Real entries from mine:

Each is one line. Each kills a recurring frustration.

Everything in version control. Including the notes about how to use the AI.

This sounds obvious. Most people do not do it. They run the AI inside one giant uncommitted folder. They lose work to a bad refactor and have no way to recover. They cannot answer "what did this look like last week?" They cannot share context with another collaborator (human or AI) without manual export.

What "use repos" means in practice

• Every project, even small ones, gets a git repo. git init on day one, not day thirty.
• Every meaningful change gets a commit. Atomic. Reviewable. Revertable.
• Push to GitHub. Local-only repos protect against nothing.
• Even your notes are a repo. Mine has hundreds of commits and a real history.
• Branches for experiments. Merge what works, delete what does not.
• Pull requests even when you are working solo. The PR view is a sanity check the AI cannot give you.

AI works dramatically better with version control. It can see the diff. It can read the commit history. It can trace why a file looks the way it does today. It can diff against any prior state to answer "what did this used to do?" Without git, you and the AI are both flying blind in a single mutable folder.

Combined with documentation (Section 4), the repo becomes the project's persistent brain. Code, decisions, and history all live in one place the AI can read on demand.

Default AI output is too long. Your job is to cut.

The model was trained on academic writing, marketing copy, and corporate documentation. All three reward verbosity. Without intervention you will get five sentences where one would do, three adjectives where none belong, and a thoughtful closing paragraph that restates the thing you just read.

You are the editorial check. Teach it explicitly. A line for your CLAUDE.md:

Reinforce the rule every time the AI reverts. Reversion happens often, especially in long-form pages, proposals, and anything emailed to executives. Those formats pull the model toward thought-leadership voice.

Tells to kill on sight

• Setup paragraphs ("Most people..." / "In today's world...")
• Triplet rhythms ("no clever prompt, no secret setting, no hidden flag")
• Pull quotes that summarize what you just said
• Closing aphorisms ("That's the whole game.")
• "Your future self will thank you"
• Em dashes used as a rhetorical device
• Any sentence that adds nothing to the previous sentence

If you tolerate verbose output, you ship verbose output. If you want Claude to work in your style and write in your voice, you have to configure it to do so.

The page above uses words that mean specific things. Here is the short version, plus the prompt habits that go with them.

Terms

How to talk to AI

• Direct, declarative. "Add a button to the header" beats "could you maybe add a button?" Politeness wastes tokens and signals you don't expect compliance.
• Be specific. Name files, paste error messages verbatim, give exact strings when wording matters. Vague input gets generic output.
• Tell it what NOT to do. Negative space is information. "Don't change the styles" or "don't add tests for this" prevents whole categories of unwanted output.
• Quote yourself. If exact phrasing matters, hand it the phrasing. "Use this verbatim: ..." is faster than describing what you want.
• Push back. When the output is wrong, lazy, or off-voice, say so plainly. The model adjusts. Tolerating mediocre output trains it that mediocre is acceptable.
• Plan before big changes. "List the files you plan to edit and what changes go in each. Wait for my OK." Catches divergence before code is written.
• Ask for summaries. Long sessions drift. "Summarize what we've decided in this session" is both a memory check and a context compactor.