Claude-code

• With AI agents, the cost of writing tests is approaching zero. Five words: “write tests on new code.” The excuses are running out.

  Are you verifying the tests your AI writes, or just trusting the green checkmarks?

  Mar 12, 2026 / Programming / Testing / Claude-code

• Wrote a guide on writing a good CLAUDE.md. Takeaway: keep it under 200 lines. Every line loads into context every session, so bloat costs real tokens.

  How are you handling multiple AI context files across tools?

  Mar 11, 2026 / Programming / Tools / Claude-code

• Python: If your CLI tool uses print() and gets called as a subprocess by Claude Code, the output now gets swallowed. The parent process captures it. Structured logging will fix it.

  Mar 8, 2026 / Programming / Claude-code / Debugging

• How to Write a Good CLAUDE.md File

  Every time you start a new chat session with Claude Code, it’s starting from zero knowledge about your project. It doesn’t know your tech stack, your conventions, or where anything lives. A well-written CLAUDE.md file fixes that by giving Claude the context it needs before it writes a single line of code.

  This is context engineering, and your CLAUDE.md file is one of the most important pieces of it.

  Why It Matters

  Without a context file, Claude has to discover basic information about your project — what language you’re using, how the CLI works, where tests live, what your preferred patterns are. That discovery process burns tokens and time. A good CLAUDE.md front-loads that knowledge so Claude can get to work immediately.

  If you haven’t created one yet, you can generate a starter file with the /init command. Claude will analyze your project and produce a reasonable first draft. It’s a solid starting point, but you’ll want to refine it over time.

  The File Naming Problem

  If you’re working on a team where people use different tools: Cursor has its own context file, OpenAI has theirs, and Google has theirs. You can easily end up with three separate context files that all contain slightly different information about the same project. That’s a maintenance headache.

  It would be nice if Anthropic made the filename a configuration setting in settings.json, but as of now they don’t. Some tools like Cursor do let you configure the default context file, so it’s worth checking.

  My recommendation? Look at what tools people on your team are actually using and try to standardize on one file, maybe two. I’ve had good success with the symlink approach , where you pick your primary file and symlink the others to it. So if CLAUDE.md is your default, you can symlink AGENTS.md or GEMINI.md to point at the same file.

  It’s not perfect, but it beats maintaining three separate files with diverging information.

  Keep It Short

  Brevity is crucial. Your context file gets loaded into the context window every single session, so every line costs tokens. Eliminate unnecessary adjectives and adverbs. Cut the fluff.

  A general rule of thumb that Anthropic recommends is to keep your CLAUDE.md under 200 lines. If you’re over that, it’s time to trim.

  I recently went through this exercise myself. I had a bunch of Python CLI commands documented in my context file, but most of them I rarely needed Claude to know about.

  We don’t need to list every single possible command in the context file. That information is better off in a docs/ folder or your project’s documentation. Just add a line in your CLAUDE.md pointing to where that reference lives, so Claude knows where to look when it needs it.

  Maintain It Regularly

  A context file isn’t something you write once and forget about. Review it periodically. As your project evolves, sections become outdated or irrelevant. Remove them. If a section is only useful for a specific type of task, consider moving it out of the main file entirely.

  The goal is to keep only the information that’s frequently relevant. Everything else should live somewhere Claude can find it on demand, not somewhere it has to read every single time.

  Where to Put It

  Something that’s easy to miss: you can put your project-level CLAUDE.md in two places.

  • ./CLAUDE.md (project root)
  • ./.claude/CLAUDE.md (inside the .claude directory)

  A common pattern is to .gitignore the .claude/ folder. So if you don’t want to check in the context file — maybe it contains personal preferences or local paths — putting it in .claude/ is a good option.

  Rules Files for Large Projects

  If your context file is getting too large and you genuinely can’t cut more, you have another option: rules files. These go in the .claude/rules/ directory and act as supplemental context that gets loaded on demand rather than every session.

  You might have one rule file for style guidelines, another for testing conventions, and another for security requirements. This way, Claude gets the detailed context when it’s relevant without bloating the main file.

  Auto Memory: The Alternative Approach

  Something you might not be aware of is that Claude Code now has auto memory, where it automatically writes and maintains its own memory files. If you’re using Claude Code frequently and don’t want to manually maintain a context file, auto memory can be a good option.

  The key thing to know is that you should generally use one approach or the other. If you’re relying on auto memory, delete the CLAUDE.md file, and vice versa.

  Auto memory is something I’ll cover in more detail in another post, but it’s worth knowing the feature exists. Just make sure you enable it in your settings.json if you want to try it.

  Quick Checklist

  If you’re writing or revising your CLAUDE.md right now, here’s what I’d focus on:

  • Keep it under 200 lines — move detailed references to docs
  • Include your core conventions — package manager, runtime, testing approach
  • Document key architecture — how the project is structured, where things live
  • Add your preferences — things Claude should always or never do
  • Review monthly — cut what’s no longer relevant
  • Consider symlinks — if your team uses multiple AI tools
  • Use rules files — for detailed, task-specific context

  That’s All For Now. 👋

  Mar 6, 2026 / AI / Programming / Claude-code / Developer-tools

  Enjoyed this?

