I think there’s a saying that goes something like “code is ephemeral, but data is forever.” That’s never been more true than right now. Code is easier than ever to create, anyone can spin up a working app with an AI agent and minimal experience. But your data structure? That’s the thing that sticks around and haunts you.

Data modeling is one of those topics that doesn’t get enough attention, especially given how critical it is. You need to understand how your data is stored, how to structure it, and what tradeoffs you’re making in how you access it. Get it right early, and your code stays elegant and straightforward. Get it wrong, and your codebase becomes a forever series of workarounds…

Microservices Won’t Save You

For teams moving from a monolith to microservices, if the data stays tightly coupled, you don’t really have microservices; you have a distributed monolith with extra network hops.

Yes, data can be coupled just like code can be coupled. If all your different services are still hitting the same database with the same schema, you have a problem. You need separate data structures for your services, not a monolithic architecture hiding behind a microservices facade.

The Caching Trap

So what happens when you have a lot of data and your queries get slow? You’ve done all the easy stuff; optimized queries, added indexes, followed best practices. But things are still slow.

Every senior engineer’s first instinct is the same: “Let’s add Redis in front of it.” Or “more read replicas.” And sure, that works, but you have just added complexity and now you have to deal with cache invalidation.

What happens when you have stale data? How do you recache current data, and when does that happen?

Are you caching on the browser side too? Understanding where data can be cached and how to invalidate it is another genuinely difficult problem to solve. You’re just trading one set of problems for a different set of problems.

You Can’t Predict Every Future Question

If you’re selling things on the internet, chances are, you will care about event sourcing at some point. A lot of interesting business problems don’t care about the current state of a user, they care about the intent and history. So how you store intent and history is probably different from your ACID-compliant Postgres table that you’ve worked hard to normalize.

You can get your data structure perfect for displaying products and processing sales, then run into a completely new set of requirements that changes everything about how your data needs to be structured.

It’s genuinely hard to foresee all the potential questions you’ll need to answer in the future.

Why This Matters Now

Everything you do on a computer stores data somewhere, it’s just a matter of persistence.

Which is why; everything software-related is eventually a database problem.

Data modeling isn’t glamorous, but getting it right is the difference between a system that scales gracefully and one that fights you every step of the way.

If you’re using agentic coding tools like Claude Code, there’s one thing you should know by now: your context window is a budget, and everything you do spends it.

I’ve been thinking about how to manage the budget. As we are learning how to use sub-agents, MCP servers, and all these powerful capabilities we haven’t been thinking enough about the cost of using them. Certainly the dollars and cents matters too if you are using API access, but the raw token budget you burn through in a single session impacts us all regardless. Once it’s gone, compaction kicks in, and it’s kind of a crapshoot on whether it knows how to pick up where we left off on the new session.

Before we talk about what you can do about it, let’s talk about where your tokens go, or primarily are used.

Why Sub-Agents Are Worth It (But Not Free)

Sub-agents are one of the best things to have in agentic coding. The whole idea is that work happens in a separate context window, leaving your primary session clean for orchestration and planning. You stay focused on what needs to change while the sub-agent figures out how.

Sub-agents still burn through your session limits faster than you might expect. There are actually two limits at play here:

• the context window of your main discussion
• the session-level caps on how many exchanges you can have in a given time period.

Sub-agents hit both. They’re still absolutely worth using and working without them isn’t an option, but you need to be aware of the cost.

The MCP Server Problem

MCP servers are another area where things get interesting. They’re genuinely useful for giving agentic tools quick access to external services and data. But if you’ve loaded up a dozen or two of them? You’re paying a tax at the start of every session just to load their metadata and tool definitions. That’s tokens spent before you’ve even asked your first question.

My suspicion, and I haven’t formally benchmarked this, is that we’re headed toward a world where you swap between groups of MCP servers depending on the task at hand. You load the file system tools when you’re coding, the database tools when you’re migrating, and the deployment tools when you’re shipping. Not all of them, all the time.

There’s likley more subtle problems too. When you have overlapping MCP servers that can accomplish similar things, the agent could get confused about which tool to call. It might head down the wrong path, try something that doesn’t work, backtrack, and try something else. Every one of those steps is spending your token budget on nothing productive.

The Usual Suspects

Beyond sub-agents and MCP servers, there are the classic context window killers:

• Web searches that pull back pages of irrelevant results
• Log dumps that flood your context with thousands of lines
• Raw command output that’s 95% noise
• Large file reads when you only needed a few lines

The pattern is the same every time: you need a small slice of data, but the whole thing gets loaded into your context window. You’re paying full price for information you’ll never use.

