From Template to Custom in Under 20 Minutes: Claude Code, Plan Mode, and the Impeccable Skill

I rebuilt the entire frontend of this site in a single short session. New design system, new build pipeline, new color tokens, new typography, no theme dependency. The old Hugo template, the 36 Go modules, the 800-line custom SCSS — all gone. Replaced with Tailwind v4, ten hand-picked SVG icons, and a single main.css I actually own.

This post is about the workflow that made that possible: Claude Code, the /impeccable design skill, and plan mode.

The Setup: Fighting the Template

A few weeks back I migrated this site from Next.js to Hugo and picked up a polished theme so I could focus on writing instead of CSS. The theme looked good out of the box. It was also a heavily-opinionated stack: Bootstrap 5 SCSS, Font Awesome 6, jQuery-era plugins (Swiper, Glightbox, Shuffle, fuse.js client-search), and 36 Hugo Go modules for things like cookie consent, Crisp chat, Valine comments, AdSense, Baidu/Matomo/Plausible/Counter analytics, and a dozen shortcode helpers I never used.

I’d already overridden most of the page templates — index.html, single.html, about.html, contact.html, the header and footer. Each override had to fight the theme’s own SCSS defaults. When the audit pass came back showing a “monochromatic palette” and “washed-out body text,” I dug into why and realized the theme’s _typography.scss was setting body { color: muted } and p { color: muted } underneath everything I was doing. I was layering corrections on top of a foundation I couldn’t reach.

Time to stop fighting.

The Workflow: Three Tools, One Loop

Here’s the workflow that actually moved the needle:

1. /impeccable teach — establish persistent design context the AI can reference across sessions
2. /audit — get a structured assessment of what’s broken
3. Plan mode — ask Claude Code to design the implementation before touching code, then approve

The combination is what makes this fast. Each tool does one thing well, and they compose.

/impeccable: Persistent Design Context

The first thing I did, weeks ago, was run /impeccable teach. That skill conducts a short interview about who the site is for, what voice it should have, what aesthetic direction fits the brand. The output is a small .impeccable.md file at the repo root that any future Claude Code session reads automatically.

For Pocket Dev, that file says (in part):

### Brand Personality
The tone should feel calm, credible, and intentional. It should
communicate technical confidence without drifting into loud startup
polish or playful novelty.

### Aesthetic Direction
The site should read as a refined developer publication: editorial,
composed, and quietly opinionated. It should avoid generic AI-blog
aesthetics, avoid overly loud gradients or novelty effects, and make
the writing feel like the hero.

This matters more than it looks. Without that file, every AI session starts from “you’re building a website” and lands on a generic SaaS-blog aesthetic by default. With it, every design decision has a north star to argue against. When I later asked for a color palette, the AI knew “deep navy gradient on glassy cards” would violate the brief — because the brief was sitting in context the whole time.

/audit: Honest, Structured Assessment

The /audit skill runs a 5-dimension technical quality check: accessibility, performance, theming, responsive design, and anti-patterns. It scores each dimension 0-4 and produces a prioritized list of issues with severity tags (P0 blocking → P3 polish).

The first audit on this site scored 9/20 — Poor. The verdict was blunt:

The site is no longer AI slop, but a new anti-pattern has taken over: everything lives in the same blue-charcoal hue family. The accent is so close to the text-strong color that they read similarly. Body prose defaults to muted. The ‘similar hues’ you’re perceiving is real.

That’s the kind of feedback you don’t get from a generic “make my site better” prompt. It cited specific files, specific line numbers, computed actual WCAG contrast ratios, and explained why each finding mattered. It also listed the right next commands to run (/colorize, /distill, /polish).

I ran several rounds of those targeted fixes. They moved the score from 9/20 to 16/20 — meaningful progress. But the audit kept surfacing problems that traced back to the theme. I could keep playing whack-a-mole, or I could accept the structural verdict and rebuild.

Plan Mode: Design Before Code

This is where Claude Code earned its keep. Plan mode is a focused state where the AI does only read-only research and writes a structured plan to a file you approve before any changes happen.

I asked Claude to plan the theme removal. It spawned three parallel exploration agents:

1. One inventoried what the theme provided (layouts, partials, SCSS, JS, i18n).
2. One catalogued the project’s actual content, layouts, data, and config.
3. One audited every Hugo module to determine which were essential, which were replaceable, and which were dead weight.

That parallel discovery took maybe a minute. The plan that came out was concrete: copy these four theme files into the project, write minimal replacements for these three partials, strip these 36 modules from module.toml, set up Tailwind v4 via PostCSS, and so on.

