After a month of building Claude Code skills and commands, I had 25+ scattered across my config folder. Some had prefixes, some didn’t. Some were duplicates. Finding the right command meant remembering arbitrary names.

The cognitive load added up: instead of the tool being a thinking extension, I was thinking about the tool.

The before

craft:create-pr      ← git stuff
craft:reflect        ← actually session stuff
craft:save-session   ← session stuff
smart-commit         ← git stuff, no prefix
learned              ← productivity, no prefix
add-task             ← duplicate of another command
build                ← dev stuff, no prefix

No mental model. Just accumulated commands.

The fix

Namespaces aren’t just organization. They’re muscle memory. When I type /do I see everything related to productivity. When I type /dev, I see code workflow. The prefix becomes a mental shortcut.

do:       productivity      do:coach, do:add, do:list, do:done
dev:      dev workflow       dev:start, dev:pr, dev:rebase, dev:commit
dcode:    design in code     dcode:find, dcode:uxcopy, dcode:jtbd-copy
sesh:     session mgmt       sesh:save, sesh:resume, sesh:close

Four namespaces. Each one a distinct mental model. Type the prefix and the options appear.

Why it works

This is information architecture applied to CLI.

Miller’s Law says humans hold roughly seven items in working memory. With 25 scattered commands, you’re over the limit. But four namespaces? Easy. Then within each namespace, you’re choosing from 5-12 commands. Manageable chunks.

The namespace becomes the first filter. You don’t scan 25 commands. You pick a category, then scan a short list within it. Same principle behind any good navigation system, applied to a terminal.

Design principles

Verb-first namespaces. do: not productivity:. dev: not development:. Short prefixes mean less friction. Every character you save compounds across hundreds of daily invocations.

Group by mental model, not implementation. sesh:reflect is about the session, not about “crafting.” Move it to where you’d look for it. The structure should match how you think, not how the code is organized.

Delete duplicates ruthlessly. If add-task and do:add do the same thing, one has to go. One way to do things. No ambiguity.

Separate concerns clearly. dcode:find is for designers navigating codebases. dev:start is for running a project. Different jobs, different namespaces. You never confuse which one you need.

The meta point

This reorganization took maybe fifteen minutes. But the cognitive load it eliminated is permanent. Every time I reach for a command now, the namespace tells me where to look before I even start typing.

The goal of any tool is to disappear. You shouldn’t be thinking about the interface. You should be thinking about the work. Namespace conventions are one way to get there: small, structural decisions that remove friction from everything that follows.

Both toolkits are open source: dcode for designers in code, codekit for daily workflow.