The Claude Code Setup Guide That Made Me Rethink Everything

affaan (@affaanmustafa) won an Anthropic hackathon and has used Claude Code daily for 10 months. His full configuration is published as a GitHub repo, and the gap it reveals between typical setups and well-tuned ones is not a model problem. It is a configuration problem.

The guide’s core message is subtractive: not more, but exactly what you need. That’s harder to follow than it sounds.

The 200K Context Window Is a Myth: The Real Number Is 70K

Claude Code’s 200K context window is a theoretical maximum. Load too many MCP servers and plugins simultaneously, and your usable context drops to around 70K. affaan’s solution is to configure 14 MCP servers but only activate 5-6 per project, keeping fewer than 80 tools enabled at once.

His actual config includes GitHub, Supabase, Vercel, Railway, the Cloudflare series, ClickHouse, and more. The unused ones are explicitly disabled via disabledMcpServers. After adopting this pattern myself, response quality improved noticeably, specifically on tasks that require the model to reason across multiple files. The degradation from context bloat is real and easy to miss because it’s gradual.

Skills, Hooks, and Subagents: Role Separation Is the Key

These three concepts are confusing at first, but the distinction matters. Skills live in ~/.claude/skills and let you run an entire workflow with a single command like /refactor-clean. Hooks are event-driven automation: auto-format with Prettier after editing .ts files, warn on console.log statements, and similar checks. The hookify plugin lets you generate hooks through conversation rather than writing them manually. Subagents live in ~/.claude/agents and handle delegated tasks with dedicated roles, such as planner, architect, tdd-guide, and security-reviewer.

affaan places hooks at three execution points: PreToolUse, PostToolUse, and Stop, automating formatting, type checking, and security audits. Boris Cherny’s workflow uses the same pattern. When two independent practitioners converge on the same structure, it’s worth paying attention to.

mgrep, Git Worktrees, and Zed Editor

Three practical tools affaan uses daily are worth understanding individually.

mgrep is more accurate than ripgrep for code search and has built-in web search support. A single command like /mgrep 'function handleSubmit' searches both local files and the web simultaneously, which matters when you’re trying to understand how a library function is used across the ecosystem, not just in your repo.

For working on multiple features simultaneously, git worktrees let you create independent checkouts and run Claude Code in each one. You can also use /fork to branch conversations. There’s ongoing debate about whether worktrees or repo clones are the better approach; both have trade-offs depending on your workflow, and neither is clearly superior in all cases.

Zed Editor is built on Rust, so it stays lightweight under load. The Agent Panel tracks Claude’s file modifications in real time, and CMD+Shift+R executes custom commands instantly. It’s not a requirement, but it pairs well with the rest of this setup.

Rules Structure for Consistency

Modularizing ~/.claude/rules by concern keeps things maintainable as the project grows. affaan uses separate files for security (no hardcoded secrets), coding-style (immutability, file structure guidelines), testing (TDD workflow, 80% coverage minimum), git-workflow (commit message format), and performance (model selection criteria).

Rules like “never commit console.log” belong here, enforced by a Stop hook that audits changes before they ship. The automation catches mistakes that code review misses, not because reviewers are careless, but because humans are inconsistent under deadline pressure.

The Five Core Principles

affaan’s philosophy comes down to five points. Treat configuration like fine-tuning, not architecture: small, targeted adjustments beat sweeping overhauls. The context window is a finite resource, so disable anything not actively in use. Parallel execution via /fork and worktrees compounds the throughput of a single developer meaningfully. Hooks eliminate manual steps that slow you down. Subagents need narrow, well-defined responsibilities; the broader the scope, the lower the reliability.

Excessive configuration is counterproductive, and subtracting is the hardest part for most people. The instinct is to add more tools, more servers, more rules. This guide pushes back on that instinct with specifics.

One note from my own usage: for browser automation, Vercel’s agent-browser has been more stable than Playwright in the tasks I’ve thrown at it. That’s a narrow data point, and your mileage will vary depending on what you’re automating.

The full setup is on affaan’s GitHub repository. The value isn’t in copying it wholesale; it’s in understanding why each choice was made, then deciding which constraints apply to your own project.