• Claude Code Skills vs Plugins: What's the Difference?

  If you’ve been building with Claude Code, you’ve probably seen the terms “skill,” “plugin,” and “agent” thrown around. They’re related but distinct concepts, and understanding the difference will help you build better tooling. Let’s focus on skills versus plugins since those two are the most closely related.

  Skills: Reusable Slash Commands

  Skills are user-invocable slash commands, essentially reusable prompts that run directly in your main conversation. You trigger them with /skill-name and they execute inline. They can be workflows or common tasks that are done frequently.

  Skills can live inside your .claude/skills/ folder, or they can live inside a plugin (where they’re called “commands” instead). Same concept, different home.

  The important frontmatter you should pay attention to is the allowed-tools property. This defines which tool calls the skill can access, and there are three formats you can use:

  1. Comma-separated names — Bash, Read, Grep
  2. Comma-separated with filters — Bash(gh pr view:*), Bash(gh pr diff:*)
  3. JSON array — ["Bash", "Glob", "Grep"]

  I don’t think there’s a meaningful speed difference between them? The filtered format might take slightly longer to parse if you have a huge list, but in practice it’s negligible. Pick whichever is most readable for your use case.

  The real power here is that skills can define tool calls and launch subagents. That turns a simple slash command into something that can orchestrate complex workflows.

  Plugins: The Full Package

  A plugin is a bigger container. It can bundle commands (skills), agents, hooks, and MCP servers together as a single distributable unit. Every plugin needs a .claude-plugin/plugin.json file; which is just a name, description, and author.

  Plugins are a good way to bundle agents with skills. If your workflow needs a specialized agent that gets triggered by a slash command, a plugin is a good option for that.

  Pushing the Boundaries of Standalone Skills

  However, I wanted to experiment with what’s actually possible using standalone skills, so I built upkeep. It turns out that you can bundle actual compiled binaries inside a skill directory and call them from the skill. That opens up a lot of possibilities.

  Here’s how I did it:

  • The skill has a prerequisite section that checks for a bin/ folder containing the binary
  • A workflow calls the binary, passing in the commands to run
  • Each step defines what we expect back from the binary

  You can see the full implementation in the SKILL.md file. It’s a pattern that lets you distribute real functionality, not just prompts, through the skill.

  Quick Summary

  • Skills are slash commands. Reusable prompts with tool access that run in your conversation.
  • Plugins bundle skills, agents, hooks, and MCP servers together with a plugin.json.
  • Skills are more flexible than you might expect, you can call subagents, distribute binaries, and build real workflows.

  If you’re just getting started, skills are the easier entry point. When you need to package multiple pieces together or distribute agents alongside commands, that’s when you reach for a plugin.

  Have fun building!

  Mar 5, 2026 / AI / Development / Claude-code

  Enjoyed this?

