Feeling the FONC (Fear of Neglecting Claude)

It’s the late 1700s. Your landowner friends won’t stop talking about their textile mills and you’re staring at your own little free-flowing stream thinking: why is that kinetic energy NOT MAKING ME TEXTILES RIGHT NOW.

That is me with my Claude Max plan. Feeling the FONC¹: Fear of Neglecting Claude.

I am doing all kinds of things with Claude, but if my Claude Max plan is a sun, I’m barely growing sunflowers. I need solar panels. I need a Dyson sphere.

The bottleneck keeps moving and I keep chasing it. Claude keeps waiting for my input. A few weeks ago I was juggling tabs with color-coded worktrees, a full-stack feature in each. The merges weren’t painful, but my own “did I build what I actually wanted?” reviews were. So I built a Claude plugin to turn screen recordings of bug rants into structured markdown feedback, and piped that back into the build loop. Bottleneck widened.

Then my backlog ran dry. What to build next, with these ridiculous powers, to help me expand these ridiculous powers even further? If code is now liquid, what are the critical skills for a code hoser? Unclear. This great Adam Jacob AI Native Infra Automation talk makes a good case for boning up on Domain Driven Design and software architecture. And aren’t both of those disciplines built on a foundation of design patterns, metaphors, and mental models? Quick search for “Wikipedia or TV Tropes or materials library but for metaphors” didn’t find much beyond MetaNet². How far could we run with this?

Metaphorex

Metaphorex is a knowledge graph of metaphors, mental models, archetypes, and patterns. 648 entries so far, each a markdown file with YAML frontmatter. GitHub is the CMS. PRs are drafts, merged is published.

I overdesigned v0 with a full CMS, custom auth, and extra metadata for bot contributions. Claude kept hinting I was working against the grain, trying to build a platform AND a content catalog simultaneously. I’m a Gall’s Law believer, and took the hint. The current version is a static Astro site on a public GitHub repo, deployed to GitHub Pages.

The napkin sketch I started from: anyone can suggest a collection of metaphors; a book, catalog, collection, or domain, then a system routes that ‘import project’ through stages where it’s mined and refined into a consistent taxonomy and writeup that’s interesting enough to peruse as a human, and structured enough to traverse as a tool.

Here’s how it came together.

Claude squad LARPs as a scrum team that LARPs as a mining company

I didn’t expect anyone would come contribute to an empty content catalog, and I wasn’t patient enough to write it myself, so I immediately started prompting around for seed content. Then quickly shifted focus from prompting for content to building the agents to do that work.

The Claude plugin marketplace includes a nice plugin-dev plugin for making plugins, so it didn’t take long to bring up an initial crew of agents. Inspired by Steve Yegge’s Gastown, I started with a small cast: a Prospector, a Miner, and an Assayer. The rest grew organically as bottlenecks appeared. The Smelter showed up when I got tired of formatting inconsistencies. The Surveyor when Prospector playbooks needed verification before mining could start. The Pitboss when I realized I was the orchestrator and I was the bottleneck.

The mining metaphor is wrong, though. Mining is for minerals. What I’m doing is closer to fossil fuel extraction: drilling into deposits of concentrated knowledge that took lifetimes to assemble, refining it into a fungible form, and burning LLM compute (also fueled by compressed human knowledge) to power the operation.

The current roster:

• Prospector: researches new sources, builds extraction playbooks
• Miner: extracts entries from playbooks (Opus, in a git worktree)
• Smelter: mechanical cleanup, validation, formatting (Haiku, cheap)
• Assayer: quality review, approves or requests changes (Sonnet)
• Pitboss: the /work command that orchestrates all of the above

Each agent has a markdown file defining its role, tools, and scope. The Pitboss dispatches work in rounds: survey the repo for actionable items, assign agents in parallel, wait for completion, print a summary, loop. The stop condition is total_actionable == 0. I had to add that rule to the agent’s memory after it tried to stop early one day to “save me money.” We’re not here to save money, we are spraying tokens at this coal face and fracking ourselves a knowledge graph!

