A European company asked us at CAPSLOCK, an applied AI lab, to help with a problem that looked small. About two dozen of its people make screens, decks and papers in Claude every week: engineers, analysts, stakeholders. None of them are designers, and none of them need to be. Their job is the content. We built them a skill that carries the company's look into everything Claude makes, and the shortest way we've found to say what changed is this: "it was like having a personal designer for every single person in the company."

A skill is a folder of instructions and files Claude reads before it builds. What people build with it are artifacts: pages Claude makes that can be shared as a link. Our own observation, with no number behind it: the company's internal documents had never looked this good.

Before the skill, the content came out right. The case, the inputs, the journey, the figures. The look came out wrong: a generic theme, the wrong fonts, no product frame, and decisions the team already agreed (tiles, not rows; actions at the bottom) that Claude had no way of knowing.

the second job nobody does

Making an artifact look like the company is a second job. Restyle it, swap the fonts, rebuild the product frame by eye, ask design if it's ok.

It was nobody's priority, and fairly so. So most people left it as it came out, and generic pages went in front of sponsors and boards as they were. The few who did care spent the time, or sent it to design with "is this on brand?". The agreed decisions got argued again in meetings, because the page in front of everyone didn't show them.

You can't fix this by asking people to care more about something that isn't their job. You fix it by making the right look the default.

two lanes. before: most artifacts go straight from make to the meeting, off brand, as a generic page as it came out; a thin side path, for the few who cared, goes make, restyle the fonts and product frame by eye, ask design “is this on brand?”, then the meeting. after: every artifact goes straight from make to the meeting, on brand, because the skill brings the look and the page looks like the product
fig. the second job: most people skipped it, so the right look has to be the default

the skill owns the look, you own the content

Claude doesn't design badly. It designs from memory, from scratch, every time. So we gave it something to fill in instead of something to draw.

The skill works like a mould: the mould gives the shape, the person asking brings the dough. Inside this one are the company's design tokens (its colours, type sizes and spacing, each saved as a named value), the real frame of each product, templates for decks, papers, memos, one-pagers and discovery packs, and an invented cast of people and figures. A small checker flags any colour or size that isn't in the design system.

Design writes the look rules once. Nobody else edits them. And there are four things Claude never decides on its own:

  • The look. It comes from the design system, copied, never redrawn.
  • Real people's data. An artifact is a page that can be shared. Real customer details are swapped for the invented cast and never placed in the page, even when someone asks. For real colleague names, Claude asks once.
  • Commitments nobody made. Targets, dates and savings nobody supplied show as "to confirm", never as a plausible number.
  • Decisions the team already agreed. When someone's content clashes with an agreed pattern, Claude builds the pattern and leaves one line in the notes: "built as tiles, per the workspace decision."
a card split in two. the skill decides the look: design tokens for colours, type and spacing, the real frame of each product, and templates for decks, papers, memos, one-pagers and discovery packs; design writes the look rules once and nobody else edits them. the person asking decides the content: process, fields, wording, figures. underneath, four things claude never decides on its own: the look, copied from the design system and never redrawn; real people’s data, swapped for the invented cast and never placed in the page; commitments nobody made, shown as “to confirm”; and decisions the team already agreed, built as the agreed pattern. when content clashes with an agreed pattern, one line in the notes: “built as tiles, per the workspace decision.”
fig. the skill owns the look, the person asking owns the content, and four things are never claude’s call

what changed for the people making things

Brand without effort. The people who never cared still don't have to. The page comes out looking like the product because the colours, sizes and frames come from the design system, not from memory. The few who did care get their time back, and stop asking design for a brand check. Design stops being the brand police.

Time. One analyst used it to prepare a sponsor review and made 25 versions in a day. The prototype took part of a week instead of the whole week. When feedback comes in, the changes go back on the same link.

Alignment. The stakeholder can open the link before the meeting, so the meeting is about the content. The look is already settled, and the agreed decisions arrive built in, with a note saying so.

People change it themselves. The same analyst opened the artifact's chat and asked for a change on their own. Their words: "that's super helpful."

