Claude Code Skills

Most AI coding tools assume the user is a developer. I work directly in production codebases, often opening PRs alongside specs. I wanted that workflow to be more fluid, and more accessible to designers who are starting to work the same way. I built two open-source toolkits for Claude Code to make that happen.

Repos: dcode · codekit

Two Toolkits

dcode is for designers who work in code but don’t live there. Six skills: find components from screenshots, rewrite copy using Jobs to Be Done frameworks, audit UX microcopy against 10 writing frameworks, frame PRDs around user jobs, mine sessions for repeatable patterns, and reflect on what you learned.

codekit is for daily workflow. Four plugins spanning 26 commands: task management with a coaching model (do:), dev automation that auto-detects your project type (dev:), session continuity across terminal closures (sesh:), and component discovery from visual input (find).

Both are published on the Claude Code marketplace. Both use colon-namespaced slash commands. Type the prefix and related commands appear.

Namespace Convention

The naming system didn’t start clean. Early on I had scattered commands with no consistent prefix. I kept forgetting where things lived. The fix was a colon-separated namespace convention applying information architecture principles:

do:       task management     do:coach, do:add, do:list, do:done
dev:      dev automation      dev:start, dev:pr, dev:rebase, dev:commit
dcode:    design in code      dcode:find, dcode:uxcopy, dcode:jtbd-copy
sesh:     session continuity  sesh:save, sesh:resume, sesh:close

Type a prefix and related commands appear. Short prefixes mean minimal friction. The tool disappears and you think about the work, not the interface.

Key Design Decisions

Screenshot-first input. A designer’s native language is visual. dcode:find takes a screenshot and locates the component in code: the route, the styles, the tests, the sub-components. You don’t need to know the file tree. You show the tool what you see.

One question at a time. AI agents tend to dump multiple questions simultaneously, creating cognitive overload. do:coach asks one question, waits for the answer, then adapts the next question based on the response. The conversation is sequential, not parallel. It feels like talking to a person, not filling out a form.

Persistent files for continuity. AI memory doesn’t survive session boundaries. Goals, coaching history, and task lists live in markdown files (~/.claude/goals.md, ~/.claude/coach-history.md) that get read at the start of each session. The AI doesn’t need to “remember.” The files are the memory.

Challenge assumptions. The coaching skill detects guilt-driven language. “I should probably…” triggers a pushback: “This task doesn’t align with any stated goal. Drop it?” The AI acts as an accountability partner, not a yes-machine.

Context lookup offer. Before expanding scope (checking Slack, pulling Linear issues), the skill asks permission. The user controls whether the agent reaches into other systems. Trust comes from asking, not assuming.

Apply-to-similar. When auditing UX copy across a codebase, you make the same category of decision repeatedly. dcode:uxcopy offers an “r” shortcut that applies your choice to all items of the same type. Batch decisions without losing control.

Learning Loops

The most important design decision: skills that generate knowledge, not just output.

dcode:reflect captures what you learned in a coding session. do:learned stores it as a journal entry. do:review synthesizes patterns across entries over time. dcode:mine analyzes productive sessions to identify workflows worth turning into new skills. Each session feeds the next.

How I Work With These

I use both toolkits daily. The JTBD copy skill I built for dcode is the same one I used to write the microcopy framework for Automattic for Agencies. The session skills (sesh:save, sesh:resume) are how I maintain continuity across every project, including this portfolio site. dcode:mine is how I identified which workflows were worth turning into skills in the first place.

The philosophy is simple: ship, use, feel the friction, fix. Ergonomics only emerge through real use.