And here’s the frustrating part — you don’t know what the relevant data is until after you’ve loaded it. It’s a classic catch-22.

Enter Context Mode

Somebody (Mert Köseoğlu - mksglu) built a really clever solution to this problem. It’s available as a Claude Code plugin called context-mode. The core idea is simple: keep raw data out of your context window.

Instead of dumping command output, file contents, or web responses directly into your conversation, context-mode runs everything in a sandbox. Only a printed summary enters your actual context. The raw data gets indexed into a SQLite database with full-text search (FTS5), so you can query it later without reloading it.

It gives Claude a handful of new tools that replace the usual chaining of bash and read calls:

• ctx_execute — Run code in a sandbox. Only your summary enters context.
• ctx_execute_file — Read and process a file without loading the whole thing.
• ctx_fetch_and_index — Fetch a URL and index it for searching, instead of pulling everything into context with WebFetch.
• ctx_search — Search previously indexed content without rerunning commands.
• ctx_batch_execute — Run multiple commands and search them all in one call.

There are also slash commands to check how much context you’ve saved in a session, run diagnostics, and update the plugin.

The approach is smart. All the data lives in a SQLite FTS5 database that you can index and search, surfacing only the relevant pieces when you need them. If you’ve worked with full-text search in libSQL or Turso, you’ll appreciate how well this maps to the problem. It’s the right tool for the job.

The benchmarks are impressive. The author reports overall context savings of around 96%. When you think about how much raw output typically gets dumped into a session, it makes sense. Most of that data was never being used anyway.

What This Means for Your Workflow

I think the broader lesson here is that context management is becoming a first-class concern for anyone doing serious work with agentic tools. It’s not just about having the most powerful model, it’s about using your token budget wisely so you can sustain longer, more complex sessions without hitting the wall.

A few practical takeaways:

• Be intentional about MCP servers. Load what you need, not everything you have.
• Use sub-agents for heavy lifting, but recognize they cost session tokens.
• Avoid dumping raw output into your main context whenever possible.
• Tools like context-mode can dramatically extend how much real work you get done per session.

We’re still early in figuring out the best practices for working with these tools. But managing your context window? That’s one of the things that separates productive sessions from frustrating ones.

Hopefully something here saves you some tokens.

I got tired of plaintext .env files, so I built LSM. lsm exec will inject secrets at runtime so they never touch the filesystem. Doppler’s idea, minus the monthly bill.

How are you managing local secrets?

I switched to mise for version management a month ago. No regrets. No more brew upgrade breaking Python. Built-in task runner replaced some of projects that were using Makefiles.

Still juggling nvm + pyenv + rbenv?

I wrote about why you should stop using pip. Poetry or uv. Pick one. pip has no lockfile, no dependency resolution worth trusting, and no isolation by default.

Have you moved to uv yet? Still happy with poetry? How’s it going?

I wrote about when to reach for Python over Bash. Most veterans put the cutoff at 50 lines. If you’re writing nested if statements in Bash, you’ve already gone too far.

Where does Go fit in though? Overkill for scripts?

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?

I compared npm, Yarn, pnpm, and Bun. TLDR version: pnpm wins for most teams, Bun wins if you’re already on the runtime.

Has anyone switched their whole team to Bun yet? How’d that go?

I wrote about securing node_modules. Socket, Snyk, Dependabot — each catches different things. Hopefully answering when to use AI to rewrite simple deps you barely use.

Anyone want to build that CLI?

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?

When to use python over bash is really a question of when to use bash. Python is a general-purpose language that can handle just about anything you throw at it. Bash, on the other hand, has a very specific sweet spot. Once you understand that sweet spot, the decision makes itself.

What Bash Actually Is

Bash is an interactive command interpreter and scripting language, created in 1989 for the GNU project as a free software alternative to the Bourne shell. It pulled in advanced features from the Korn shell and C shell, and it’s been commonly used by Unix and Linux systems ever since.

What makes Bash unique is its approach to data flow programming. Files, directories, and system processes are treated as first-class objects. Bash is designed to take advantage of utilities that almost always exist on Unix-based systems. So think of tools like awk, sed, grep, cat, and curl. Another important thing to know when writing effective Bash scripts, you also need to understand the pipeline operator and how I/O redirection works.

A good Bash script will look something like this:

#!/bin/bash
set -euo pipefail

LOG_DIR="/var/log/myapp"
DAYS_OLD=30

find "$LOG_DIR" -name "*.log" -mtime +"$DAYS_OLD" -print0 |
  xargs -0 gzip -9

echo "Compressed logs older than $DAYS_OLD days"

Simple, portable, does one thing well. That’s Bash at its best.

