Once a month I sit down and clean it up. Cut the skills nobody calls. Simplify the ones that drifted. Rewrite agent identities that got too vague. Normal gardening.

This month I wanted a different view. Not a list of what I have, I already have that. I wanted a picture of how it all connects. Which skills hand off to which. Which agents get delegated to. Which MCP servers actually get used, and by what.

So I asked Claude to build it. The team liked the result enough that I packaged it into a skill you can drop into any repo. It’s called harness-map, and it runs under Claude Code, Codex, and anything else that reads the Agent Skills format.

How it works

The hard part is not listing the files. A script can walk .claude/ and find every skill, command, agent, and MCP server in a second. The hard part is the edges. A dependency between two skills lives in prose, in a sentence like “then run the code-review skill” buried in a SKILL.md body. You can’t grep your way to that reliably.

So harness-map splits the work. Deterministic scripts do the scanning and the final HTML rendering. In between, the agent reads every skill and agent body and infers the typed edges: skill hands off to skill, skill delegates to agent, either one uses an MCP server.

The one rule I care about most: every edge needs a quotable line of evidence. No line, no edge. That keeps the map honest. It draws what the files actually say, not what sounds plausible.

Output is a single self-contained harness-map.html. Fully offline, opens in any browser.

Reverse-engineering superpowers

The map below is not our harness. That one stays private. This is Obra’s superpowers, a public skill library, run through harness-map. I use superpowers myself for brainstorming, TDD, and debugging, so it made a good test.

Fourteen skills, twenty-two edges, clustered automatically. You can see which skills sit at the center and which hang off the edge. This took a few minutes to generate from a repo I’d never opened.

Why I keep opening it

There are two reasons I keep opening it. First, if you have a big harness, it’s satisfying to see what’s inside. Seven months of small decisions, each one made in isolation, laid out as one graph. I built most of these skills one friction point at a time and never once saw them together.

Second, and this is the useful part, the layout surfaces problems you can’t feel from inside individual files, because structure you didn’t intend shows up as shape.

What it found in ours

The thing that caught my eye was absence. Several skills I expected to lean on each other had no edges between them at all. They sat in their own corners, disconnected.

I dug in. It turned out the code review instructions were copy-pasted across half a dozen skills. Each skill carried its own slightly-drifted version of the same review steps, instead of every skill pointing at one canonical review skill that already existed. No edges, because there were no references. Just duplication.

That is exactly the kind of thing that hides in plain sight. Each skill reads fine on its own. You only notice when you see them next to each other and the arrows that should be there aren’t. The fix was boring: delete the copies, point everything at the canonical skill. But I would not have found it without the picture.

Try it

npx skills add dreamiurg/harness-map

Then invoke /harness-map, or just ask your agent to map the harness. You get harness-map.html and nothing else to clean up.

Your mileage will vary. Your harness is not my harness, and you may find nothing worth fixing. But if yours has grown past the point where you can hold it in your head, it’s worth a look. It’s been genuinely useful for us.

Cheers.

People who have climbed here for twenty years answer this from memory. Storm coming off the ocean? Go east of the crest. Marine layer? Head south. They have a mental database built from hundreds of weekends, some of them ruined.

I don’t have that database. I’ve been climbing in the Cascades for a few years, and when my primary objective gets stormed out, I have no honest basis for picking a backup. I could copy what more experienced friends do, but I wanted to actually understand it. I wanted an answer I could check against 20 years of records, not secondhand rules of thumb.

The result is Climbable.day, an interactive map that ranks backup objectives for any of 500 Washington peaks, conditioned on the season and the incoming weather pattern. This post is about how I got there.

Getting the data

I was experimenting with Claude Science at the time, so I asked it to do the data legwork. Two free, keyless sources cover everything:

• Daymet has daily precipitation, temperature, and snowpack on a 1 km grid going back decades. Sampled at each of 500 summits for 2004 through 2023, that’s about 7,300 days per peak.
• NASA POWER has daily wind direction, pulled at five points spanning coast to dry interior to label each day’s flow pattern.

The peak list is the Bulger List of the 100 highest Washington peaks, plus 400 more from OpenStreetMap so the Olympics, both sides of the Cascades, and the Blue Mountains are all represented.

Then I needed a definition of a “climbable day.” I settled on 3 mm of precipitation or less and an overnight low of -15 °C or warmer. It’s a deliberately simple proxy for “dry and not brutally cold.” A rock climber and an ice climber would draw those lines differently, and that’s fine. The point is to compare peaks against each other, and any reasonable threshold preserves the ranking.

What the data said

Four things stood out.

The rain shadow is enormous. Mount Baker averages over 200 inches of precipitation a year. Peaks 50 miles east in the Methow see under 30. That’s a 7x gradient across a two-hour drive, and it’s the physical foundation of every backup plan in this state.

There is no anti-correlated peak. I assumed some peaks would be good exactly when others are bad. The data says no. Washington storms are big; when one moves in, nearly every pair of peaks gets wet together and dries out together. So when your objective is stormed out, everything is somewhat worse. The realistic goal is the peak that degrades least. On a wet southwest storm day, the far-eastern dry country still offers about a 50% chance of a climbable day while the western peaks sit near zero.