• Claude Code Now Has Two Different Security Review Tools

  If you’re using Claude Code, you might have noticed that Anthropic has been quietly building out security tooling. There are now two distinct features worth knowing about. They sound similar but do very different things, so let’s break it down.

  The /security-review Command

  Back in August 2025, Anthropic added a /security-review slash command to Claude Code. This one is focused on reviewing your current changes. Think of it as a security-aware code reviewer for your pull requests. It looks at what you’ve modified and flags potential security issues before you merge.

  It’s useful, but it’s scoped to your diff. It’s not going to crawl through your entire codebase looking for problems that have been sitting there for months.

  The New Repository-Wide Security Scanner

  Near the end of February 2026, Anthropic announced something more ambitious: a web-based tool that scans your entire repository and operates more like a security researcher than a linter. This is the thing that will help you identify and fix security issues across your entire codebase.

  First we need to look at what already exists to understand why it matters.

  SAST tools — Static Application Security Testing. SAST tools analyze your source code without executing it, looking for known vulnerability patterns. They’re great at catching things like SQL injection, hardcoded credentials, or buffer overflows based on pattern matching rules.

  If a vulnerability doesn’t match a known pattern, it slips through. SAST tools also tend to generate a lot of false positives, which means teams start ignoring the results.

  What Anthropic built is different. Instead of pattern matching, it uses Claude to actually reason about your code the way a security researcher would. It can understand context, follow data flows across files, and identify logical vulnerabilities that a rule-based scanner would never catch. Think things like:

  • Authentication bypass through unexpected code paths
  • Authorization logic that works in most cases but fails at edge cases
  • Business logic flaws that technically “work” but create security holes
  • Race conditions that only appear under specific timing

  These are the kinds of issues that usually require a human security expert to find or … real attacker.

  SAST tools aren’t going away, and you should still use them. They’re fast, they catch the common stuff, and they integrate easily into CI/CD pipelines.

  Also the new repository-wide security scanner isn’t out yet, so stick with what you got until it’s ready.

  Mar 4, 2026 / DevOps / AI / Claude-code / security

  Enjoyed this?

• Ever wanted your CLAUDE.md to automatically update from your current session before the next compact? There’s a skill for that and it’s been helpful. In case you missed it, here’s a link to the skill:

  autoskill

  Mar 3, 2026 / AI / Claude-code

• Managing Your Context Window in Claude Code

  If you’re using Claude Code, there’s a feature you should know about that gives you visibility into how your context window is being used. The /context skill breaks everything down so you can see exactly where your tokens are going.

  Here’s what it shows you:

  • System prompt – the base instructions Claude Code operates with
  • System tools – the built-in tool definitions
  • Custom agents – any specialized agents you’ve configured
  • Memory files – your CLAUDE.md files and auto-memory
  • Skills – any skills loaded into the session
  • Messages – your entire conversation history

  Messages is where you have the most control, and it’s also what grows the fastest. Every prompt you send, every response you get back, every file read, every tool output; it all shows up in your message history.

  Then there’s the free space, which is what’s left for actual work before a compaction occurs. This is the breathing room Claude Code has to think, generate responses, and use tools.

  You’ll also see a buffer amount that’s reserved for auto-compaction. You can’t use this space directly, it’s set aside so Claude Code has enough room to summarize the conversation and hand things off cleanly.

  Why This Matters

  Understanding your context usage helps you work more efficiently. A few ways to keep your context lean:

  • Start fresh sessions for new tasks instead of reusing a long-running one
  • Be intentional about file reads — only read what you need, not entire directories
  • Use sub-agents — when you delegate work to a sub-agent, it runs in its own context window instead of yours. All those file reads, tool calls, and intermediate reasoning happen over there, and you just get the result back. It’s one of the best ways to preserve your primary context for the work that actually needs it.
  • Trim your CLAUDE.md — everything in your memory files loads every session, so keep it tight

  I’ll dig into sub-agents more in a future post. For now, don’t forget about /context

  Mar 2, 2026 / AI / Claude-code / Developer-tools

  Enjoyed this?

