Claude Frontend Design Skill for Reports and Proposals: What It Changes and How to Steer It

The Claude frontend design skill is a set of instructions from Anthropic that moves Claude off its default look (the safe sans-serif, the centered cards, the purple gradient) toward a visual direction that looks chosen. It is tuned for interfaces. A report or proposal is a different object: opened once on a laptop, compared line by line, sometimes printed. Paired with the constraints below, the skill keeps its taste and loses the parts that fail on paper.

What the Claude frontend design skill changes

Claude skills are folders of instructions (a SKILL.md file plus any supporting files) that Claude loads when a task matches the skill's description. Anthropic publishes frontend-design in its public skills repository on GitHub. In paraphrase, it tells Claude to commit to a clear aesthetic direction before writing code, pick characterful typefaces over the most common defaults, build the palette around a dominant color with sharp accents, and add motion, unexpected layouts and textured backgrounds.

For a landing page, all of that helps. In a report, the typography, hierarchy and committed palette still help, but each interface habit has a cost in a document:

• Scroll-triggered motion. A section the reader never scrolled to stays at its starting state, so it prints blank, or as zeros.
• Dark, textured grounds. Browsers skip background colors when printing unless the reader changes a setting, so light-on-dark text prints pale on white.
• Card grids. Numbers a reader wants to compare end up scattered across rows instead of lined up in a column.
• Several display fonts. Each one is another request, and if one fails the fallback looks nothing like the design.

So keep the skill for direction and add explicit rules for the medium. Where its general guidance conflicts with your specific rules, Claude generally follows the specific instruction. Check the output anyway.

How to turn on the frontend design skill

Skills run where Claude can execute code, so turn code execution on first.

• Claude apps (web and desktop). On plans that offer skills, open Settings and find Skills near the code execution toggle. Switch on Anthropic's frontend-design skill if it is listed. If it isn't, download its folder from the repository, zip it, and upload it as a custom skill.
• Claude Code. Copy the folder into ~/.claude/skills/ to use it in every project, or into .claude/skills/ inside a repository to use it in that project only. The repository's README also covers installing it as a plugin.
• Claude API. Custom skills are uploaded and attached to requests that use code execution. Anthropic's developer documentation has the steps.

Menu labels shift between app versions, so go by where the setting sits, not its exact wording. Claude loads the skill on its own when you ask for a web page, dashboard or HTML report. If you want to be sure, name it in the prompt ("use the frontend-design skill"). With the HTMLvault Claude connector added, the same conversation can publish the page as a tracked link and edit it after you send it.

Eight rules that keep a report printable and patchable

The skill sets the direction and these rules set the limits. Each one is an instruction you can check, followed by its reason. The prompt at the end repeats them in a form you can paste.

1. Deliver one self-contained HTML file. Put all CSS in a <style> element and scripts inline or from one CDN, with no local file paths. HTMLvault serves the document with its own CSS and scripts and adds no stylesheet or fonts, so anything the file doesn't carry is missing.
2. Use a system font stack, or one web font with a system fallback. That means one font request at most, and the page still reads if the font fails to load. The skill leans away from common typefaces, so the usual result is a distinctive heading font over a system stack for body text.
3. Use at most two accent colors. One for emphasis and an optional second to flag a problem, with neutrals everywhere else, so every color means something.
4. Set body text at 16px or larger. People read the page on a laptop at arm's length, and sometimes on paper.
5. Put figures someone will compare in a table, not cards. Use one row per item, a <thead>, and numbers right-aligned with font-variant-numeric: tabular-nums. A column lines numbers up, and a grid scatters them.
6. Include an @media print stylesheet. It should set a white background and dark text, hide navigation and buttons, and keep table rows and figures from splitting across pages. Browsers drop background colors when printing by default.
7. Do not animate data. No count-ups or fade-ins on tables, charts or figures. Draw charts as static inline SVG, or turn off a chart library's animation. An animated value prints at whatever state it reached.
8. Give every section, table, figure and key value a stable, unique id, and write each number once. Edits after sending are find-and-replace patches, and by default a patch's find string must occur exactly once.

Three more rules follow from how HTMLvault stores a page:

• Close every <p>, <li>, <td> and <tr> explicitly. Malformed HTML is refused, not repaired, and leaving out end tags can push nesting past the parser's limit of 1,000 levels.
• Reference images by https URL or draw them as inline SVG. An <img src="data:..."> is removed at publish.
• Never use an HTML comment as a marker. Publishing drops comments, so a patch can't find one.

Rules 5, 6 and 8 in markup:

<style>
  @media print {
    body { background: #fff; color: #111; }
    nav, button { display: none; }
    tr, figure { break-inside: avoid; }
  }
</style>

<section id="revenue-by-region">
  <h2>Revenue by region</h2>
  <table id="revenue-table">
    <thead>
      <tr><th>Region</th><th>Q2</th><th>Q3</th></tr>
    </thead>
    <tbody>
      <tr id="row-emea"><td>EMEA</td><td id="q2-emea">$412,000</td><td id="q3-emea">$448,000</td></tr>
    </tbody>
  </table>
</section>

Worked example: one quarterly summary, built twice

Both builds start from the same input: revenue by region for Q2 and Q3, pipeline by stage, two risks, and priorities for next quarter.

With the skill alone

Claude commits to a dark editorial direction. It uses a near-black ground with a gradient glow, a display serif for headings, a second display face for numbers and a third font for body copy. The four headline figures sit in oversized cards that count up as they scroll into view. Regional revenue becomes a staggered card grid with Q2 and Q3 on separate cards, and every section fades in. The Q3 total appears in three places: the hero, a card and the summary sentence.

On a laptop it looks like a product launch. To compare EMEA's two quarters, the reader has to jump between rows. On paper, the background drops out and the sections nobody scrolled to come out blank. Correcting the total takes three edits that all have to match.

With the skill plus the eight rules

The skill still makes the design decisions. It picks one distinctive serif for headings over a system body stack, a deep green accent, a muted red kept for the one region that missed plan, a confident type scale and generous margins. Regional revenue is one table (region, Q2, Q3, change) in tabular numerals, and the pipeline chart is static inline SVG. Each section has an id (summary, revenue-by-region, pipeline, risks, next-quarter). The Q3 total appears once, in its own cell, and the print stylesheet keeps rows whole on a white page. It still looks designed, because the typography was doing most of the design work all along.

Through the HTMLvault MCP server, Claude publishes the file with create_link. The account's PII and secret checks run on the way, and a refused publish returns the findings instead of a URL. When a figure changes after sending, the agent first reads the stored HTML with get_link, because publishing normalizes markup: attribute values are double-quoted and comments are dropped. It then calls patch_link to replace the exact stored cell, such as <td id="q3-services">$186,000</td>, with the new value. One call takes up to 200 patches, all or nothing, and the URL stays the same. Editing a published page covers the details.

Prompt you can reuse

With the skill on, paste this under your content request. Or save it in a Claude Project's instructions so every report in that project follows it.

This is a report or proposal that will be read once on a laptop and may be printed. Keep your design direction and follow these rules exactly:
1. Output one self-contained HTML file: all CSS in one <style> element, scripts inline or from one CDN, no local file paths.
2. Fonts: a system font stack, or exactly one web font with a system fallback.
3. Color: neutrals plus at most two accent colors. Use the second only to flag a problem.
4. Body text 16px or larger, line-height about 1.5.
5. Put figures a reader will compare in a <table> with a <thead>, one row per item, numbers right-aligned in tabular numerals. No card grids for comparable numbers.
6. Include an @media print stylesheet: white background, dark text, navigation and buttons hidden, no page breaks inside table rows or figures.
7. No animation on data: no count-ups, scroll reveals or fade-ins on tables, charts or figures. Draw charts as static inline SVG.
8. Give every section, table, figure and key value a unique, stable id (lowercase words joined by hyphens). Write each number in exactly one place.
9. Close every <p>, <li>, <td> and <tr> explicitly.
10. No data: URLs in <img src>. Use https image URLs or inline SVG. Never use HTML comments as markers.

Keep that block next to the skill, and your next proposal will look designed on the laptop where it's opened. It will also come off the printer for the meeting you're not in with every figure where you put it.