Winter breaks the strategy. Storms blanket the entire state, so hopping to a backup buys you little. It’s in summer that the dry east genuinely decouples from the wet west, which means the approach pays off most exactly during climbing season. Convenient.

The best backup flips with the weather pattern. This is the one I didn’t expect. Classifying all 7,300 days by their statewide precipitation shape and wind direction produced five recurring patterns. On a wet southwest day, the best backup for a stormed-out Shuksan is east; on a dry northwest day, it’s south. The direction depends on the pattern, not the peak.

From report to planner

The first output was a report with static charts. It answered my questions, but every chart provoked a new one. What about this peak? What about September? What if the incoming pattern is transitional instead of a full storm?

A static report can’t answer follow-up questions. An interactive map can. So I turned the report into the planner: pick any peak, pick a season or let the live 14-day forecast classify the incoming pattern, and it ranks your Plan B and Plan C by their odds on exactly the days your first choice was out. When you select a pattern, animated wind streaks show the flow so the geography clicks.

A concrete example. Shuksan in summer under a wet southwest storm drops to a 9% chance of a climbable day. The planner’s top backups for those exact days: Tatoosh Buttes (54%), Muckamuck Mountain (54%), and Ptarmigan Peak (51%), all far east of the crest. Under the dry northwest pattern the same Shuksan sits at 91% and the whole question evaporates.

Under the hood it’s a single static page: vanilla JS, Leaflet, a bit-packed binary of 500 x 7,300 climbable-day flags (456 KB), and Open-Meteo for the live forecast. The forecast classifier is nearest-centroid over four features. It reproduces the historical patterns about 70% of the time (random guessing over five patterns would get 20%), and about 87% on the wet-vs-dry call that actually drives decisions.

The full write-up with figures and method is in the report (PDF). The app code, figures, and the 500-peak roster are in the project folder of this site’s repo.

What it won’t tell you

This is a planning aid built on historical weather. It is not a forecast for your climb day, and it knows nothing about avalanche hazard, route conditions, rockfall, smoke, or whether the road is open. A peak with great weather odds can still be dangerous. Check a real mountain forecast and the NWAC bulletin before committing to anything.

Try it

The planner is at climbable.day. If you climb in Washington, I’d genuinely like to know whether the rankings match your experience, especially if you’re one of those people with the twenty-year mental database. And if you have ideas for improvements, drop me a line.

I went through my session logs and pulled usage numbers. For each skill I’m showing two stats: the percentage of active Claude days where I used it at least once, and the raw invocation count over the last four weeks.

I also use community skills, particularly Obra’s superpowers for brainstorming, TDD, debugging, and code review. Awesome Claude Code has a growing list if you want to browse what’s out there. But the ones below are mine. I built my first one back in November and kept going.

Heavy traffic

These three account for the majority of my skill invocations.

oneshot (32% of days, 78 last month)

Takes a detailed implementation plan, analyzes the task graph, breaks it into waves of parallel work, dispatches sub-agents to implement each task, runs a two-stage code review (spec compliance + code quality) between waves, validates with linters and tests, commits, creates a draft PR, monitors CI, and addresses CodeRabbit feedback.

The orchestrator is a thin lead agent that never runs commands itself. It dispatches everything. This keeps its context window clean across multi-wave implementations.

babysit-pr (25% of days, 93 last month)

The complement to oneshot. Once a PR exists, babysit-pr takes over. Gathers CI status, CodeRabbit feedback, CodeQL findings, and coverage reports in parallel. Fixes lint errors, type issues, missing test coverage, legitimate review findings. Loops until all required checks pass. I talked about this feedback loop in where the work goes when agents arrive.

It evaluates each automated review comment rather than blindly implementing all of them. Pushes back on nitpicks, fixes real issues, skips subjective style preferences.

cleanup-worktree (24% of days, 17 last month)

Removes a finished git worktree and deletes the branch. Verifies the branch is actually merged, checks for uncommitted work, asks before doing anything destructive.

Moderate traffic

wt (5% of days, 34 last month)

Created three weeks ago, so the day-percentage is misleading.

The counterpart to cleanup-worktree. Creates a new worktree, stashes any in-progress changes (including untracked files), pops them in the new directory, runs post-creation setup. Enforces a session rule: all subsequent work stays inside the worktree so the agent doesn’t accidentally edit files in the main repo. I track parallel sessions with topic summaries in my tmux status line, so knowing which worktree I’m in matters.

rebase (8% of days, 1 last month)

Rebases the current feature branch on origin/main and force-pushes with --force-with-lease. Validates you’re not on the default branch, checks for uncommitted changes, aborts cleanly on conflicts. Usage spiked in January and dropped off since.

Low traffic

Low invocations here doesn’t mean low value. Some of these are one-time-per-repo tools by design.

bootstrap-quality (5% of days, 13 last month)

Takes a working prototype and adds production-grade quality infrastructure: pre-commit hooks for linting, formatting, secrets detection, and SAST via Semgrep. CI workflow with a sentinel pattern. Test coverage thresholds. Cyclomatic complexity gates via Lizard. GitHub branch protection rulesets. Dependabot with auto-merge for minor and patch updates. Supply chain security review. Release Please for semantic versioning. README with badges.