Where Bash Falls Short

Bash isn’t typed. There’s no real object orientation. Error handling is basically set -e and hoping for the best. There’s no try/catch, no structured exception handling. When things go wrong in a Bash script, they tend to go wrong quietly or spectacularly, with not much in between.

Python, by contrast, is optionally strongly typed and object-oriented. If you want to manipulate a file or a system process in Python, you wrap that system entity inside a Python object. That adds some overhead, sure, but in exchange you get something that’s more predictable, more secure, and scales well from simple scripts to complex logic.

Here’s that same log compression task in Python:

from pathlib import Path
import gzip
import shutil
from datetime import datetime, timedelta

log_dir = Path("/var/log/myapp")
cutoff = datetime.now() - timedelta(days=30)

for log_file in log_dir.glob("*.log"):
    if datetime.fromtimestamp(log_file.stat().st_mtime) < cutoff:
        with open(log_file, "rb") as f_in:
            with gzip.open(f"{log_file}.gz", "wb") as f_out:
                shutil.copyfileobj(f_in, f_out)
        log_file.unlink()

More verbose? Absolutely. But also more explicit about what’s happening, easier to extend, and much easier to add error handling to.

The Performance Question

In some cases, performance genuinely matters. Think high-frequency trading platforms, edge devices, or massive clusters. Bash scripts excel here because there’s almost zero startup overhead. Compare that to Python, which needs to load up the interpreter before it can start executing code. You’re going from microseconds to milliseconds, and sometimes that matters.

But startup time is just one factor. When you compare the actual work being done, Python can pull ahead. String manipulation on structured data? Python wins. Parsing JSON, YAML, or any structured format? Python’s core libraries are written in C and optimized for exactly this kind of work. If you find yourself reaching for jq or yq in a Bash script, that’s a strong signal you should be using Python instead.

The Guidelines People Throw Around

You’ll see a common guideline online: if your script exceeds 100 lines of Bash, rewrite it in Python. But a lot of veterans in the industry feel like that cutoff is way too generous. Experienced engineers often put it at 50 lines, or even 25.

Another solid indicator: nested if statements. Some people say “deeply nested” if statements, but let’s be honest, more than one level of nesting in Bash is already getting painful. Python handles complex branching logic far more gracefully, and you’ll thank yourself when you come back to maintain it six months later.

Unit Testing Tells the Story

You can do unit testing with Bash. BATS (Bash Automated Testing System) exists, and ShellCheck is useful as a lightweight linter for catching bad practices. But despite these tools, Python’s testing ecosystem is on another level entirely. It’s fully mature with multiple frameworks, excellent mocking capabilities, and the ability to simulate network calls, external APIs, or system binaries. Complex mocking that would be difficult or impossible in Bash is straightforward in Python.

If your script needs solid testing or if it’s doing anything important, that’s a strong vote for Python.

Bash’s Biggest Win: Portability

So what does Bash actually win at? Portability. When you think about all the dependencies Python needs to run, Bash is the clear winner. You’re distributing a single .sh file. That’s it.

With Python, you have to ask: Does Python exist on this machine? Is it the right version? You’ll need a virtual environment so you don’t pollute system Python. You need third-party libraries installed via a package manager; and please friends, remember that we don’t let friends use pip. Use Poetry or uv. Pip is so bad that I’d honestly argue that Bash not having a package manager is better than Python having pip. At least Bash doesn’t pretend to manage dependencies well.

If you want something simple, something that can run on practically any Unix-based machine without setup, Bash is your answer. Even Windows can handle it these days through WSL, though you’re jumping through a few hoops.

TLDR

The decision is actually pretty straightforward:

• Use Bash when you’re gluing together system commands, the logic is linear, it’s under 50 lines, and portability matters.
• Use Python when you’re parsing structured data, need error handling, have branching logic, want proper tests, or the script is going to grow.

If you’re reaching for jq, writing nested if statements, or the script is getting long enough that you’re losing track of what it does… it’s time for Python.

I think in a future post we might look at when Go makes sense over Bash. There’s a lot to cover there about compiled binaries, but for now, hopefully this helps you make the call next time you’re wondering what to start your scripting with.

I built a thing to solve a problem. It has helped me, maybe it will help you?

It all starts with a question.

Why isn’t there a good local secrets manager that encrypts your secrets at rest? I imagine a lot of people, like me, have a number of local applications. I don’t want to pay per-seat pricing just to keep my sensitive data from sitting in plaintext on my machine.

I built an app called LSM Local Secrets Manager to solve that problem. The core idea is simple. Encrypt your .env files locally and only decrypt when you need them (sometimes at runtime).

The Problem

