Your CLAUDE.md is the difference between Claude Code that guesses and Claude Code that knows your project. Here's how to write one that actually improves your output: THE BASICS CLAUDE.md is a markdown file at your project root. Claude Code reads it automatically at the start of every conversation. Think of it as persistent instructions that survive session resets. WHAT TO PUT IN IT 1. Build/test commands - The exact commands to build, test, and lint your project. Claude Code will use these instead of guessing. Example: - Build: npm run build - Test: npm test -- --watch - Lint: npm run lint:fix 2. Architecture decisions - Things that aren't obvious from the code. "We use server components by default." "Auth goes through middleware, not page-level checks." "The API layer is in /apps/api, not /src/api." 3. Code style rules - Preferences Claude Code can't infer. "No barrel exports." "Use named exports, not default." "Error messages go in /lib/errors.ts, not inline." 4. What NOT to do - Negative constraints are powerful. "Never add Co-Authored-By to commits." "Don't use chore: prefix." "Don't add comments to unchanged code." WHAT NOT TO PUT IN IT - Secrets or tokens (it's committed to git) - Entire API documentation (too long, dilutes focus) - Things obvious from package.json or tsconfig THE STRUCTURE THAT WORKS Keep it under 200 lines. Start with build commands, then architecture, then style rules, then constraints. Claude Code reads the whole thing every time, so every line costs attention. LEVEL UP: NESTED CLAUDE.md You can put CLAUDE.md files in subdirectories. Claude Code reads the one closest to the file it's working on. Use this for monorepos: - /CLAUDE.md (repo-wide rules) - /apps/api/CLAUDE.md (API-specific patterns) - /apps/web/CLAUDE.md (frontend-specific patterns) THE TEST After writing your CLAUDE.md, start a fresh Claude Code session and ask it to make a small change. If it follows your conventions without being told, it's working. If it doesn't, your CLAUDE.md needs to be more specific.

Most people use Claude Code the same way they use a chatbot — type a prompt, watch it work, respond to questions, babysit the output. That's fine for one-off fixes. But it doesn't scale. Here's the pattern I've been running instead: Claude Code as a background agent you dispatch tasks to, then walk away. The setup is simple: 1. Invoke Claude Code with --print and --permission-mode bypassPermissions 2. Pass a task description on stdin or as a prompt 3. It runs to completion and exits — no TTY required 4. Pipe the output wherever you need it (Telegram, log file, another agent) Example command: claude --print --permission-mode bypassPermissions "Fix the failing test in auth_service.py and commit the result" That's it. Claude reads the codebase, finds the test, fixes it, commits, and exits. You get a message when it's done. Where it gets powerful: • Schedule via cron — "every weekday at 9am, review open GitHub issues and draft fixes" • Chain agents — one agent researches, another implements, another reviews • Run multiple in parallel — different tasks on different branches simultaneously • Trigger on events — new PR opens, run a review agent automatically The key mindset shift: Claude Code is not a chat interface. It's a programmable worker. Once you stop treating it like a chatbot and start treating it like a subprocess, the whole thing opens up. What are you currently babysitting that you could delegate to a background agent?

I just published a full walkthrough on building an MCP server in Python from scratch. If you haven't touched MCP yet — it's simpler than it sounds. An MCP server is a JSON-RPC service that exposes tools to Claude. You define functions, Claude discovers them, picks the right one based on context, and your code runs. That's the entire pattern. Python is the fastest path to a working server. The FastMCP library gets you from zero to a running server in about 30 lines. You define a tool with a decorator, add a description so Claude knows when to use it, and start the server. Done. The pattern looks like this: - You write Python functions and mark them as tools - Claude connects to your server and sees what's available - When a user asks something relevant, Claude calls your tool automatically - Your code runs, returns results, Claude uses them in its response No middleware. No routing logic. No prompt engineering to get Claude to use your tool — it just works because MCP is a standard protocol that Claude speaks natively. I built my first MCP server to pull YouTube analytics. Took about an hour from "what is MCP" to "Claude is reading my channel stats." The second one took 20 minutes. Once you see the pattern, you can wrap any API or script as a tool Claude can use. The walkthrough covers setup, tool definitions, testing locally, and connecting to Claude Code. Full post here: https://kjetilfuras.com/build-mcp-server-in-python/ Full code in the post. Drop questions below.

I stopped opening Canva for thumbnails about two months ago. Every thumbnail on my YouTube channel is now generated by a Python script. One command, ~10 seconds, done. Here's the stack: - Gemini generates the background image from a text prompt. Cinematic, saturated, 16:9. No stock photos, no searching, no licensing. - Pillow (Python) handles the text overlay. Impact font at ~130px, thick black outline for readability on any background. - Color-highlighted keywords draw the eye. You tag a word in the title and it renders in a different color with a glow effect behind it. The rest stays white. - Vignette darkens the edges so the text pops in the center. - Output: 1280x720, exactly what YouTube wants. The whole thing runs from one command with a --title flag and an optional --subtitle. No templates, no layers, no drag-and-drop. Why no face? I tested both. For the topics I cover (space/science Shorts, automation), faceless thumbnails with bold text and dramatic backgrounds perform the same or better. One less variable to manage. What I learned building this: 1. Short punchy titles crush long question-format titles. "NEUTRON STARS COLLIDE" beats "What Happens When Neutron Stars Collide?" every time. 2. The Gemini prompt matters. Adding "do NOT include any text in the image" prevents the AI from baking words into the background — which ruins the overlay. 3. Thick outlines are non-negotiable. Without them, white text disappears on bright backgrounds. The script draws the outline pixel by pixel in a radius around each character. The script also supports an avatar cutout mode (face extracted with rembg, composited with a drop shadow) but I keep it off for my content. Total cost: $0. Gemini API is free tier. Pillow is open source. The only investment was writing the script. Want the exact Python script and setup instructions? Comment below or DM me and I'll send them over. More on automating content pipelines: https://kjetilfuras.com/blog-automation/

Every Claude Code session has a single context window. The longer you work, the more it fills with search results, file contents, and exploration noise. Subagents fix this. A subagent runs in its own context window. It does the work, returns a summary, and the exploration stays out of your main conversation. Think of it as handing a task to a colleague who reports back with the answer, not the journey. Claude Code ships with three built-in subagents: - Explore — runs on Haiku (fast, cheap), read-only. Use it for file discovery and codebase search without polluting your main context. - Plan — read-only research agent that gathers context before presenting a plan. Activates automatically in plan mode. - General-purpose — full tool access, inherits your model. For complex multi-step tasks that need both reading and writing. You can also define custom subagents. They're markdown files with YAML frontmatter — same format as skills. Drop one in ~/.claude/agents/ and it's available in every project. What makes custom subagents powerful: 1. You control which tools they can access (read-only reviewer, write-capable fixer, etc.) 2. You can route them to cheaper models — Haiku for exploration, Sonnet for analysis 3. Each gets a focused system prompt so it stays on task 4. They can't spawn other subagents, which prevents infinite nesting The mental model: delegate when the side work would flood your context with stuff you won't reference again. Research, verification, batch processing, code review — all good candidates. Keep implementation and decision-making in your main session. One detail worth knowing: subagents work within a single session. If you need multiple agents running in parallel and communicating with each other, that's agent teams — a different pattern entirely. Full docs: https://code.claude.com/docs/en/sub-agents I wrote a deeper walkthrough on skills and agent architecture here: https://kjetilfuras.com/claude-code-agent-skills/