Interactive 11-phase setup. Detects what exists (Go? TypeScript? Python?), asks preferences, executes. Used on 8 repos, once each.

cleanup-all-worktrees (6% of days, 10 last month)

Batch version of cleanup-worktree. Run from the main repo, it scans all branches with worktrees, checks each for merged PRs with no unpushed work, and deletes the safe ones. Periodic housekeeping when worktrees accumulate.

oneshot-team (4% of days, 7 last month)

Evolution of oneshot with persistent agent teams instead of ephemeral sub-agents. Implementers and reviewers retain context across waves, message each other directly, self-claim tasks from a shared list. Trade-off is token cost: each teammate is a full Claude instance for the duration of the plan. Still experimental.

What’s not on this list

Plenty. Each project has its own skills that live in the repo’s .claude/ directory. I have project-specific skills for speckit (spec-driven development), blog writing, and various domain workflows. I also rely heavily on community plugins, particularly Obra’s superpowers for brainstorming, TDD, systematic debugging, and code review.

If any of these sound useful, let me know. Happy to share the source.

Cheers.

Claude Code, Cursor, Codex, Windsurf, whatever you use. These tools run as processes on your machine with the same permissions as your shell. If you have AWS_SECRET_ACCESS_KEY in your .zshrc, the agent has it. If you have a .env file with database credentials, the agent can read it. If you exported a Stripe API key three months ago and forgot about it, the agent still knows.

This isn’t a bug. It’s how processes work on Unix.

Agents are processes, not people

When you run an AI coding agent, you’re launching a process that inherits your shell environment. It can execute commands, read files, and make network requests. It does all of this to be useful, and mostly it is.

But these agents also accept instructions from the content they read. A malicious comment in a GitHub issue, a crafted docstring in a dependency, a weird README in a package you’re evaluating. This is prompt injection, and it’s not theoretical.

In December 2025, a security researcher disclosed over 30 vulnerabilities across Cursor, GitHub Copilot, Windsurf, and other popular AI coding tools, collectively dubbed “IDEsaster.” The flaws enable data theft and remote code execution through prompt injection. Around the same time, someone compromised Amazon Q’s VS Code extension and planted prompts that could wipe files and disable AWS infrastructure. In May 2025, an attacker crafted a malicious GitHub issue that hijacked an AI assistant connected to an MCP server, leaking private repo contents and personal financial information to a public repository.

The agent reads something that tells it to do something else. Maybe it curls your env vars to an external URL. Maybe it reads ~/.aws/credentials and stuffs the contents into a commit message. The attack surface is your entire environment.

What you should actually do

There’s no single fix. Defense in depth applies here the same way it does everywhere else. You should:

• Run agents in sandboxed containers. Docker sandboxes, DevContainers, and Claude Code’s native sandboxing all limit filesystem and network access. This is the single biggest thing you can do. If the agent can’t read /Users/you/.aws/credentials or reach the internet, most exfiltration attacks are dead on arrival.
• Use short-lived, least-privilege credentials. A GitHub fine-grained PAT scoped to one repo with read-only access is a lot less dangerous than a classic PAT with full repo scope. AWS STS session tokens, OAuth tokens with short expiry, scoped API keys. If a credential leaks, you want it to be useless by the time anyone tries to use it.
• Restrict agent permissions at the tool level. Most agents have permission controls. Claude Code has permission modes and deny rules that can block file access and network requests to specific paths and domains. Use them. An agent that can’t write to .mcp.json or ~/.zshrc can’t tamper with its own credential pipeline.

These are all good practices. You should do all of them.

But security is always about finding the right balance. Not everyone has time to implement all of this at once, especially if you’re a solo developer or a small team moving at light speed. And that’s fine. Security isn’t binary. It’s about understanding the risk you’re comfortable with and adding layers as you go. Most of us start with export API_KEY=sk-... in .zshrc and move on.

Here’s something practical you can do right now, in about an hour, that adds a meaningful layer on top of whatever else you’re already doing (or not doing).

Process-scoped secrets with 1Password CLI

1Password CLI lets you store secrets in your vault and reference them with op:// URIs. You can test this right now if you have 1Password CLI installed:

$ op read "op://Vault/GitHub/token"
ghp_a1b2c3d4e5f6...

That fetches a single secret from your vault, authenticated via biometrics or a cached session. The interesting part is op run, which uses the same references to inject secrets into a child process:

1. You define environment variables using op:// references that point to items in your vault.
2. op run resolves those references at launch time.
3. It passes the resolved values as env vars to the child process only.
4. The secrets never enter your shell environment, never hit disk, and aren’t visible to env or /proc.

The child process gets exactly the secrets it needs. Nothing else on your machine can see them.

Where this actually matters: MCP servers

Say you’re using GitHub’s official MCP server so your coding agent can create issues, review PRs, and search code. It needs a Personal Access Token. The typical approach is to put it in .env or export it in your shell profile. But then every process on your machine, including the AI agent itself, can see that token. And a GitHub PAT with repo scope is keys to the kingdom.