If you’ve got a bunch of projects on your machine, each with their own .env or .env.local file full of API keys you’re definitely not rotating every 90 days. Those files just sit there in plaintext. Any process on your system can read them. And with AI agents becoming part of our dev workflows, the attack surface for leaking secrets is only getting easier.

ThE CLAW EnteRed ChaT

I started looking at Doppler specifically for OpenCLAW. Their main selling feature is injecting secrets into your runtime so they never touch the filesystem. I was like, cool. Also I like that Doppler stores everything remotely. The only thing was the cost did not make sense for me right now. I don’t want to pay $10-20 a month for this set of features.

So what else is there?

Well GCP Secret Manager has its own set of issues.

You can’t have duplicate names per project, so something as common as NODE_ENV across multiple apps becomes a more work than you want to deal with. Some wrapper script that injects prefixes? No thanks. I imagine there are a thousand and one homegrown solutions to solve this problem. Again, no thanks.

So what else is there?

You Find A Solution

AWS Secret Manager

A Problem for Solution Problem

AWS IAM

🫣

I have a lot more to say here on this subject but will save this for another post. Subscribe if you want to see the next post.

The Solution

The workflow is straightforward:

1. lsm init — Run this once from anywhere. It generates your encryption key file.
2. lsm link <app-name> — Run this inside your project directory. It creates a config entry in ~/.lsm/config.yaml for that application.
3. lsm import — Takes your existing .env or .env.local and creates an encrypted version.
4. lsm clean — Removes the plaintext .env files so they’re not just sitting around.
5. lsm dump — Recreates the .env files if you need them back.

But wait there’s more.

Runtime Injection with lsm exec

Remember that cool thing I just told you about? Instead of dumping secrets back to disk, you run:

lsm exec -- pnpm dev

I feel like a family man from Jersey, who don’t mess around. Aye, you got, runtime injection. I got that.

Well that’s lsm anyways. It can decrypt your secrets and inject them directly into the runtime environment of whatever command follows the --. Your secrets exist in memory for the duration of that process and nowhere else. No plaintext files hanging around for other processes to sniff.

Credit to Doppler for the idea. The difference to what we are doing is your encrypted files stay local.

What’s Next

I’ve got some possible ideas of improvements to try building.

• Separate encrypt/decrypt keys — You create secrets with one key, deploy the encrypted file to a server, and use a read-only key to decrypt at runtime. The server never has write access to your secrets.
• Time-based derivative keys — Imagine keys that expire or rotate automatically.
• Secure sharing — Right now you’d have to decrypt and drop the file into a password manager to share it. There’s room to make that smoother.

I’m not sure how to do all of that yet, but we’re making progress.

Why Not Just Use Doppler?

There are genuinely compelling reasons to use Doppler or similar services. I mean bsides the remote storage, access controls and auditable logs. There’s a lot to love.

For local development across a bunch of personal projects? I don’t think you should need a SaaS subscription to keep your secrets encrypted.

LSM is still early, but the core workflow is there and it works.

Give it a try if you’re tired of plaintext .env files scattered across your machine.

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.

Mountains of men

I love Ghostty for agentic work (mostly Claude Code). It doesn’t try to bake in its own agentic coding environment. It’s completely unopinionated about how you use it. It is exactly what I want from a terminal.

It’s open source, primarly made by one person, Mitchell Hashimoto, who doesn’t ask you for any money. No outside investment, no employees. Just a really solid (I think the best?!) terminal emulator.

Sometimes I do wish it had slightly better navigation, and system notifications was easier to figure out, but this is minor stuff and not a blocker for me being productive or enjoying the work.

The Warp’ed De-Tour

I used to use Warp before Ghostty. I’ll still open it occasionally to see what they’re working on. Warp has some interesting ideas, they’re trying to replace your IDE and be your entire agentic development environment. The problem is they seem to have too many features now for general use. I think this approach will turn off both the IDE crowd and the Neovim crowd simultaneously. So, I keep going back to Ghostty.

We now have a new contender.

Enter Cmux

Cmux is a newer option that actually solves those two minor problems I had with Ghostty. It has better navigation with side tabs, and notifications work out of the box. It’s open source and free to use, and it’s built on Ghostty under the hood, so the core terminal experience is solid.

There’s a small AI company behind it. It looks like their Y Combinator batch was in 2024, and they’re trying to build some kind of product on top of Cmux, possibly memory-related. Though with Claude Code getting better at memory and plenty of free memory frameworks already out there, I’m not sure where that is headed. This CMUX project could be the start of a pivot?

