Building a consistent frontend with Claude Code

The times we live in require such a note: articles are human-written, even those touching on the topic of AI.

And its not BEST PROMPTS THAT HELPED ME BE PRODUCTIVE 013923x slop; just knowledge sharing.

Pre/Problem

While building the frontend with Claude Code, I frequently faced a problem that it tried to recreate components inline in the application, attempting to make them design consistent. Attempting.

With 3+ developers under strict deadlines, this turns into monstrous pile of inline duplicates of the same component. And it comes to look like Frankenstein's monster couple weeks after. Every time asking it, like hey, check form components under /somepath/common/ui and use them instead is annoying at the least. Sometimes you miss it, sometimes you just don't notice.

"Tried"

My first action was to specify such instructions in CLAUDE.md . I provided here short as possible instruction like


Before adding any UI element, check this document for existing components and conventions.

Tabs

For content tabs with hash-synced navigation use components/somepath/AdminTabs.tsx:

- <AdminTabs> — renders the tab bar
- useHashTabs() — hook for hash-synced active tab state

...

## Form Components

Form components live in `components/somepath/form/`.

### Toggle

On/off switch for boolean settings. Use `components/somepath/form/Toggle.tsx`:
  - Props: `checked`, `onChange`, `label?`, `disabled?`

...

Show all 22 lines (12 more)Show less

With knowledge of components should be used in here. And Claude Code assistance collecting them properly by only listing ones and describing rules of listing these components into CLAUDE.md (like "as short as possible") we got an approx 200 rows file with instructions.

And it just worked.

-- I know, I know "where is the path, story how to go through fire and water" --

but its not just this kind of story. It worked, and gradual refining/supporting this file comes a simple solution in the long run. And solves a huge future headache and significantly reducing tech debt growth.

Refining

Storing these instructions in CLAUDE.md is OK overall. Biggest part with such instructions consumed ~1000 tokens, which is acceptable tradeoff and "minimal setup". But the problem with it is different.

I'm trying to use as less skills and keep less information in CLAUDE.md on session startup to avoid annoying Data Bias. (Sometimes asking question about form you might be hit with startup information from CLAUDE.md , because the context window already has information about components. While in new session buddy would search for actual answer. )

And the answer is simple. Keep in CLAUDE.md only reference to this rules.

Before making any frontend changes ack:
.claude/instructions/fe-framework.md

So Claude will read this file only if its in task scope.

-- At this point you might think "Wait, thats just a Claude skill". And you will be absolutely right, but the thing I added it on 2 repos, before skills have been introduced. --

It can be described as "Complete instructions set can be added to session context conditionally", - so its definitely a skill

Final version was just a Claude Skill fe-framework stored in repos, supported and heavily used by developers

"Tested"

I tested this practice on at least 4 different projects. From small to huge size repos. NextJS and Vue. Everywhere it works just fine.

That's the story. No complexity, just a simple thing that became common practice across the company, saved us a lot of nerves and time in the long run (we'll never really know how much).

And another use case for skills =)