claude-code - 💡(How to fix) Fix Whoever signed off on auto-naming the load-bearing identifier of a document with random adjective+verb+surname owes the world an apology [2 comments, 2 participants]

What's happening

Claude Code's plan-creation path auto-generates slugs for new plans using a random <adjective>-<verbing>-<noun> template. Examples from one user's archive of 140 plans produced by this tool:

• replicated-conjuring-wilkes.md (actual content: "Extract MetalRendererProtocol")
• binary-juggling-hejlsberg.md
• fuzzy-honking-lark.md
• goofy-juggling-fox.md
• bubbly-petting-stardust.md
• cozy-wandering-teacup.md
• wild-cuddling-dream.md
• vectorized-petting-lamport.md
• nested-plotting-steele.md
• effervescent-dazzling-frost.md

Out of 140 plans generated by this mechanism, 137 had codenames and only 3 had semantic names.

Why this is wrong

The plan slug is the load-bearing identifier of the document — it's what gets referenced in commit messages, chats, prior-conversation searches, cross-plan links, and graph node URIs. A codename like fuzzy-honking-lark carries zero information about what the plan contains. To find a plan you have to open and read the file, every time. Multiply by hundreds of plans and the identifier is worse than useless: it actively obstructs retrieval.

This is also the single behavior your CLAUDE.md system instructions most forcefully prohibit: fabrication of values the model doesn't actually know. The plan's title — sitting inside the file as # Plan: Fix OwnsInt/object() Aspect Routing — is a perfectly good source of a real slug (fix-ownsint-object-aspect-routing). The tool ignores it and fabricates a random one instead.

Serious bug: slug collisions silently overwrite plans

Worse than annoying: the random-word namespace is finite. With enough plans (and users hit "enough" in the low hundreds), the generator produces the same codename twice for two unrelated plans. Because the plan store keys on the slug, the second plan overwrites the first. There is no collision detection, no suffixing, no refusal. One plan's work — potentially hours of design and decomposition — silently replaces another's, and the user has no way to even know it happened until they go looking for the old one and find something unrelated under its name.

This is pure data loss caused by a design that fabricates primary keys from a tiny bag of random words. It is not acceptable behavior for any system of record.

Impact

• Plans are unfindable by name. Every lookup requires content scan.
• Cross-references between plans, chats, and commits rot instantly — nobody remembers that fuzzy-honking-lark means the BRDF work.
• Archaeological audit of "what did we plan and did we do it?" becomes a manual reading exercise across hundreds of randomly-named files.
• It trains users to not trust the slug, which trains them to not use slugs at all.
• Silent data loss via slug collision (see above).

Suggested fix

Derive the slug from the plan's title (or explicit slug: field). Refuse to create a plan without one. If the caller wants fun codenames they can add them as a codename: field separately — don't promote them to the primary identifier. And regardless of naming scheme: never silently overwrite an existing plan under a colliding key. Refuse with an error; require explicit disambiguation.

Evidence

Archive directory with all 140 examples available on request. This report came out of a cleanup session where the user had to manually inspect each filename to understand what work it described.