Here’s the problem: if the agent falls victim to prompt injection, it already has shell access. If your GitHub PAT is sitting in an env var or a dotfile, the hijacked agent can grab it with a single echo or cat command. Same for your AWS keys, Stripe tokens, database passwords, anything that’s ambient in the environment. The more credentials are lying around, the more an attacker can scoop up in one shot.

You can check MCP configurations into git with op:// references instead of actual secrets. Here’s what the GitHub MCP server looks like with this approach:

{
  "mcpServers": {
    "github": {
      "type": "stdio",
      "command": "op",
      "args": [
        "run", "--", "docker", "run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "op://Vault/GitHub/token"
      }
    }
  }
}

Notice the command isn’t docker. It’s op. The actual server command comes after -- in the args. When the agent launches this MCP server, op run authenticates with 1Password, resolves the op:// URI to your real GitHub PAT, and injects it into that one Docker process. The same pattern works for any MCP server that needs credentials: Slack bots, Sentry, Stripe, whatever. Swap in the right command and point the env vars at the right vault items.

What this gets you

The config file is safe to commit. It contains vault paths, not secrets. You can check .mcp.json into git, clone the repo on a new machine, and everything works as long as you have 1Password access. No .env.example files, no “which API keys do I need” notes.

Secrets are scoped per process. If you run multiple MCP servers this way, each one only sees its own credentials. If one process gets compromised through prompt injection, the attacker gets one set of keys, not your entire keychain.

Nothing lands in the shell. Run env | grep GITHUB and you get nothing. The agent’s main process can’t see the token either. Only the specific child process that op run launched has it.

This is not a panacea

I want to be clear about what this does and doesn’t protect against.

An agent with write access to your filesystem can modify the .mcp.json file itself. It could replace the docker command with a wrapper that prints env vars before forwarding them. It could add "echo $GITHUB_PERSONAL_ACCESS_TOKEN &&" before the real command. If the agent can edit config files and trigger a server restart, it can intercept the secrets that op run injects. This isn’t a hypothetical. Any agent that can write files and run shell commands has this capability.

op run protects against passive leakage: the case where secrets sit in your shell environment and any process, compromised or not, can read them at any time. It makes credential access explicit and auditable rather than ambient. But it doesn’t stop a determined agent (or attacker controlling one) from actively working around it.

That’s why this is one layer, not the whole stack. You still want sandboxed containers, least-privilege credentials, and agent permission rules as described above.

Each of these layers catches a different class of attack. None of them is sufficient alone. Together they add up.

What op run gives you is the easiest layer to add. Instead of every secret being available to every process at all times, each secret is available to exactly one process for the duration of its lifetime. It takes about an hour to set up, and it meaningfully shrinks the window of exposure for the most common case: secrets leaking because they were just sitting there, visible to everything.

Stay safe.

But there’s a simpler question I need answered faster: which repo is this?

When I have four or five Claude sessions open across different projects, the session topic tells me what I’m doing but not where. I kept glancing at tmux panes, reading the topic, then mentally mapping it back to a repository. That’s one step too many.

The fix: a tiny .zshrc wrapper

iTerm2 badges are large, faded text rendered in the background of a terminal session. They’re designed to be visible at a glance without interfering with the actual terminal content.

Here’s what it looks like when the badge is set to the repo name:

I wrapped the claude command in a shell function that sets the badge to the repository name before launching, and clears it on exit:

# Wrap claude to set/clear iTerm2 badge with repo name
claude() {
  local repo
  repo=$(basename "$(git rev-parse --show-toplevel 2>/dev/null)")
  if [ -n "$repo" ]; then
    printf "\033]1337;SetBadgeFormat=%s\007" "$(printf '%s' "$repo" | base64)"
  fi
  command claude "$@"
  printf "\033]1337;SetBadgeFormat=\007"
}

That’s it. No plugin, no hook, no background process. Just a shell function.

How it works

1. git rev-parse --show-toplevel finds the root of the current repository
2. basename extracts just the directory name (e.g., my-api from /Users/me/src/my-api)
3. The iTerm2 proprietary escape sequence \033]1337;SetBadgeFormat=...\007 sets the badge, with the text base64-encoded as iTerm2 requires
4. command claude "$@" runs the real claude binary, passing all arguments through
5. When Claude exits, the badge is cleared with an empty SetBadgeFormat

If you’re not in a git repo, no badge is set. No errors, no fallback text, just a clean terminal.

I also alias it for convenience:

alias c='claude'

Why badges over session topics

Session topics and badges solve different problems. I use both.

Session topics tell you what you’re working on: “OAuth debug: fixing schema validation.” They update as the conversation evolves, require a plugin, and take a few seconds to generate via Haiku. Good for remembering context after stepping away.

Badges tell you where you are: “my-api.” They’re instant, static for the lifetime of the session, and need zero infrastructure. Good for glancing across multiple terminal tabs and knowing which is which.

The badge is always there, always correct, and costs nothing. When I’m switching between tabs, that’s what I need first. The topic is what I read second, after I’ve landed in the right place.

