Claude Code setup - Feb 2026 edition

Introduction

AI tooling is moving incredibly fast—a setup that works today might look completely different in a month (or even a week). I want to document how I'm using Claude Code right now: the rules, the workflows, and the patterns I've formed after using it daily the last few months. I plan to publish updated editions as my setup evolves.

Teach It Your Codebase with Rules Files

If there's one thing I'd recommend, it's writing rules files. This has been the single highest-leverage investment I've made in Claude Code.

Rules files are markdown documents that live in your project's .claude/rules/ directory. Claude reads them automatically and uses them as context when working in your codebase. I think of them as onboarding docs—except the new hire actually reads every word, every time.

For more details, see the official docs on memory & project rules.

Organize rules by concern

A flat list of rules gets unwieldy fast. Here's roughly how I structure mine:

.claude/rules/
├── conventions/
│   ├── typescript.md
│   ├── styling.md
│   └── naming.md
├── patterns/
│   ├── data-fetching.md
│   ├── error-handling.md
│   └── testing.md
├── apps/
│   ├── web-app.md
│   └── api-server.md
└── packages/
    └── ui-library.md

Each file focuses on one area—TypeScript conventions, styling rules, and so on. And each file is concise, max ~50 lines each. This keeps things easy to find & update.

I've found that code examples work better than prose descriptions. My data-fetching rule, for instance, is about 30 lines, mostly code, defining a 3-layer architecture (entities → API → queries). Claude follows it more consistently than it would a paragraph explaining the same thing.

Scope rules with paths

Use the paths frontmatter field to scope rules to specific files. Rules with paths only load when Claude is working with matching files. Rules without paths load unconditionally.

For example, here's a snippet of my styling rules:

---
paths:
  - "src/{blocks,components}/**/*.tsx"
---

# Styling

## Semantic Tokens

Use semantic tokens, not color scales:

```tsx
<div className="bg-muted text-muted-foreground">  // Good
<div className="bg-gray-500">  // Bad
```

## Icons

- Use `@tabler/icons-react`
- Never create manual SVG icons

The rules are only applied to React component files that are located in the blocks/ or components/ folders, which keeps context focused.

Treat rules as living documents

When Claude produces output that doesn't match my expectations, I update the rule rather than re-explain it every time. Rules files aren't something you write once and forget. They evolve with your project.

Plan Before You Build

I use plan mode for anything non-trivial.

This matters because:

• It prevents wasted effort. Without a plan, Claude might build a feature using patterns that conflict with your existing architecture—wrong directory, wrong state management approach, missed abstractions. A short planning phase catches these mismatches before you're staring at a diff that needs to be thrown away.
• It catches architectural issues early. During planning, Claude surfaces things I might not have considered—"this component already handles that case" or "the existing API doesn't support that query pattern." I'd rather have those conversations before code gets written.
• It creates a decision record. Every plan file is a lightweight architectural decision record. I have dozens of plan files across my projects at this point. They're more useful than documentation I could have written after the fact because they capture the reasoning, not just the result.

When to skip planning: Single-file changes, obvious bug fixes, and quick refactors don't need a plan.

Where plans live

I keep plans as markdown files in a .wip/ folder while I'm actively iterating on them. Once a plan stabilizes, I move it into Notion so it's easier to share with others. If I need to reference that plan later during implementation, I use the Notion MCP to pull it back in as context.

What a plan looks like

A typical plan starts with a problem statement, lists goals, sketches the flow (what components or endpoints are involved), and ends with open questions. Having that structure means Claude and I are aligned before any code gets written.

The mental shift is recognizing that planning isn't overhead—for non-trivial work, it's where the hard thinking happens. Implementation is mostly mechanical. Once I'm satisfied with a plan, I auto-accept every change—something I never would have done before investing in rules and plans.

Extending Claude Code

Rules and plans set the foundation. Plugins, skills, and MCP integrations take it further. Here's what I'm using right now.

Plugins & skills:

• Superpowers—the brainstorming skill is the one I am using the most. Before planning any feature, I run it to think through requirements and intent. It asks questions I'd skip if I jumped straight to implementation, and it pairs naturally with Claude's native plan mode: brainstorm first, then enter plan mode with a clearer picture of what I'm building.
• Code review—this one works well because of rules files. The review agents read the same conventions used to write the code, so it catches things like "you used a raw string concatenation instead of cn()" or "this loader doesn't follow the 3-layer pattern." It's a second pair of eyes that already knows how my codebase works.
• Code simplifier—I run this after generating code to clean up anything that feels over-engineered or verbose.

Language servers: I have LSPs enabled for TypeScript and Python. They give Claude real-time type checking as it writes code, so type errors get caught during generation instead of surfacing later when I try to build.

MCPs:

• Notion—this ties back to the plan workflow. Once a plan stabilizes and I move it to Notion, I can pull it back in during implementation without copy-pasting. Claude reads the Notion page directly and has the full context of what we decided.
• Figma—I actually use this more for FigJam diagrams of the software architecture than for design implementation. The generated diagrams are easier to read and share with others than what's created in pure markdown.

Screenshots: Sometimes the fastest way to give Claude context is a screenshot. If something looks off in the UI, I'll take a screenshot and drop it into the conversation so Claude can see exactly what I'm seeing. I also screenshot Figma designs when I want to communicate a visual direction without pulling in the full MCP integration—I find it quicker for one-off references.

Takeaways

My setup keeps evolving. I'm still finding the right balance between giving Claude enough context and overloading it with things it doesn't need for a given task. But the pattern that is currently working for me so far: invest in context upfront, plan before building, and review everything.

I'm curious to see how my setup will change in the coming weeks and months.