Power Design: a Claude Code skill that applies 20 slide rules and 20 web rules

The problem Power Design targets: AI output that looks like AI output

Most generators produce the same visual defaults: purple gradients, a hero with six bullets, drop-shadowed bars. Power Design is a Claude Code skill that tries to remove those defaults by making two things explicit before any HTML is written. The first is brand DNA, which the README says is extracted live from a URL via Firecrawl or picked from a library of 72 or more pre-built brand systems, with Stripe, Apple, Linear, Spotify, Vercel, Notion, Tesla and Airbnb named as examples. The second is a rulebook with numeric thresholds rather than adjectives.

The audience is narrow and specific. This is for someone already working inside Claude Code who wants a deck or a landing page generated as HTML, and who would rather argue with a numbered rule than with a model's taste. If you do not use Claude Code, the skill has no delivery mechanism. The README gives no CLI, no npm package, no server, and no standalone binary, so the skill is not usable from a plain terminal or from another assistant.

Two rulebooks, one brand engine: how the skill routes work

The architecture is a fork. The skill asks "deck or website?" first, then sends the request down one of two paths that share the same brand extraction step. Slides get 20 rules drawn from Tufte, Reynolds, Duarte, Williams, Refactoring UI, Müller-Brockmann, Mayer and WCAG 2.2. Websites get a separate 20 drawn from Marcotte, Krug, Bringhurst, Utopia, Baymard, NN/g, Core Web Vitals and WCAG 2.2.

The split is justified in the README with a real distinction: a slide is a fixed frame, a page is a fluid, interactive, indexable system. That is why the web list carries rules the slide list has no equivalent for, such as breakpoints that follow content rather than devices, fluid type and space via clamp(), tap targets of at least 44 by 44 pixels, a reserved-space rule to protect CLS below 0.1, and a performance budget covering LCP, INP and CLS. The slide list instead spends its budget on frame-specific constraints: a 5% edge safe-zone on all sides, a 60-30-10 color split, and a data-ink ratio of at least 80%.

Several rules are numeric enough to check mechanically. Body text at least 24px and titles at least 48px on slides; line-height 1.4 to 1.6 for body and 1.05 to 1.2 for display; line length of 60 characters or fewer on slides and 45 to 75 on the web; contrast at least 4.5:1 for body with 7:1 as the aim. Others are judgement calls dressed as numbers, and rule 20 on slides admits it: two valid modes, Tufte versus Reynolds, pick one and stay. That is a taste decision with a citation attached, not a measurable threshold, and the README does not say how the skill enforces it.

Installing the skill and generating a first deck

There is no package manager step. The README gives a single git clone that places the repository where Claude Code looks for skills.

# from the README
git clone https://github.com/ItsssssJack/power-design ~/.claude/skills/power-design

After the clone, the skill is invoked from inside Claude Code by naming it in the prompt. The README shows two examples, one for a deck and one for a landing page.

# run inside Claude Code, not a shell
> use power-design — make me a deck for stripe.com about our new product launch
> use power-design — build me a landing page in linear.com's style for my new app

According to the README, the skill then walks a five-step flow: it asks deck or website, asks which brand (paste a URL, pick from the library, or skip for a default), extracts brand DNA through Firecrawl in roughly 30 seconds, asks a short brief (for a deck: headline plus 3 to 5 points; for a site: type, goal, sections), and writes either slides.html or a responsive site.html. The file is then opened in the browser, and refinement happens through conversation rather than through editing flags.

The repository layout supports the README's claims about scope. Alongside SKILL.md there are brands/, principles/, lib/ and email-assets/ directories. The presence of email-assets/ is worth noting because the README's two paths do not mention email output, so the skill may do more than the documentation describes, or that directory may be a staging area.

The Firecrawl dependency and other limits worth knowing

Brand extraction runs through Firecrawl. The README states this as a fact and does not document what happens when the fetch fails, when the target site blocks automated access, or when the brand is not in the 72-system library and the URL cannot be read. There is no documented fallback path in the README, and no environment variable or API key is mentioned there. That is the first thing to test rather than assume.

Versioning is the second gap. The repository has no releases, so installation is a clone of whatever main contains at that moment. The README does not document an upgrade procedure, an uninstall procedure, or a way to pin a known-good state beyond checking out a commit yourself. If you clone today and the rules change next week, nothing in the documented flow tells you what changed or how to roll back.

The licence is the third. The repository metadata reports NOASSERTION for the licence, which means the licence could not be identified automatically. A LICENSE file exists at the top level, so the terms are written down somewhere in the repository, but the README does not state them. Read that file before you ship generated output commercially; nothing here is legal advice, and the practical question of whether generated decks inherit any obligation from the skill is one the README does not address.

Finally, the output is HTML. If your team lives in PowerPoint or Google Slides, slides.html is a different artifact from a .pptx, and the README does not describe an export path.

How this differs from generic AI page builders

The obvious alternative is a prompt-driven builder such as v0 or a general chat assistant asked to write a landing page. The difference in approach is where the constraints live. A generic builder puts them in the prompt, so quality depends on how well you describe the target. Power Design puts them in a numbered list that ships with the skill, so the same 20 checks apply to every slide regardless of how the request was phrased.

That has a cost. A fixed rulebook cannot know that your brand breaks the 60-30-10 split on purpose, or that a 60-character measure is wrong for a technical diagram. The README presents the rules as research-backed, which they are, but a rule that is right on average can still be wrong for one deck. The skill's answer to this appears to be conversational refinement after generation, which is weaker than a config file that lets you disable rule 12 for one project.

A second alternative is a design-token and component stack, which the README itself points to: the sister repository power-design-web, described as covering design tokens, shadcn/ui, Tailwind v4, Radix, OKLCH, motion and theming. That is a build system, not a generator. If you want a maintained component library you own, that path is more work up front and less dependent on a model's output. Power Design is the faster route to a first draft; power-design-web is the route to something you keep.

Maintenance status, upgrade cost and what to verify first

The last push to the repository was on 2026-08-10, which is recent, and the repository is not archived. There are no releases, so there is no changelog to read and no semantic version to depend on. The practical upgrade cost is re-reading SKILL.md and the principles files after a pull, because those are the files that carry the rules. The README does not describe a migration process, so a rule change between two commits is something you discover by diffing the clone.

On licensing, the metadata reports NOASSERTION and a LICENSE file is present. The README does not restate the terms, so the file itself is the only source. That matters more here than for a library you import, because the output is a deck or a website you may distribute.

The README also links to a live principles site and a community link, but those are external references rather than parts of the install. The thing to verify first is local: that the cloned directory sits where Claude Code reads skills from, and that SKILL.md is the file the tool loads. If the skill does not appear after the clone, the README offers no troubleshooting section to fall back on.

Editorial conclusion

Adopt Power Design if you already run Claude Code and want generated decks or landing pages that follow explicit, numbered rules instead of vibes, and if you are willing to let Firecrawl read the brand URL. Do not adopt it if you need a versioned package with releases, or if you cannot accept that the entire install is a git clone into ~/.claude/skills with no upgrade path documented in the README. Before you rely on it, verify three things: that SKILL.md in the cloned directory is what Claude Code actually loads, that your brand URL can be fetched by Firecrawl, and that the emitted slides.html or site.html is something you can edit by hand when a rule fires in a way you disagree with.

Frequently asked questions

Official sources

1. Issues
2. ItsssssJack/power-design on GitHub
3. README