9 Months of Customizing Claude Code: What I Built and Why

Most people install an AI coding assistant, run the defaults, and call it a day. I did the opposite — I treated Claude Code like an operating system and spent six weeks turning it into something that thinks the way I think.

Last week I ran an audit on my own setup. The numbers surprised me: 9 custom skills, 55 plugins, 2 hooks, a daily pipeline, and a memory system — all built incrementally, one frustration at a time.

This isn't a tutorial. It's a behind-the-scenes look at what happens when a UX designer treats their AI workspace the way they'd treat a product: deliberately, iteratively, and with strong opinions about how things should work.

The System: Skills, Plugins, and Hooks

Claude Code lets you extend it with skills — markdown instruction files that teach the AI new workflows. Think of them as reusable prompts with superpowers.

Here's what I built:

• create-content — A 9-step pipeline that turns raw inputs (images, PDFs, voice memos, links) into publication-ready MDX blog posts with social media variants. The blog post you're reading right now was written using this skill.
• morning — Chains three daily commands (/sync → /start → standup summary) into a single hands-off morning routine. NotebookLM auth pre-flight included, with automatic retry.
• notebooklm — 326 lines of living API documentation for an undocumented API. Claude references this when I need to build NotebookLM integrations.
• journey-audit — The meta-skill that produced the audit I'm writing about. Built to be re-runnable, so I can track how my setup evolves over time.
• interview — Generates STAR-format interview prep briefs from a persistent story bank. Researches the company, maps my experiences to likely questions.
• rapid-learning — A 4-step framework for absorbing new tech concepts. Includes Hungarian trigger phrases, because I think faster in my native language when learning.

The 55 plugins are mostly community-built extensions — LSP servers for 9 languages, integrations with Figma, Firebase, GitHub, Slack, Supabase, Vercel, and a personality plugin called Ralph Wiggum (because customization isn't purely utilitarian).

Then there are the hooks — small automations that fire on specific events:

1. TypeScript Auto-Check — Every time Claude edits a .ts or .tsx file, the hook runs tsc --noEmit and pipes the first 20 errors. TypeScript violations surface instantly, not three tools later.
2. Completion Sound — When Claude finishes a task, afplay ~/Desktop/exhale.wav plays a sound. A tiny UX touch that means I can walk away from the terminal and hear when it's done.

The Daily Workflow

The part I'm most proud of is the morning pipeline. One command — /morning — and Claude:

1. Processes my scratchpad (extracts to-dos, ideas, random notes from yesterday)
2. Checks meeting notes for action items
3. Syncs with NotebookLM for a "Morning Spark" — curiosity themes and action ideas based on my research
4. Updates my task board and daily note
5. Suggests 2–3 priorities for the day
6. Generates a paste-ready standup summary for Slack

At the end of the day, /wrap-up reverses the flow — reviews unfinished items, updates the daily note, and generates a summary.

No external apps. No integrations beyond NotebookLM. Just markdown files, Python scripts, and Claude commands orchestrated by a skill. It's a complete daily productivity system built entirely inside a code editor.

What Surprised Me

Skill-first thinking changes how you see problems

Once I had 4–5 skills, my brain started classifying every repeated workflow as a "potential skill." Interview prep? Skill. Content publishing? Skill. Even auditing my own setup? Skill. It's the same instinct that UX designers develop for spotting patterns — but applied to personal tooling.

Accessibility became non-negotiable by default

My CLAUDE.md config mandates ARIA roles, keyboard support, and focus management on all interactive components. Tests verify it. This started as a preference and became infrastructure — every project I start with Claude Code gets accessible components from minute one, because the AI won't generate them any other way.

Hungarian-first isn't localization — it's a thinking tool

UI content defaults to Hungarian. Learning triggers include Hungarian phrases. My rapid-learning skill accepts "tanulás" and "tanuld meg" as commands. This isn't translation — it's a deliberate choice to think in my native language where it matters most: learning and daily workflows.

The completion sound was the biggest UX win

Sounds trivial, but exhale.wav playing when Claude finishes a task completely changed how I use it. Long-running tasks (like this audit) can take minutes. Audio feedback means I make coffee, stretch, check my daughter's homework — and hear when it's time to come back. It treats Claude Code as a workspace environment, not just a terminal.

The Evolution

Looking at the file dates tells a story:

Week 1–2 (late January): Discovery. Installing community skills, figuring out what's even possible. Simple config skills and a skill-finder.

Week 3–4 (early February): First major project — a fintech mobile banking prototype. This is where patterns crystallized: TypeScript zero errors, accessibility as a constraint, Hungarian localization, testing as standard.

Week 5 (late February): Methodology phase. Codifying how I learn, not just what I build.

Week 6 (early March): Infrastructure maturity. Full content pipeline, daily workflow, interview prep, NotebookLM integration, and the meta-tool that produced this audit. The setup shifted from "using Claude Code" to "building a personal operating system on top of Claude Code."

What's Honest

This setup has gaps:

• No global commands — My daily workflow is project-scoped to one directory. It should be available everywhere.
• Memory fragmentation — I have one memory file. The planned topic-specific files (patterns, debugging, preferences) don't exist yet.
• 10 duplicate plugins — Same plugins installed from both official and community marketplaces. A cleanup pass is overdue.
• No testing for skills — Skills are validated by daily use, not automated tests. This is a gap I'd never tolerate in product code.
• The evening routine isn't a skill yet — /wrap-up exists as a command but isn't chained into an /evening skill like /morning chains /sync + /start.

I'm not showing you a polished system. I'm showing you a living one — with all the rough edges that come from building in public, one frustration at a time.

The Philosophy

If there's one takeaway, it's this: treat your AI tools like products, not utilities.

Don't just use the defaults. Don't just install plugins. Think about your workflows the way you'd think about a user journey — where are the friction points? Where do you repeat yourself? Where does context get lost?

Then build for it. One skill at a time.

This post was generated using my create-content skill, from an audit produced by my journey-audit skill. The source material is a raw 18KB markdown document that Claude processed into what you just read. The irony is not lost on me.