iTerm2 badge configuration

Badges are customizable in iTerm2 preferences under Profiles > General > Badge. You can control the font size, position, and maximum dimensions. I keep mine at the default position (top right) with a large enough font to read from across the desk.

If you use tmux integration mode (tmux -CC), badges work per-tab since each tmux window maps to an iTerm2 tab. I wrote about that setup in my remote Claude Code post.

Limitations

This only works in iTerm2. If you use a different terminal, you’ll need to find the equivalent escape sequence (or just ignore this post).

The badge shows the repo name, not the branch. I considered adding the branch but decided against it. The repo name is stable for the session. The branch can change mid-session, and updating it would require either polling or a more complex hook. Not worth it for the 80% case.

If you launch Claude outside a git repository, there’s no badge. I don’t have a use case for that, so I didn’t add a fallback.

Related: I wrote about session topic summaries for Claude Code and running Claude Code remotely from my phone, both of which layer on top of iTerm2 and tmux.

At some point I also started building little tools around the site: a Chrome extension that syncs my activity history, a CLI for PeakBagger, and a Claude Code plugin that pulls route beta from a few places. Same itch every time: I want the data without clicking through five tabs.

The missing piece was letting an AI assistant query mountaineers.org directly. A lot of that site is public for anyone to browse. MCP just turns those pages into structured results so Claude/Codex can answer questions like “what scrambles are on the calendar?”

If you’re a Mountaineers member, the same idea gets more useful: you can ask about your own registrations, activity history, and course enrollments.

Getting to a working prototype

I skimmed the Model Context Protocol spec, looked at mountaineers.org, and thought: it’s mostly HTML. I can parse it, wrap it as MCP tools, and call it done.

That part did go quickly, mostly because I didn’t do it alone. I built it with a lot of help from Claude Code and Codex, and it stayed fun the whole time. I had a usable prototype in TypeScript the same day, published it on npm, and had it answering questions in Claude Desktop.

The slow part was all the small, undocumented details. The site runs on Plone, and a bunch of the “API-shaped” surfaces aren’t APIs at all:

• Faceted search returns HTML fragments, not JSON.
• “My Activities” is a React component with JSON stuffed into a data-props attribute.
• Logging in means grabbing a CSRF token from a page and then POSTing it back.

I wasn’t expecting any of this to be documented. It was mostly poking around in DevTools, trying a few requests, and seeing what broke. I also borrowed patterns from the Chrome extension.

What It Can Do

Right now it’s split into public tools (no login) and authenticated tools (your account).

Public tools:

• Search activities by type, branch, difficulty, date
• Search courses, trip reports, and routes
• Get full details for any activity, course, trip report, or route

Authenticated tools:

• Your upcoming activities and course enrollments
• Completed activity history with filtering
• Earned badges and certifications
• Member profiles and activity rosters

The public tools are basically a convenience layer over information anyone can see on the website. The authenticated tools are where the personal stuff lives.

Example Session

Two real screenshots from Claude Desktop:

Upcoming courses with open spots

One activity, with the details pulled into a single view

No clicking around. No manually redoing the same filters.

The first cut was messy

The first version was useful but rough:

• Some list tools returned bare arrays, so the client couldn’t tell when results were truncated.
• Some detail pages had fields I wasn’t extracting yet.
• Filters were inconsistent across endpoints.

I pushed a cleanup pass here: ListResult<T> wrappers for truncation, multi-leader extraction for activities, structured date parsing for courses, plus more filters across the list tools. That work is in this PR.

At one point I kept asking Claude to “do better,” and it responded by writing 200+ tests. Turns out HTML parsing breaks in quiet ways. One template tweak can turn “works fine” into “returns an empty list” and you don’t notice until you ask at the wrong time.

Using it

If you want to use it, it works in Claude Desktop, Claude Code CLI, and Codex CLI. The README has the current install/run instructions:

• README

You can’t use it in ChatGPT Desktop without hosting infrastructure that runs the server and proxies a logged-in session to mountaineers.org. That would mean building something that can see your credentials. I don’t want to ship that.

Your credentials stay on your machine and are only sent to mountaineers.org. Nothing goes to any AI provider.

If you find bugs or want features, open an issue.

Related: This is part of a series of mountaineering tools I’ve been building. I wrote about building my first Claude Code skill and how AI agents are changing where the actual work happens.

Cheers.

Not because I’m suddenly more creative. Because building stuff got faster. When you can go from “I wonder if…” to a working prototype in an afternoon, you start noticing more itches worth scratching. A dashboard for ski conditions. A break-even calculator for EV charging. A CLI for searching mountain peaks.

A lot of these are afternoon builds. Some would take weeks. A few will never happen. But I kept losing them, scattered across Notion pages, random notes, half-remembered thoughts.

Where Ideas Went to Die

I had a system, but it was fragmented. Some notes in Notion, some in my head, some as random GitHub issues scattered across repos. No single place to look.

I like to keep my brain tidy. Offload things to a dedicated place so I’m not carrying them around. But my “dedicated place” was really five different places, none of which talked to each other.

Why GitHub Issues

