Standing Orders: Claude Skills Files for Brand Consistency

Every Monday starts the same way. New chat, and before any real work: "We're writing for a B2B fintech audience, keep it direct but warm, never use 'innovative' or 'synergy', emails end with a single question, LinkedIn posts under 1,300 characters…" By the third re-paste of the week you're not writing anymore — you're doing data entry.

That setup ritual is pure waste, and it's also dangerous: the one morning you forget the banned-words list is the morning the draft ships with "transformative" in the first line.

Claude's Skills feature kills this ritual. A Skill is a folder of instructions that loads automatically when relevant — standing orders instead of a morning briefing. You write the brand rules once, and every new conversation starts already knowing them. This post shows how to build the ones that matter for writers and content teams: a brand voice library, a platform calibration file, and the workflow skills that quietly do the behind-the-scenes work.

Standing Orders, Not Morning Briefings

A chat model's memory resets with every conversation. Without a mechanism, all your hard-won context — the client's voice, the banned words, the sign-off style — evaporates each time you open a new window, and you pay the re-explanation tax again.

A Skill is the fix: instructions stored on your side, loaded automatically when the conversation touches their topic. Think job description, not briefing. You wouldn't re-explain the company dress code to an employee every morning; you'd hand them a handbook on day one.

The mechanism looks like this — a folder with a manifest and the instructions themselves:

brand-voices/
  SKILL.md          <- name, description (when it should activate)
  voices/
    acme.md         <- one client, one file
    northwind.md

The SKILL.md manifest matters more than people realize — its description is what tells Claude when the skill applies:

---
name: brand-voices
description: Brand voice rules and vocabulary for client work.
  Use whenever writing or reviewing content for Acme or
  Northwind, or when the user mentions a client by name.
---

The Brand Voice Library

One file per client, one structure every time. Five ingredients:

1. Client context — industry and what they actually sell
2. Audience — who reads this and what they're trying to get done
3. Tone in plain words — "direct but warm," not "authentic yet authoritative"
4. Vocabulary rules — words to prefer, words that are banned outright
5. Sample text — three to five sentences of their real writing you approved

A working entry:

### Acme — voice rules

Overview: B2B fintech ops teams. Direct, warm, allergic to hype.
Audience: operations managers who skim at 4 p.m. and hate fluff.

Tone markers:
- short first sentence; paragraphs 1-4 lines
- concrete numbers over adjectives
- light humor OK, puns never

Vocabulary:
- prefer: actually, specific, quietly, in practice
- banned: innovative, transformative, synergy, leverage, game-changer

Output defaults:
- emails end with exactly one question
- LinkedIn posts under 1,300 characters, hook first line

Why one file per client rather than one big file? Mixing two voices in one context is how you get Acme's jokes in a Northwind memo. Separate files plus a manifest that matches by client name keeps the wrong rules from ever loading.

Beyond Voice: Four Workflow Skills

Voice consistency is the entry point. The bigger wins come from codifying your process:

Brief intake

### Brief checker
Before drafting for any client, verify the brief contains:
goal, audience, format, length, deadline, call to action.
If anything is missing, list ONLY the missing items as
questions — do not start drafting.

Now a rough client email gets converted into "here are the three things I still need" before any writing starts — the question-asking you're too tired to do on Friday afternoon.

Platform calibration

One file explaining what "good" means per surface, so "make this for LinkedIn" carries actual specs: subject lines punchy under 45 characters, hero copy informative, threads structured hook → payload → callback. You stop re-describing platforms and start requesting outputs.

Feedback translation

Client feedback is famously vague — "make it more exciting." A skill can encode your private dictionary:

### Feedback decoder
"more exciting" -> add one concrete example and a sharper
  first line; do NOT add exclamation points
"more professional" -> remove slang and contractions, add
  one data point
"shorter" -> cut adverbs and hedges first, then merge
  paragraphs; never delete the example

Vague notes become specific structural edits instead of a roulette-wheel rewrite.

Quality bar

Your personal final-check list, reusable on every draft: banned words absent, one idea per paragraph, ends with a question or a specific next step, no sentence over 30 words unless deliberate. Every draft gets the same strict read you'd give it on your best morning.

Building Your First Skills Properly

The implementation order matters — vague feelings make vague skills:

1. Gather real material. If you can't describe the client's voice without opening their website, the skill can't either. Pull 3–5 approved samples.
2. Draft in a scratch chat first. Feed the raw material in and have Claude produce the structured entry. Never promote straight to permanent storage.
3. Edit until it sounds like a person wrote it. If the description reads like a robot describing a human, tighten it — vague entries produce vague compliance.
4. Save with clear headings. Client name in the heading, one file per voice, manifest description naming every client it covers.
5. Test with a cold start. New chat, minimal prompt: "50-word intro for Acme." If the tone markers and banned words hold without reminders, the skill works.

The Same Pattern, Locally

Skills are Claude's mechanism, but the pattern — write the rules once, load them always — travels. With Ollama, the equivalent is a Modelfile that bakes your standing orders into a custom model:

FROM llama3.1
SYSTEM """
Voice: direct but warm. Short first sentences. Concrete
numbers over adjectives. Banned: innovative, transformative,
synergy, leverage. Emails end with one question.
"""

ollama create acme-voice -f Modelfile and ollama run acme-voice gives you a permanently pre-briefed local model — no data leaves the machine, which matters when the skill file contains a client's unpublished positioning. Cloud for leverage, local for sensitivity; the library structure is identical either way.

Frequently Asked Questions

What exactly is a Skill in Claude?

A persistent instruction file (folder with a manifest) stored on your side that loads automatically when a conversation matches its description — unlike a chat prompt, which must be re-pasted every session.

Do I need a different Skill per client?

Yes — one file per voice. Mixing clients in a single context is exactly how a playful brand's jokes end up in a formal one's memo. Separate files plus a manifest that matches by client name keeps rules from bleeding across projects.

Will many Skills confuse the model?

Not if each has a clear description and headings. Confusion comes from contradictory instructions loading together, not from volume. Mention the client by name and the right entry wins.

How do I test whether a Skill is working?

Cold start: open a brand-new chat and give a minimal prompt like "50-word intro for Acme." If the saved tone and vocabulary rules hold with no reminders, the skill is active and correct.

Wrap-Up

The setup ritual — re-pasting guidelines every Monday — is unpaid data entry with a failure mode. Replace it with standing orders: a voice file per client with tone markers, vocabulary rules, and samples; workflow skills for brief intake, platforms, feedback decoding, and the final quality bar; and a local Modelfile twin for the sensitive clients. You explain once, then spend every session after that executing instead of configuring.