• Claude Code Prompts for Taming Your GitHub Repository Sprawl

  Some useful Claude Code prompts for GitHub repository management.

  1. Archive stale repositories

  Using the GitHub CLI (gh), find all of my repositories that haven't
  been pushed to in over 5 years and archive them. List them first and
  ask for my confirmation before archiving. Use gh repo list <user>
  --limit 1000 --json name,pushedAt to get the data, then filter by
  date, and archive with gh repo archive <user>/<repo> --yes.
  

  2. Add missing descriptions

  Using the GitHub CLI, find all of my repositories that have an empty
  or missing description. Use gh repo list <user> --limit 1000 --json
  name,description,url to get the data. For each repo missing a
  description, look at the repo's README and any other context to
  suggest an appropriate description. Present your suggestions to me
  for approval, then apply them using gh repo edit <user>/<repo>
  --description "<description>".
  

  3. Add missing topics/tags

  Using the GitHub CLI, find all of my repositories that have no topics.
  Use gh repo list <user> --limit 1000 --json name,repositoryTopics,
  description,primaryLanguage to get the data. For each repo with no
  topics, analyze the repo name, description, and primary language to
  suggest relevant topics. Present your suggestions for approval, then
  apply them using gh api -X PUT repos/<user>/<repo>/topics
  -f '{"names":["tag1","tag2"]}'.
  

  To make #1 easier, repjan is a TUI tool that pulls all your repos into an interactive dashboard. It flags archive candidates based on inactivity and engagement, lets you filter and sort through everything, and batch archive in one sweep. If you’ve got hundreds of repos piling up, it’s way faster than doing it one by one.

  Feb 26, 2026 / Productivity / Claude-code / Developer-tools / Github

  Enjoyed this?

• I’m reading an article today about a long-term programmer coming to terms with using Claude Code. There’s a quote at the end that really stuck with me: “It’s easy to generate a program you don’t understand, but it’s much harder to fix a program that you don’t understand.”

  I concur, while building it may be fun, guess what? Once you build it, you got to maintain it, and as a part of that, it means you got to know how it works for when it doesn’t.

  Jan 26, 2026 / AI / Programming / Claude-code

• Two Changes in Claude Code That Actually Matter

  As of 2026-01-24, the stable release of Claude Code is 2.1.7, but if you’ve been following the bleeding edge, versions 2.1.15 and 2.1.16 bring some significant changes. Here’s what you need to know.

  The npm Deprecation Notice

  Version 2.1.15 added a deprecation notification for npm installations.

  If you’ve been using Claude Code via npm or homebrew, Anthropic will soon start nudging you toward a new installation method. You’ll want to run claude install or check out the official getting started docs for the recommended approach.

  This isn’t a breaking change yet, but it’s a clear they are moving away from npm for releases going forward.

  Built-in Task Management

  Version 2.1.16 introduces something I’m genuinely excited about: a new task management system with dependency tracking.

  If you’ve been using tools like beads for lightweight issue tracking within your coding sessions, this built-in system offers a similar workflow without the setup.

  You can define tasks, track their status, and—here’s the key part—specify dependencies between them. Task B won’t start until Task A completes.

  This is particularly useful for repositories where you don’t have beads configured or you’re working on something quick where setting up external tooling feels like overkill.

  Your sub-agents can now have proper task management without anything extra.

  Should You Update?

  If you’re on 2.1.7 stable and everything’s working, there’s no rush. But if you’re comfortable with newer releases, the task management in 2.1.16 is worth trying, especially if you work with complex multi-step workflows or use sub-agents frequently.

  The npm deprecation is something to keep on your radar regardless. Plan your migration before it becomes mandatory.

  Jan 25, 2026 / DevOps / Ai-tools / Claude-code

  Enjoyed this?

• Claude Code’s built-in tasks are pretty solid—they work well for what they do. But I still find myself reaching for Beads. There’s something about having persistent issue tracking that lives with your code, syncs with git, and doesn’t disappear when you close your terminal. Different tools for different jobs, I suppose.

  Jan 24, 2026 / Claude-code / Developer-tools

