The Question No Brand Manual Answers
Three months ago, a junior designer on a team I know took 4 days to create a social media post.
Not because they couldn't design.
But because they spent 3 days searching for:
- The correct tone of voice across 47 pages of brand guidelines
- The exact colors between 3 different PDFs
- Whether they could use emojis (spoiler: there was a specific rule buried on page 23)
- What legal claims they needed to include
The knowledge existed. But it was dead.
Lived in documents nobody opens until something goes wrong.
Skills: When Knowledge Executes, Not Reads
Claude Skills aren't another documentation tool.
They're a way to package institutional knowledge as executable code.
The difference is brutal:
Traditional documentation:
- You write: "Our tone is professional but approachable"
- The junior interprets their version of "approachable"
- You review, correct, explain
- You repeat this with each new person
With Skills:
- You code: The exact prompt that generates the correct tone
- Anyone on the team executes it
- The output is consistent from day one
- The knowledge is alive, not archived
What You Can Capture in a Skill
What's interesting about Skills is they work for knowledge you thought was "too specific" to automate:
1. Brand Voice
```yaml name: "Brand Voice - Financial Analysis" context: | You write for CFOs and Controllers in Spain. Formality level: Professional but direct. NEVER use: "innovative", "disruptive", "synergy". ALWAYS: Data first, interpretation after. Cultural references: OK to mention Spanish regulations.
instructions: | 1. Open with the most relevant insight (no context) 2. Use bullets for data, paragraphs for analysis 3. ALWAYS include the data source 4. End with a question that invites reflection ```
This isn't a "guideline". It's a machine for generating consistent content.
2. Compliance and Legal
A Skill can package all your legal requirements:
```yaml name: "Legal Review - Marketing Copy" checklist: | - Does it include disclaimer about past performance? - Does it mention risks if discussing investment? - Does it comply with GDPR if mentioning data? - Does it use terms requiring financial license?
autocorrect: | If you detect absolute claims ("guaranteed", "safe", "always"), reformulate in probabilistic terms or eliminate. ```
The junior can no longer forget the disclaimer. The Skill enforces it.
3. QA Workflows
Look at this Skill for reviewing PRs:
```yaml name: "Code Review - Next.js Apps" context: | You review PRs in Next.js 14+ projects with App Router. We use Supabase for auth, Vercel for deploy.
checklist: | ## Performance - Uses dynamic imports for heavy components? - Images use next/image with sizes? - Fetches use appropriate cache tags?
## Security - Validates user inputs? - Uses RLS in Supabase? - Exposes credentials in code?
## Standards - Follows project naming conventions? - Tests for business logic? ```
This Skill captures what a tech lead would repeat 50 times a year.
The Pattern That Makes Skills Useful
After creating several Skills, I've noticed a pattern:
Good Skills aren't generic.
You don't write "be professional". You write:
``` NEVER use second-person pronouns. Address the reader as "the CFO" or "the finance team". If you mention a metric, include period and source: ✓ "In Q1 2024, according to Bank of Spain data..." ✗ "The data shows that..." ```
Specificity is what makes it work.
How to Start Capturing Knowledge
1. Identify what you explain repeatedly
What questions do you answer again and again?
- "How do we write SEO titles?"
- "What structure do we use for onboarding emails?"
- "How do we review code before merging?"
Those are your first Skills.
2. Convert explanations into instructions
Don't write *about* the process. Write *the process* as you'd execute it:
Bad: "Our emails are clear and actionable."
Good: ``` 1. Subject line: 40 chars max, include specific benefit 2. Paragraph 1: A single problem, in one sentence 3. Paragraph 2: How your product solves it 4. CTA: Single button, actionable text (not "Read more") ```
3. Test with new people
The best validation of a Skill:
Give it to someone who's never done that task.
Can they execute it without asking you questions?
If yes → the Skill works. If no → it lacks specificity.
The Mental Shift
Skills change how you think about company knowledge:
Before: "We need better onboarding to explain our processes."
Now: "What processes can we code so they don't require explanation?"
It's not about replacing humans.
It's about freeing your team's brainpower for problems that actually require original thinking.
What I'm Building With This
I'm converting my project processes into Skills:
- How I write technical posts (structure, voice, links)
- How I validate ideas before building (CENTS checklist)
- How I optimize for local SEO (patterns that work)
Each Skill is knowledge that used to live only in my head.
Now anyone (or any AI) can execute it.
The Takeaway
Skills aren't documentation 2.0.
They're institutional knowledge as code.
And like all code: you can version it, test it, improve it, and share it.
The question isn't "do we need more documentation?"
It's: "What knowledge can we execute instead of explaining?"
Start with one. The process you explain most often per month.
Convert it into a Skill.
And watch how much time you get back.