Before approving, I caught a question I hadn’t considered. Claude asked which layout system I wanted: keep Bootstrap, drop it for modern CSS, or use something else. I answered “why not use Tailwind?” — which it took as a strong choice and reshaped the plan around. The plan that landed in front of me reflected my actual preferences, not its defaults.

Then I approved and let it execute.

The Phases: Why Decomposition Matters

The plan broke into seven phases, sequenced so the build stayed working after every one:

In execution, I actually swapped phases 1 and 2 — Tailwind needed to be in place before stripping the theme, otherwise the site would render with no CSS at all in the gap between phases. Claude noticed and re-sequenced on its own. Each phase ended with a build check; if Hugo failed, we stopped and fixed it before continuing.

This is the part that’s hard to overstate. The phase boundaries are what made this safe. A 4-hour refactor done as one giant edit is a recipe for a site that’s broken in twenty subtle ways and unrecoverable without a git reset. The same refactor done as seven sequenced phases, each verifiable, is a thing you can ship.

The Numbers

The CSS bundle is roughly an order of magnitude smaller. The JS bundle dropped 50×. Build time cut by two-thirds. None of this required cleverness — it required stopping doing the wrong thing, which is the part that’s actually hard.

Why Less Than 20 Minutes Was Possible

I want to be clear about what made the timeline work, because “AI did it” is the wrong takeaway.

1. Persistent context via .impeccable.md. The AI never had to re-discover the brand voice, the audience, the aesthetic direction. That file was loaded into every session.

2. Plan mode as a forcing function. Plan mode meant I got a structured proposal before a single file changed. I could redirect (“use Tailwind, not Bootstrap”), I could approve, and I could trust the execution to follow the plan I’d already vetted.

3. Phase decomposition with build checks. Seven phases, each independently verifiable. The build was tested after each one. When it broke (and it did, twice — once from a missing partial reference, once from a site.Data deprecation), the fix was scoped to a single phase, not the whole project.

4. Auto-mode parallelization. Claude Code ran independent operations in parallel — three exploration agents at once during planning, multiple file reads in single tool calls during execution. Wall-clock time and machine work diverged in my favor.

5. The audit loop as quality gate. I didn’t have to remember what “good” looked like. The /audit command was the rubric. Run, fix, re-run, fix, re-run.

The actual machine time across seven phases was minutes, not hours. The planning work — exploration, design, my approvals, my redirections — added maybe ten minutes of conversation on top. Total elapsed time from “let’s go custom” to a working build with new CSS, new typography, new icons, dark mode, and a passing accessibility audit: well under twenty minutes of focused session time.

What I’d Tell Someone Trying This

A few things that would have helped me, in order of importance:

1. Establish design context first. Before any agentic work on a frontend, run /impeccable teach (or write the equivalent context file by hand). This is the single highest-leverage move. Without it, you’ll get generic results and waste cycles correcting them.

2. Use plan mode for anything bigger than a typo. Plan mode forces the AI to research and design before editing. The plan file is a contract you can read, edit, and approve. It also means the AI’s context window holds the design during execution, not just the immediate diff.

3. Insist on phases. When the AI proposes “I’ll do this in one big change,” push back. Ask for a sequenced plan where each step ends with a build or test that confirms nothing broke. Refactors die in undifferentiated change blobs.

4. Trust the audit, not your eyes. I almost defended the navy palette in my head (“but it’s editorial!”) until the audit computed contrast ratios and showed me, in numbers, that everything was in the same hue family. The tool is more honest than I am about my own work.

5. Auto-mode is for execution, not for thinking. When I was figuring out what to build, I let Claude ask me questions and I made decisions. When I was executing an approved plan, I let auto-mode rip. Don’t conflate the two phases.

The Stack, For Reference

Final stack on this site:

• Hugo for the static site generator
• Tailwind CSS v4 with CSS-first @theme tokens (no JS config)
• @tailwindcss/typography for article body prose (prose class)
• PostCSS via Hugo Pipes (css.PostCSS | minify | fingerprint)
• IBM Plex Sans + Newsreader via Google Fonts CDN with display=swap
• Hand-picked inline SVG icons (10 of them, Lucide-style)
• Zero Hugo modules, zero theme dependencies, zero JS dependencies beyond a tiny mobile-nav toggle

Total stack you can fit in a package.json with five entries.

Closing

The interesting thing about this rebuild isn’t the result — Tailwind sites are not novel. The interesting thing is the workflow. A persistent context file, a planning phase that forces design before code, a structured audit as the quality rubric, and phase-based execution with build checks. Take any of those four out and the timeline blows up. Together, they made it possible to do a real frontend rebuild in the same time it usually takes to draft an email about doing one.

If you’re using AI to write code and your output still feels generic, fix the workflow before you fix the prompts. The model isn’t the bottleneck. The structure around it is.