• 36 Framework Fixtures in One Session: How Beads + Claude Code Changed Our Testing Game

  We built test fixtures for 36 web frameworks in a single session. Not days. Not a week of grinding through documentation. Hours.

  Here’s what happened and why it matters.

  The Problem

  api2spec is a CLI tool that parses source code to generate OpenAPI specifications. To test it properly, we needed real, working API projects for every supported framework—consistent endpoints, predictable responses, the whole deal.

  We started with 5 frameworks: Laravel, Axum, Flask, Gin, and Express. The goal was to cover all 36 supported frameworks with fixture projects we could use to validate our parsers.

  What We Actually Built

  36 fixture repositories across 15 programming languages. Each one includes:

  • Health check endpoints (GET /health, GET /health/ready)
  • Full User CRUD (GET/POST /users, GET/PUT/DELETE /users/:id)
  • Nested resources (GET /users/:id/posts)
  • Post endpoints with pagination (GET /posts?limit=&offset=)
  • Consistent JSON response structures

  The language coverage tells the story:

  • Go: Chi, Echo, Fiber, Gin
  • Rust: Actix, Axum, Rocket
  • TypeScript/JS: Elysia, Express, Fastify, Hono, Koa, NestJS
  • Python: Django REST Framework, FastAPI, Flask
  • Java: Micronaut, Spring
  • Kotlin: Ktor
  • Scala: Play, Tapir
  • PHP: Laravel, Slim, Symfony
  • Ruby: Rails, Sinatra
  • C#/.NET: ASP.NET, FastEndpoints, Nancy
  • C++: Crow, Drogon, Oat++
  • Swift: Vapor
  • Haskell: Servant
  • Elixir: Phoenix
  • Gleam: Gleam (Wisp)

  For languages without local runtimes on my machine—Haskell, Elixir, Gleam, Scala, Java, Kotlin—we created Docker Compose configurations with both an app service and a dev service for interactive development.

  How Beads Made This Possible

  We used beads (a lightweight git-native issue tracker) to manage the work. The structure was simple:

  • 40 total issues created
  • 36 closed in one session
  • 5 Docker setup tasks marked as P2 priority (these blocked dependent fixtures)
  • 31 fixture tasks at P3 priority
  • 4 remaining for future work

  The dependency tracking was key. Docker environments had to be ready before their fixtures could be worked on, and beads handled that automatically.

  When I’d finish a Docker setup task, the blocked fixture tasks became available.

  Claude Code agents worked through the fixture implementations in parallel where possible.

  The combination of clear task definitions, dependency management, and AI-assisted coding meant we weren’t context-switching between “what do I need to do next?” and “how do I implement this?”

  The Numbers

  Metric	Value
  Total Issues	40
  Closed	36
  Avg Lead Time	0.9 hours
  New GitHub Repos	31
  Languages Covered	15

  That average lead time of under an hour per framework includes everything: creating the repo, implementing the endpoints, testing, and pushing.

  What’s Left

  Four tasks queued for follow-up sessions:

  1. Drift detection - Compare generated specs against expected output
  2. Configurable report formats - JSON, HTML, and log output options
  3. CLAUDE.md files - Development instructions for each fixture
  4. Claude agents - Framework-specific coding assistants

  The Takeaway

  Doing this today, was like having a super power. “I need to test across 36 frameworks” and actually having those test fixtures ready, but with agents and Opus 4.5 and beads, BAM done!

  Beads gave us the structure to track dependencies and progress.

  Claude Code agents handled the repetitive-but-different implementation work across languages and frameworks.

  The combination let us focus on the interesting problems instead of the mechanical ones.

  All 36 repos are live at github.com/api2spec with the api2spec-fixture-* naming convention.

  Have you tried this approach yet?

  Jan 13, 2026 / DevOps / Open-source / Testing / Ai-tools / Claude-code

  Enjoyed this?