I didn’t set out to recreate the scrum team, but some combination of my muscle memory and all the Agile documents ingested by Common Crawl (and from there into every training dataset) must have led us to it. The round summary is a standup. GitHub Issues are the backlog. The Pitboss reads the backlog and dispatches each sprint. Retros? That’s the kaizen loop (more on that below). Yeah, this is kinda enterprise theater. But with five agents working the same repo, you need some process to keep them from stepping on each other.

The kaizen problem

Every agent files “kaizen” issues (opportunities for improving system efficiency) when it hits friction. Smelter notices a counting bug. Assayer discovers GitHub blocks self-reviews. Miner gets confused by nested worktrees. They file the issue, label it kaizen:pipeline, and move on.

The Pitboss reports these each round:

### Kaizen
- Open: 18 issues
- #1470 (GitHub blocks self-review), #1489 (smelter counting bug), ...
- No kaizen resolved this round.

Hmm, eighteen issues, none resolved this round. The pipeline reports on kaizen but never fixes it. Here’s how Claude summarized the gap when I asked it to audit the situation:

What agents do today with kaizen:

 Role      Files                                                 Fixes
 Agents    File kaizen at end of run                             Never
 Pitboss   Report counts, escalate if 3+ agents hit same issue   Never
 Human     Reads round summaries, sighs                          Occasionally

That “sighs” is my favorite line Claude has ever written. Passive-aggressive and accurate.

Eight of those 18 are fixable by an agent right now. Two need me to make an architectural call. The rest are bigger projects. The fix is obvious: add a kaizen triage phase to each /work round. Read the backlog. Classify. Pick one. Dispatch a fixer. One improvement per cycle. Not zero (current). Not all at once (chaos). If all goes well, the system keeps improving itself.³

The honest part

This is not a dark factory. Everything runs inside Claude Code, in my terminal, on my machine. The agents can’t wake up at 3am and process a batch. They can’t respond to a webhook. They can’t even refresh their own GitHub token. When I close the laptop, the mill stops.

I could fix that. I could run it through a deterministic loop, with each agent in its own tmux session. I could have the Pitboss poll for new issues and dispatch agents autonomously. But that would mean ripping open the panel where the OAuth token is hiding and risk running afoul of the terms of service for the Claude Max subscription that is the inspiration for this whole project. I am tinkering, on the path to manufacturing, and I’m okay with the workshop living in someone else’s loop until it proves itself.

Also this: I am now a slop jockey running a content mill on the backs of my well-below-market unpaid nonhuman staff. I’m not unconflicted about this! But I’m hopeful that this type of synthetic data is not the seeping model collapse hazmat folks are worried about.

Where this is going

The catalog is still growing, but I don’t yet have a clear path to making it useful. I didn’t expect my naive “stuff metaphors into a context window” or “vector search metaphor RAG” to work miracles, and they don’t. I didn’t even have a clear sense of how to test my vague value proposition. The quickie evals I came up with showed that baseline Claude could work with metaphors better than Claude + Metaphorex. But if you’re curious, please do have a look, and then head over to Github and leave a star, file an issue, or contribute a PR.

There’s research on structured reasoning scaffolds (SELF-DISCOVER, analogical prompting, SKiC) suggesting a different approach. Maybe the value isn’t in the content of the entries but in the names and the structure. Priming a conversation with just the names and one-sentence summaries of well-chosen patterns activates reasoning modes that content injection doesn’t. The catalog might be more useful as a menu of reasoning modules than as a reference library.

So the FONC returns — leaving the Metaphorex mill / mine / factory running is not enough. Expanding the breadth and scale of a mostly-synthetic metaphor catalog is unlikely to solve any new problems. I will need to try some other approaches. Most importantly, if the goal is to improve aptitude at a task that’s hard to measure (system thinking, architecture), how do you know you’re on the right track? And if the goal is to avoid mixing metaphors, I am starting from a sub-basement baseline.