A small skill dropped this week, and it fixes a problem most of us didn’t even know we had. It’s called “glossarize,” and it’s not about code quality or speed. This Reddit user, MirafoldHQ, built it to solve something quieter: you and your AI agent don’t actually agree on what things are called.
Here’s the setup. Every project grows its own private language. You call it the “queue worker,” your agent calls it the “job processor,” and three files down there’s a function that does the same thing under a third name nobody chose on purpose. Multiply that by six months of AI-assisted coding, where you’re reading less code and trusting more summaries, and the mismatch gets expensive. You think you’re talking about the same thing. You’re not. And the gap doesn’t announce itself. It just sits there quietly until the day your agent refactors the wrong module because “processor” meant one thing to you and another thing to it.
This is the kind of drift that never shows up in a bug report. Nobody files a ticket that says “our naming is inconsistent.” It just slows everyone down a little bit every single day, one small misunderstanding at a time, until eventually you’re spending more time clarifying what you meant than actually building.
What’s new: glossarize has your agent go do a deep dive of your entire project. It maps out what things are already called, flags the inconsistent naming, finds the core parts that never got a real name at all, and comes back with a report. Not a lint warning buried in a terminal scroll. An actual document you can sit down and read, organized by area of the codebase, showing you exactly where the same concept wears three different hats.
The twist is what happens next. This isn’t a linter that silently renames stuff and calls it done. It’s the start of a conversation. The agent hands you its findings and then opens a back-and-forth brainstorm session, arguing through naming decisions with you until you both land on terms you actually agree on. Say the agent found four different names for what’s basically your rate limiter. It doesn’t just pick one and move on. It asks you which mental model fits best, pushes back if your first answer creates a new inconsistency somewhere else, and keeps negotiating until the name actually sticks. The output is a glossary file, a shared vocabulary that makes every future conversation with your agent sharper, because you’re finally speaking the same language about your own project.
How the workflow runs, based on what the creator described:
- 🔍 Agent scans the codebase and inventories existing names, including the inconsistent ones
- 🧩 It flags the unnamed pieces: features, modules, concepts that never got a proper label
- 💬 It reports back and opens a dialogue, proposing names and asking for your take
- 🤝 You go back and forth until terms are locked in
- 📓 It writes the final glossary so both of you can reference it going forward
One detail worth calling out: the creator says this works even better once you’ve stopped reading every line of code yourself. That’s the exact moment naming drift gets dangerous, because you’re relying on the agent’s mental model matching yours, and a glossary is the cheapest way to force that alignment. Think about it this way. The less code you personally read, the more your entire working relationship with the agent runs on shared vocabulary instead of shared memory. If that vocabulary is fuzzy, every instruction you give gets a little bit lossy in translation.
Pro tip: don’t treat this as a one-time setup step. The original poster says they’re running it on every project, spending a half hour to an hour each time, because naming things well makes a project more fun to work in. You get to decide what your own features are called instead of inheriting whatever half-baked variable name got typed at 2am. Run it after a big feature lands too, not just at project kickoff, since that’s usually when three new ad hoc names sneak in.
Second pro tip: run this early, before your codebase accumulates six different names for the same thing. Untangling naming debt after the fact costs way more than naming it right the first time. If you’re staring down a project that’s already a few months old and clearly tangled, don’t panic and try to fix everything in one pass. Let the agent surface the worst offenders first, agree on those, and pick the rest up on a second run.
Third pro tip: treat the glossary file itself as a living document, not something you generate once and forget. Drop it somewhere your agent reads automatically at the start of a session, so the shared vocabulary actually gets used instead of just existing.
The full skill spec and the discussion around it are sitting in r/PromptEngineering under this Redditor’s post, worth a read if you want the exact frontmatter to drop into your own setup. Go check it out and name something today.
Frequently Asked Questions
Q: Is glossarize just renaming things in my actual code?
No , it builds a shared vocabulary for talking about your project, separate from your code. The glossary helps you and your agent discuss the codebase using consistent house terms. You can implement those names in the code itself if you want, but the primary value is in precise communication, not refactoring.
Q: How iterative is this? Do I get one glossary or do we brainstorm back-and-forth?
It’s definitely back-and-forth. Glossarize opens the conversation with three ranked name candidates per part (one recommended pick + two alternates), then you react with your picks, rejections, or half-likes. Expect multiple turns , you decide what sticks, and the skill proposes fresh options on demand until you’ve settled the terms.
Q: What if my codebase has wildly inconsistent naming already?
That’s exactly what glossarize is built for. Part of the scan is untangling existing inconsistencies so you can see the pattern (or lack thereof), then establish a house register , a consistent style for this project. Once you’ve settled on that style, all new names follow it.
Q: Does this work for both visual apps and pure backend services?
Yes. Visual repos have surfaces, screens, and components to name; backend services have subsystems, pipelines, entities, and data structures. The skill adapts to what your repo actually is and focuses on the parts people need to talk about.
Q: When should I lock in the glossary? Do I need a formal document?
Once you and the skill have settled on terms through brainstorming, you can ask to finalize a glossary document , but only when you’ve actually decided. The skill won’t write it unilaterally. A locked glossary becomes your reference for future conversations with agents and teammates, ensuring everyone uses the same words for the same things.
Glossarize – make a glossary of terms for your project
by u/MirafoldHQ in PromptEngineering