This website uses cookies

Read our Privacy policy and Terms of use for more information.

In partnership with

TL;DR: How to extend a Claude brand skill so it works on more than the format you built it for. No rebuild needed. You just add a reference file.

What I missed

Last issue, I shared how I built a brand skill in Claude so my decks would stop looking generic. (Here's that post if you missed it.)

It worked, and my decks have been coming out looking pretty slick.

Then I tried it on a one-page guide for an AI cohort I’m running.

Result: not so great.

It looked generic, and it used my colors wrong - kept overusing my secondary orange and underusing my primary yellow.

The problem was that after the back-and-forth getting my presentations all shiny, the skill was optimized for that, and didn’t quite know how to apply those instructions to documents.

Skills can have reference files

A Claude skill can be one simple text file with one set of rules.

Or it can be a folder and contain the main instructions, along with files like logos and reference documents with specialized guidance for particular contexts. All that gets wrapped up in a single SKILL.md file:

When you invoke the skill, Claude reads the main file. When the work matches one of the reference files, it reads that too. The skill stays simple at its core. The complexity loads only when relevant.

My brand skill already had a reference file called nathan-decks.md. It held everything Claude had learned about making my decks look right: templates, headline rules, color discipline for presentations, common mistakes we'd hit along the way.

But it didn't have a reference file for docs.

Here’s how we made one.

I told Claude what I wanted:

How can you take what exists in the nathan-decks part of the skill and create a nathan-docs. The decks we're getting look great - highly professional. The doc you just created is okay but boring.

Cover page is all white, no author biline or subtitle, logo is awkwardly placed. The body is all text - bullets are huge and all black - no color or interest, no tables, no callouts, there are weird rectangles all over. Prompt text is green which isn't a brand color. no table of contents.

The brand skill needs to intelligently understand the content and the length and purpose and build accordingly. Also, using orange for the hyperlinked text in the footer is the wrong call. It draws attention to the footer over the text. If you look in the decks skill you'll also see it should call for use of yellow more.

Claude analyzed the main brand instructions and the deck instructions, and used that to create a mirror of that file, but for creating docs.

Some things it included:

  • Skill organization note. Same pattern as decks. References SKILL.md for brand identity.

  • Brand constants block. Color objects, font definitions, style names.

  • Doc-Type Decision Matrix. A table that maps doc purpose × length × audience to a recommended treatment so Claude can intelligently understand the content. For example:

    • Lead magnet / info product (12+ pages, external) → full cover + ToC + section dividers + callouts + branded prompt blocks

    • Proposal (4-10 pages, client) → cover with hero stat + executive summary box + callouts

    • etc…

  • Doc-Level Pacing Rules. Parallel to the deck pacing rules:

    • Any doc > 6 pages gets a ToC.

    • Any doc > 4 major sections gets section dividers.

    • One callout box per ~2 pages of body, not more.

    • One pull quote per ~5 pages.

    • Footer text and footer hyperlinks use muted slate gray or navy. Never orange. Footer is meta, not focal.

  • D01-D12 Templates. Templates for different pages/sections:

    • D01 COVER (variants: lead magnet, proposal, report, memo)

    • D02 TABLE_OF_CONTENTS

    • D03 SECTION_DIVIDER

    • D04 BODY_PAGE (running header + body)

    • D05 CALLOUT (variants: key insight in Butter, warning in Apricot, pull quote in Pale Navy)

    • D06 PROMPT_BLOCK (navy text on Pale Navy bg, monospace, branded — replaces the green code blocks)

    • etc…

  • Production setup. Standard page setup: page size (US Letter), margins (0.75"), font registration, style definitions to register at the top of any build script.

  • Pre-build checklist. Which property, what doc type, what length, what's on the cover, what gets a callout, where do prompts live, what does the footer do.

All that got packaged into a second reference doc that now lives in the skill:

Then came the testing.

I built a doc with the updated skill, told Claude what was off, fixed the skill, tried again.

At least four or five times.

It’s still not quite as sharp as I’d like, but good enough to get outputs like this consistently:

What to do this week

If you've built an AI skill of any kind (brand, voice, framework, workflow) and you've only ever used it for one type of output, expect a gap when you try a new one.

You don't have to anticipate every format upfront.

You build one thing, see what looks off, and then codify the corrections into a reference file in the skill.

The skill gets smarter. The next deliverable in that format comes out closer to what you wanted.

If I eventually need this brand applied to a website, a specific kind of report, or a banner ad, I might need to add another reference file.

Or the existing patterns might cover it.

The only way to find out is to build the first one and see how it behaves.

FAQ

What is a Claude skill? A set of instructions you install once in Claude that fires automatically whenever you need it. Instead of pasting the same guidelines into every conversation, the skill runs in the background. Install it once, and every output it covers follows your rules without you having to ask.

What is a reference file inside a skill? A supplementary file in the same folder as your main skill. The main file holds rules that always apply. Reference files hold rules that only matter in specific situations. Claude reads the main file every time, then pulls in the reference file when the work calls for it. That's why my deck rules don't interfere when I'm building a doc, and vice versa.

How do I know when to add a reference file vs. just updating the main skill? If the gap is specific to one format, add a reference file. If it's a core identity issue that should apply everywhere, update the main skill. The practical test: would this fix break something that's already working in another format? If yes, it belongs in a reference file, not the main one.

Dig Deeper

If you know someone who's been tweaking their AI setup for months and still getting inconsistent output, forward this. They might just be one skill with a good reference file away from fixing it.

Thanks for reading!

Nathan Rodgers

👋 Say hello on Substack and LinkedIn

Were you forwarded this email? Click here to subscribe.

Keep Reading