Since I’m already living in a GitHub + Claude Code world, I figured: why not keep ideas where I already work?

Coding agents can access GitHub directly. I can point Claude at an issue and say “brainstorm this with me,” and it has full context. Sure, there’s a Notion MCP, but it doesn’t work well with Claude Code on the web or other async workflows I use on the go.

This website lives on GitHub Pages, so ideas live in the same repo where I’ll eventually publish posts about them. Keeps the pipeline in one place.

And issues have just enough structure (labels, checklists, comments, close/open states) without becoming a project management tool.

The “Itch & Pitch” Template

After a few rapid iterations, I ended up with a GitHub Issue template that forces me to think through an idea before I start coding:

## The Itch (Why?)
What sparked this? What's annoying you?

## The Pitch (What?)
One or two sentences describing what you're building.

## The Destiny (Who?)
- [ ] Just Me (Localhost/Scripts)
- [ ] Friends & Family (Shared link/Group chat)
- [ ] The World (Public launch/Blog post/Portfolio)

## The Playground (Fun/Tech)
What new tools are you exploring with this?

## AI Brainstorming Context
Core constraints, rabbit holes to avoid, success criteria.

The template is mostly settled, but I’m still experimenting with the “AI Brainstorming Context” section. I use Obra’s superpowers brainstorming skill, which picks up context from the issue and steers the conversation in the right direction. No more “let me suggest a Kubernetes cluster for your weekend project.”

Example: EV Break-Even Calculator

I recently built an EV vs gas break-even calculator after a conversation with my dad at a charging station. The issue looked like this:

I paid $0.56/kWh at a DC fast charger and started wondering about the break-even point compared to gas. Wanted a mental model for when EV charging is actually cheaper.

The “Destiny” checkboxes helped me scope it. This wasn’t just for me, I wanted to share it publicly, which meant building something polished enough for a blog post.

The playground section reminded me I wanted to try Plotly.js for visualization. Single HTML file, no backend.

90 minutes later: published calculator, blog post, issue closed.

From Idea to Blog Post

Open Claude Code in a new session on this repo. Tell it to file a new issue using the template. This seeds the context with the Itch & Pitch structure.

Then I ask Claude to brainstorm using superpowers. The brainstorming skill picks up the constraints from the issue and keeps things focused. From there I can track the work, build, ship, and publish.

I also leave comments on the GitHub issue as I go, notes for future enhancements, or food for thought when writing the blog post later.

Will This Stick?

Honestly? I don’t know. I’ve been using this for a few weeks and it’s working well. Having ideas in one AI-accessible place feels like the right foundation. But I’ve also abandoned plenty of “systems” before.

What I do know: the friction between “random idea” and “thing I can actually work on” dropped significantly. And that’s worth something.

The template is available as a gist if you want to steal it.

Related: I wrote about where the work actually goes when you’re building with AI agents — the workflow that makes these quick builds possible.

Cheers.

I think Gas Town is directionally correct but you have to admit also unhinged in a bunch of ways. I can’t help but be attracted to the absolute gonzo yolo mentality that birthed it, but I wouldn’t want to live there.

It’s been rattling around in my head since. He’s right on both counts. And I say that as someone who actually lives there.

The main thing I keep noticing isn’t the tools. It’s where the work goes.

Over the last six months living in Gas Town, the biggest shift hasn’t been speed, it’s attention. This post is about how that attention moves upstream into design and guardrails, and how the feedback loops change once you stop reading every line.

I Live in Gas Town

What Gas Town Is

For the past six months I’ve been experimenting with Gas Town and other ways to orchestrate AI-driven development, both for work and personal projects. Gas Town is Yegge’s multi-agent orchestration system for Claude Code. It coordinates 20-30 agents working on tasks simultaneously. Mad Max-themed terminology: a Mayor agent you talk to, Rigs for projects, Polecats as ephemeral workers. It’s a machine for spending hundreds of dollars a day on Claude API calls while you focus on feeding it design work.

The pitch: agents lose context on restart, so Gas Town persists work in git-backed hooks. You tell the Mayor what you want, and it orchestrates implementation across multiple agents while you go do something else. Throughput at the speed of thought.

Why I Live There

Is it gonzo? Absolutely. Would I want to live there? I already do.

The Trade: Distance Is the Gain

The trade is simple. AI-assisted coding has increased my productivity and the distance between me and the code. These aren’t separate effects. The productivity gain is the distance. You can’t have one without the other.

I no longer read every line that gets written. I don’t even read most lines. That used to bother me until I realized the work had moved.

Two Modes of Attention

Looking back at how I produce code now, it breaks into two distinct modes:

Autopilot Mode (70%)

Small features, bug fixes, routine changes. I describe what I want, Claude implements it, CI runs, it merges. I give little attention to implementation details.

This sounds reckless until you consider what’s actually in place. Unit tests with decent coverage. Linters catching style issues. Formatters keeping things consistent. Type checking catching obvious mistakes. CI gates preventing broken code from merging. Pre-commit hooks running gitleaks for secrets.

Some of these workflows have solidified enough that I’ve codified them into Claude commands, skills, and custom prompts. Others are still experimental, patterns I use daily but haven’t formalized yet. As I notice approaches working reliably, I encode them. The codified workflows compound: each one means more work I can safely put on autopilot.