The repo is kind of a mess, they have their website mixed in with the application code. And they offer something called a “Founder’s Edition” for $30/month… which I don’t know how that makes any sense when Warp is $20/month, Zed is $10/month, and Cursor is $20/month.

However it’s optional and the free version of Cmux is really good right now; but I’m be doubtful it exists in five or ten years. My guess is their exit strategy is to get acquired by a model provider, given that they have taken investment.

I am having fun with cmux, so check it out if you haven’t yet!

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. 👋

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!

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.

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

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

Built a thing: Chord Compass — an interactive circle of fifths that lights up chord relationships when you click a key. Load preset progressions like I–V–vi–IV, hit play, hear them back. It looks like a brass compass from an old music theory textbook and I love it.

I built Scale Lab — pick a root note, choose from 14 scales and modes, and watch the notes light up on a piano keyboard. Hit play to hear them ascend. Just a bit of music theory fun. Enjoy!

I published an Agentic Maturity Model on GitHub, a mental framework for thinking about and categorizing AI tools. It’s open to contributions and I’m looking for coauthors.

Agentic Maturity Model

Microsoft Gaming has a profit margin problem. Their marching orders are to hit 30%, and right now (we think) they’re sitting at around 12% to 15% range. That means they need to roughly double their margins, a massive ask for a division with 20,000 employees across a dozen studios.

For context, even the most successful studios only hit 40% margins on a great year. CD Projekt Red, a publicly traded company, can clear that mark when they ship a massive IP like The Witcher or Cyberpunk. But CD Projekt Red is around 1,200 employees. Microsoft Gaming is much, much larger so, comparing one focused studio to an entire publishing empire isn’t exactly fair.

So how do you close that gap? You either increase revenue or cut spending. I think the answer starts with fixing Game Pass.

Simplify Game Pass

Here’s my pitch: kill Game Pass Core and the middle tier. Get rid of the confusing lineup of plans and just have one. Your current Game Pass Ultimate becomes “Game Pass” and reduce it to $25/month.

Right now, Game Pass has too many tiers doing too little to differentiate themselves. Core exists to charge people for online multiplayer, which feels increasingly absurd when I’m only playing free-to-play games like Minecraft, Marvel Rivals, or Fortnite. I shouldn’t have to pay $10/month just to play online in games that are free everywhere else.

One plan. One price. Simple.

Fix the New Release Problem

Game Pass’s biggest issue is that day-one releases cannibalize game sales. Every copy someone plays through Game Pass instead of buying is lost revenue and for a division trying to double its margins, that’s a problem.

Here’s what I’d do: new releases still come to Game Pass on day one, but they rotate out after a couple of months. Want to keep playing? Buy the game. Then, after a couple of years, those titles can come back to the Game Pass catalog permanently as part of the back catalog.

This gives subscribers the chance to try new games, which is the whole appeal of the service. But it stops Game Pass from being a reason to never buy anything. Let me discover games through the service, but make me buy the ones I love if I want to keep playing before they hit the archives.

You get the best of both worlds: Game Pass stays exciting with new releases, and you stop bleeding game sales.

Replace xCloud with GeForce Now

Now I don’t know a ton about xCloud, but what I do know is that it’s not as good as GeForce Now. So why not just build GeForce Now into the Xbox ecosystem?

Microsoft doesn’t need to own every piece of the stack. If NVIDIA already has the best cloud gaming solution, partner with them. Integrate it into the Xbox app and console experience. The user doesn’t care whose servers are running the game, they care that it works well.

Make Games Portable Across Platforms

This is the big one. If I buy a game, I should be able to play it on any device I want; so on my Xbox, on PC through the Xbox app, or streamed through GeForce Now gaming. One purchase, play anywhere.

Right now, Steam lets me play my library on basically anything. That’s a huge reason people buy games there instead of the Microsoft Store. If Xbox matched that with true cross-platform ownership, it would actually give people a reason to buy from Microsoft.

Maybe this waits for the next Xbox hardware revision, but tell people now that it’s coming. Set the expectation. Give people a reason to start building their library in the Xbox ecosystem.

The Takeaway

The path to 30% margins isn’t about cutting studios or raising prices. It’s about making the Xbox ecosystem so compelling that people actually want to spend money in it. Simplify Game Pass, stop cannibalizing sales, partner where it makes sense, and make purchases feel valuable by letting people play anywhere.

Microsoft has the studios. They have the IP. They have the infrastructure. They just need to stop overcomplicating things and give gamers a reason to choose Xbox not just subscribe to it.

I built a frustration game disguised as a broken SaaS dashboard. Cookie banners, modals and upgrade prompts. Close one and two more spawn. The modern internet as a playable joke.

thousand-boxes.logan.center