Our bet, not yet measured. A junior designer with this works at a senior's level on the look, and spends their time on the content. We haven't tested that with juniors; it's an opinion, and we'd like to be proven right or wrong.

And what it doesn't replace. A link doesn't carry the reasoning behind a design, so the meeting still matters. And anything Claude works out for itself (which day counts as "today" on a plan, say) has to be stated on the page, so nobody finds out later.

how we know it holds

We tested it two ways.

With people. The pilot group used it on their real work, and we sat with them while they did: what they reached for, where it got in the way, what they changed themselves. The analyst's review above is one of those sessions.

With a test set. We wrote 17 requests of the kind people there actually make: a board one-pager, a team dashboard, a screen for a data request, a town hall deck, each in the voice of someone who'd ask it, from an analyst to a compliance lead to someone in their first week. Claude built every one with the skill, and one of them again without it. A second Claude checked each result against a short list: does it look like the product, are there real people's details in it, did it make up any numbers. (How we run tests like this.)

One synthetic test, run both ways. There are no real before-and-after screens from the team, and we can't show their pages. So to see what the skill changes, we set up a test: one request with an invented customer in it, built once with the skill and once without.

That request pasted in the customer's details, written as if real. Without the skill, it came back in system fonts, with 79 problems flagged by the checker and the customer's name, account number, address and balance in the page, twice each. With the skill, across all 17 requests, the look matched the product and no personal details made it into any page, including when the request came from a compliance lead insisting "it's for legal". On the short list, the single request run without the skill scored 2.0 out of 5; the 17 requests run with it averaged 4.4. Those two numbers aren't a like-for-like pair, so read them as a direction.

How far to trust "a second Claude checked": it scored each page only against the short list above, and no person checked its scores against their own, so there was no human calibration. We also built the skill. We read those numbers as a strong signal, not a measurement. The people in the pilot are the other half of the evidence.

comparison of the same ask with the skill off and on. look: system fonts and a generic theme, against the product’s frame and design tokens. personal details in the page: the pasted customer’s name, account number, address and balance, twice each, against none across 17 artifacts. checker: 79 problems flagged on the skill-off page, against colours and sizes taken from the design system. judged score: 2.0 out of 5 against 4.4 out of 5. note: the customer was invented and pasted as if real; the judges are models with no human calibration, and we built the skill
fig. with the skill, the look matched the product and no personal details reached any page

what still fails

Some of it, honestly:

  • The page stayed clean, the chat didn't. Asked to put real names on a screen, the model refused, then explained in the chat how to add them back by hand. That's now a rule: don't help put them in.
  • A code request got a prototype. A developer asked for a component to drop into the codebase and got an artifact, when the right answer was a pointer to the real component library.
  • Gaps got filled. Where a process had a hole, the model sometimes filled it with plausible detail instead of marking it. The rule was written; it wasn't followed every time.

Each of these is on the list for the next version. The list is the work.

from two dozen to many

The skill is packaged as an enterprise plugin (the way one skill gets installed for many people at once), installed for groups, so nobody sets it up by hand. It's built to run inside the company's own environment and to comply with eu data rules. A named owner on the design side refreshes it when the design system or a product changes, and every artifact shows which version made it, so an old one is easy to spot. The weak point is a refresh that someone forgets.

flow: two dozen people, engineers, analysts and stakeholders, get the skill through an enterprise plugin installed for groups, so nobody sets it up by hand, and from there it reaches many. underneath, a loop: when the design system or a product changes, a named owner on the design side refreshes the plugin, and the new version is shown on every artifact, so an old one is easy to spot. the weak point, marked on the owner: a forgotten refresh
fig. from two dozen to many: a plugin carries it, a named owner keeps it current

six questions to start

  1. Who in your company really makes artifacts with AI, and what do they make?
  2. Which of your sources of truth (tokens, components, product screens, templates) could Claude copy exactly?
  3. What should never change from one artifact to the next?
  4. What must Claude never decide on its own, starting with real data?
  5. How will you compare the same ask with and without the skill?
  6. Where will you write down what it still gets wrong?