Deliberate Mode (30%)

New authentication systems. Terraform infrastructure. Database schema changes. Architectural decisions that will shape hundreds of subsequent changes.

This is where I slow down. A lot. I brainstorm with Claude before any code gets written. We discuss tradeoffs. I sketch designs. I ask Claude to poke holes in my thinking. Only then does implementation happen, and I read that code carefully before merging.

The goal isn’t to review every line. It’s to make sure the patterns and abstractions are right. If the foundation is solid, all the autopilot work that lands on top of it will be decent. If the foundation is broken, no amount of careful review on individual features will save you.

Failure Rate Snapshot

Across both modes, failures still show up. I pulled numbers from my logs to keep myself honest. Those are below.

A Quick Analysis

Numbers From the Logs

After the brain dump, I looked at my own session logs for January 4, 2026 through February 3, 2026 and pulled some basic numbers. I wanted a reality check before making claims.

• Sessions scanned: 1,130 total, 1,058 Claude and 72 Codex
• User prompts: 37,562
• Median session length was under a minute. P90 was around 25 minutes. P95 was about 100 minutes.
• Median prompts per session was 3. P90 was about 63.

Failure signals showed up in about 16% of sessions. When failures happened, they were mostly CI related. About three quarters of failure prompts mentioned CI. Fewer than one in ten mentioned pre-commit. Manual review was a small slice.

What the Numbers Point To

That points to two things. The tightest feedback loop is pre-commit, and agents fix those errors quickly. The weaker loop is CI, which fires later and is less visible unless I am actively watching the pull request. I think that is where the next productivity jump is. I need an automated handoff that watches CI until merge and reacts when it breaks. That connects directly to Steve Yegge’s Gas Town merge queue and refinery idea. If I can automate that step reliably, the whole system gets smoother.

I’m still figuring out how to run workflows reliably. In any reasonably large project there’s a chain from inspiration to requirements to design to implementation to landing. Landing means tests, lint, CI, deploys, and the integration environment still behaving. That’s where things go sideways. A lot of my learning in the last months has been about prompting and using deterministic tools, linters, tests, CI, so agents keep moving in the right direction.

Failure Modes & the Learning Budget

I discover new failure modes constantly. Claude gets confused by monorepos with multiple package.json files. It invents API endpoints that don’t exist. It confidently refactors code in ways that technically work but violate conventions I never explicitly stated.

Each failure teaches me something: a new instruction to add to CLAUDE.md, a test case I should’ve written, a pattern I should’ve established earlier. This is the learning budget, the cost of pushing boundaries in a space that’s still evolving rapidly.

I’m excited by it, and I’m not pretending I’ve figured it out. I’m sharing where I am right now, six months into living in a full-time multi-agent, herd-the-agents workflow. Gas Town is just one influence.

Feedback Loops

Deterministic vs. Fuzzy Loops

What actually keeps quality stable is feedback loops that build confidence.

Some loops are deterministic: tests, linters, type checks, CI gates, pre-commit hooks. Other loops are fuzzier: prompt constraints, checklists, review rituals, and the explicit constraints I hand to agents. The confidence comes from overlap. When multiple signals agree, I move faster. When they disagree, I slow down and tighten the loop.

If your loops are thin, no tests, no types, weak CI, you cannot put anything on autopilot. You end up reviewing every line because that is your only quality gate.

What I Want to Measure Next

There is also an open question I want to dig into later: observability for these loops. I want metrics on which loop actually caught the failure.

• How many times did the agent hit a unit test failure in pre-commit?
• How many times did CI fail a pull request because earlier stages missed it?

If you have ideas here or have built something along these lines, let me know. I’m curious to learn.

Operating Loops I Use

The concept is concrete in the day-to-day. A few operating loops have become routine:

• Recon pass. I ask an agent to scan a neglected area, map what’s off, and propose a small set of changes. Sometimes it turns into a feature, often it’s just debt.
• Targeted sweep. Pick one pattern that’s been bothering me and update it everywhere in one pass.
• Codify the pain. If I ask for the same thing twice, I turn it into a skill or a command. If it’s deterministic, I drop to a script.
• Guardrail tuning. When something fails, I tighten prompts or CI gates before the next run.

These aren’t planned work. They’re opportunistic and show up when I have spare cycles.

I’ve also noticed a new loop: solve the thing, then codify it, then move on. If a task repeats twice, I start thinking about the skill or command that would make it deterministic. That impulse didn’t exist for me before. Now it shows up almost automatically.

What Changed for Me

The New Relationship with the Codebase

It’s a different relationship with a codebase. Less intimate, more managerial. I know what’s there at an architectural level, but I don’t have line-by-line familiarity anymore. And I’m okay with that.

If anything here sticks for me, it’s where the work went: up front into design and guardrails, then back into review loops. Everything else is still moving.

Delegation Isn’t Reckless (If Guardrails Exist)

