Claude Code and I built this site. Adding sections, refactoring components, fixing bugs. It is fast, and I enjoy working with it. But after a few days, every session started the same way: I would explain the design system from scratch, Claude would still get something slightly wrong, and I would have to write a clearer prompt. I even wrote my prompt in a text file so I could copy and paste it into the terminal.
Claude Skills changed that. Once I wrote down my rules, I stopped having that problem. The corrections became rare. The back-and-forth shortened. I started finishing things in one session instead of three. That sounds small, but it made a real difference in staying focused and in maintaining the motivation to keep building.
What a skill actually is
Claude Code has a feature called skills, which are essentially persistent instructions you can invoke with a slash command. A skill is a markdown file that lives in the project. Once it is there, calling it by name makes it part of the conversation context for that session.
Skills can be written with Claude. I describe the rules, Claude drafts the file, I review and adjust. It takes a few minutes. During development, I update it regularly as new patterns emerge.
There are also a lot of skills available online, so writing one from scratch is not always necessary. Vercel ships official skills for React best practices, for example. It is a good starting point if the project uses React and you do not want to write the rules yourself.
The skills I wrote for this site
For this site, I wrote one called /frontend-guide. It describes the exact rules for this site: the section anatomy, the typography scale, which colours are allowed, how spacing works, what never to do. For example: always use h-dvh instead of h-screen, never use rounded badges, never add gradients, never use hardcoded colours except #879bd6.
There is no Figma file for this site. Every design is done in code, so this skill matters: I don't need to come up with a design, and Claude can create something I will like (at least 80% of it).
The section anatomy rules show how specific it gets. Every section must open with a border divider (bg-border h-px w-full), an optional mono label, then the heading. Without the skill, Claude would invent its own structure every time and spend tokens searching the codebase for examples. With it, the pattern is just there.
I also wrote one called /add-magnet that handles adding a new entry to the magnets page, including copying the image to the right folder and updating the constants file. That one is more of a workflow shortcut than a design guide. I just call the skill and paste a magnet image.
I still haven't completely optimized my workflow for adding magnets, though. Every magnet image needs to be edited first (more saturation, fixed contrast, removed background), so I still do that part manually. What the skill saves is everything after the image is ready: copying it to the right folder, connecting it to the code, and writing the entry details. I paste the image and it handles the rest.
The third one is /review-blog-post. It is a different kind of skill entirely. Rather than telling Claude how to build something, it tells Claude how to read something I already wrote and give structured feedback. It checks grammar, flags anything that breaks my writing voice, suggests what is missing, and audits the JSX structure of the post component.
I used it on this post before publishing it. It flagged a paragraph where the content did not match the section title, and pointed out a few sentences that did not quite make sense on their own. Those are the things I stop seeing after reading the same text too many times.
What changed
Claude didn't suddenly become a better designer, but it stopped guessing. Before the skill, it would make reasonable choices that did not match my system. After, it had the system. The output landed closer on the first try.
A concrete example: before /frontend-guide existed, I asked Claude to add a new section and it came back with [font-family:var(--font-instrument-serif)] inline on every heading. Technically correct, but I had already extracted that into a .heading CSS class. After the skill, it knew that class existed and used it. Small thing. Adds up fast.
I also noticed I was spending less mental energy on low-stakes decisions. Things like whether to use space-y-4 or space-y-6 between blocks, or which divider pattern to use between rows. Those are already decided. They live in the skill file. I do not have to think about them again.
The same goes for grammar. I don't have to worry about it as much. The /review-blog-post skill catches issues before I publish, so I can focus on getting the content down first.
What did not change
The actual decisions. What goes on the page, what the content says, whether something should exist at all. The skill handles the how, not the what. I still make every call that matters.
The trap is accepting everything Claude outputs without checking. The desire to just accept and publish more is always there. I still read everything. That part does not change.
Testing is still fully manual. I check every page on every screen size. A skill cannot tell me whether something feels right. I do not think that will ever change.
Do I recommend it
Yes. Every time. Writing the skill takes less time than fixing the same mistakes every session. Manual tasks that used to mean several steps are now one command.
I believe skills will become standard for anyone building with Claude. Not as an optional extra, but as the starting point.