Gas Town does feel gonzo. But the underlying intuition, that we can trust automated systems more and human review less, isn’t actually crazy. We’ve been moving in that direction for decades. Compilers, type checkers, linters, CI pipelines, code review tools. AI agents are just the next layer.

Delegating to autopilot isn’t reckless if you’ve built the infrastructure to catch falls. It’s just acknowledging where the actual value of human attention lies.

Related: I’ve written about the tools that support this workflow — session topic summaries for tracking parallel sessions, running Claude Code remotely from my phone, and building my first Claude Code skill. I also wrote about how I track ideas for projects like these.

Cheers.

We came up with some rough numbers on the spot, but I was curious what this actually looks like in perspective.

The Question

The basic question is simple: when does charging an EV cost more or less than filling up a gas car for the same distance?

The answer depends on a bunch of variables:

• Your EV’s efficiency (mi/kWh)
• Battery size and how much you’re charging (10% to 85% vs 20% to 80%)
• Electricity price (home charging at $0.12/kWh vs DC fast charging at $0.56/kWh)
• Gas price in your area
• What kind of gas car you’re comparing against (a Prius vs an F-150)

The Calculator

I built an interactive calculator that visualizes all of this.

The heatmap shows cost difference across two dimensions:

• X-axis: Gas car fuel efficiency (MPG) - from gas-guzzling trucks to hybrids
• Y-axis: Electricity price ($/kWh) - from cheap home charging to expensive DC fast charging

Green means the EV is cheaper. Red means gas is cheaper. The break-even line shows where costs are equal.

What I Learned

A few things became clear:

Home charging is almost always cheaper. At typical home rates ($0.10-0.15/kWh), my Rivian R1S beats everything except the most efficient hybrids. Even comparing against a 30 MPG sedan, I’m saving money.

DC fast charging changes the math. At $0.56/kWh (what I paid at Electrify America), my Rivian only beats gas cars getting worse than about 22 MPG. Against a typical sedan, gas is actually cheaper per mile.

The break-even point shifts dramatically by state. In Washington, we have cheap electricity ($0.12/kWh average) but expensive gas ($4.02/gal). That’s favorable for EVs. In Texas, cheap gas ($2.45/gal) makes the comparison tighter.

Try It

The calculator has presets for common EVs (Tesla Model 3/Y/X, Rivian R1S/R1T, Cybertruck) and all 50 US states. Select your car and state to see your specific scenario, or adjust the sliders manually.

Open the calculator

The state prices table at the bottom shows average gas and electricity prices across the US, with a ratio column showing which states favor EVs the most.

This calculator started as a side project idea I tracked in GitHub Issues — from itch to published tool in 90 minutes.

Source

Built with Plotly.js for the heatmap visualization. Single HTML file, no backend, works offline. Source on GitHub.

Some are rapid-fire sessions where I’m iterating on code quickly. Others are slow burners that sit around for days while I context-switch to other work. The problem: when you come back to one of those slow sessions, you get that familiar moment of staring at the transcript thinking, what was I doing here again?

Claude Code doesn’t help. There’s no at-a-glance “this session is about X” indicator. You end up scrolling up, re-reading, trying to reconstruct context like you’re debugging your own brain.

So I built a thing.

The Idea

Put a one-line topic summary in the status line for each session. Keep it fresh automatically. Think Slack or Discord channel topics, or the old IRC topic line, but for Claude Code sessions.

Example lines:

• OAuth debug: fixing schema validation (5m)
• Blog post: adding code snippets (2h)
• tmux config: wiring session display (<1m)

The summary has two parts:

1. Theme - what is this session fundamentally about
2. Current focus - what we’re doing right now

Plus a relative timestamp so you can see whether the summary is stale. If it says (2h), it might not reflect the last few messages.

Implementation

It’s mostly glue around Claude Code’s hooks system:

• The Stop hook fires on every message
• I throttle actual generation to every 10 messages, because empirically session themes stay stable across 40-50 messages while focus shifts every 8-10
• When the threshold hits, it spawns a background job that reads the session transcript (JSONL), extracts recent context, and calls Claude Haiku via the claude CLI
• The hook returns quickly (tens of ms) so Claude Code stays snappy, while summary generation happens async
• A lock file prevents multiple generations from running at once

Things I Learned

Along the way I discovered a few annoying but useful things.

Summary generation can take 10-60 seconds depending on transcript size and complexity. You really don’t want it blocking the hook.

The claude CLI has overhead you don’t need for this use case. Turning off session persistence with --no-session-persistence and disabling tools with --tools "" helps.

Haiku occasionally ignores formatting instructions unless you’re very explicit. “Output ONLY the topic line” and “Do NOT output the word ‘Theme’ literally” got me to 100% format compliance.

If you go full set -euo pipefail in a script that renders your status line, you’ll eventually get a useless exit 1 in your UI instead of a fallback message. Ask me how I know.

The Plugin

I packaged this as claude-session-topics. The plugin registers the Stop hook automatically. Run /setup-statusline to configure your status line display.

Anyway, if you’re the kind of person who keeps multiple Claude Code sessions open and hates reloading context by scrolling, give it a shot. I also wrote about running Claude Code remotely from my phone and building a daily summary skill, both of which build on the same hooks system.