How to Actually Build a Skill (Step by Step)

The process of creating a Skill is pretty straightforward, but doing it well takes some thought. Here's how I approach it:

Step 1:

Pick One Repetitive Task That Eats Your Time

Don't try to codify your entire expertise at once. Start with something specific that consumes hours of your time without requiring your creative judgment.

Good candidates:

• Documentation work that follows a consistent format

• Information gathering from scattered sources

• Objective compliance checks against established standards

• Reformatting or adapting content for different contexts

Bad candidates (at least for your first one):

• Processes that change constantly based on context

• Purely subjective creative judgment with no consistent criteria

• Things that require extensive proprietary information you can't share

• Work that requires reading room dynamics or managing stakeholder politics

I started with brand compliance checking because I was spending 60 to 90 minutes per vendor review on work that didn't require my expertise. Just adherence to documented standards.

Step 2:

Document Your Actual Process (Not the Idealized Version)

Write down how you actually do this thing. Including the specific checks you run and the criteria you apply.

Be specific. What do you check first? In what order? What are the objective pass/fail criteria versus the subjective judgment calls? What tells you something needs flagging for further review? What does done look like for this task?

Include examples. Real examples from your work (anonymized if necessary). The difference between "check brand compliance" and showing an example of a logo spacing violation with the specific measurement that's wrong, that's the difference between a Skill that works and one that doesn't.

For my brand compliance Skill, I included:

• Our actual brand guidelines (the technical specifications, not the conceptual stuff)

• Three examples of common violations with specific measurements showing what's wrong

• Three examples of subjective issues that need human judgment (tone, hierarchy, strategic alignment)

• The exact format I want for flagging issues ("Logo width is 42px but minimum spec is 50px")

This took maybe two hours to write. Most of that time was finding good examples and documenting the exact specs.

Step 3:

Structure It As Instructions, Not Documentation

Skills work best when written as clear instructions for how to do something. Not as reference material about a topic.

Less effective: "Our brand maintains consistent spacing around the logo."

More effective: "Check logo clear space. Measure the minimum distance from the logo to any other element in all directions. Minimum clear space equals the height of the 'C' in the logo mark. Flag any violations with specific measurements: 'Logo has 8px clear space on the right side but minimum spec is 12px based on C-height.'"

The structure I use for most Skills:

1. Purpose and Context (2 to 3 sentences on what this Skill does and when it applies)

2. Objective Checks (The measurable, pass/fail criteria with specific standards)

3. Subjective Flags (What to surface for human review and how to describe it)

4. Output Format (How to structure the findings, violations separate from observations)

5. Examples (Real cases showing both objective violations and subjective flags)

You don't have to follow this exactly. But separating objective checks from subjective observations has been crucial for me.

Step 4:

Create the Actual Skill File

The technical part is simpler than you'd think. A basic Skill is just a folder containing:

manifest.json (describes what the Skill does and when Claude should use it)
instructions.md (your detailed process documentation)
examples/ (optional, for reference materials, templates, brand guidelines)

For non-technical creative leaders: you can write everything in Markdown (basically just formatted text) and don't need to code anything.

Here's a simplified version of my brand compliance Skill structure:

brand-compliance-skill/
├── manifest.json
├── instructions.md
└── examples/
├── brand-guidelines.pdf
├── violation-example.png
└── subjective-flag-example.png

The manifest.json is minimal:json

{ "name": "Brand Compliance Checker", "description": "Checks designs against brand guidelines for objective violations and flags subjective concerns", "version": "1.0" }

The real work is in instructions.md, which contains all the methodology I documented in Step 2.

If you're on a Claude Team or Enterprise plan, you can create and manage Skills through the Console interface without touching any files directly. For Pro plans, you work with the file structure, but it's still just writing in Markdown.

Step 5: Test With Real Work

Don't just create the Skill and assume it works. Try it on actual projects and see what happens.

I tested my brand compliance Skill by running it on some recent vendor designs where I'd already done manual reviews. Then I compared. Did it catch everything I caught? Did it flag things that weren't actually issues? How useful was the output format?

The first version missed some edge cases (logo on dark backgrounds has different clear space requirements, which I hadn't documented). I added those specifications. The second version was too aggressive about flagging tone concerns. It was flagging every design that wasn't explicitly conversational, even when a more formal tone was appropriate for the context. I refined the criteria for when tone should be flagged.

Pay attention to: Does Claude invoke the Skill when you'd expect it to? Are the objective checks actually catching violations accurately? Are the subjective flags useful or is it flagging things that don't matter? Is the output format easy to act on?

I went through four iterations on my brand compliance Skill before it consistently caught what I needed it to catch without over-flagging.

Step 6: Refine Based on What Actually Gets Used

After a few weeks of using a Skill, patterns emerge about what works and what doesn't.

My developer handoff Skill needed the most refinement. The initial version included too much detail. Specs that developers didn't actually need and that just cluttered the documentation. I stripped it down to what developers actually reference. Now the output is leaner and more useful.

The production requirements Skill needed more detail going the other direction. The initial version identified constraints but didn't explain why they mattered or how they connected. I added context. "Character count limited to 35 for headlines because smallest banner size (300x250) can't accommodate more at minimum readable font size." Now designers understand not just what the constraint is but why it exists.

You'll know a Skill is working when you start trusting its outputs enough that you're reviewing and refining rather than redoing the work yourself to be sure.

What I Learned From Actually Doing This

The Tedious Work Takes More Time Than You Realize

Before I tracked it, I didn't realize how much time I spent on objective compliance checks, information gathering, documentation generation. It felt like background work. The stuff you do between the "real work" of providing creative direction and strategic feedback.

Turns out, that background work was consuming 30 to 40 percent of my time. Logo spacing checks during design reviews. Hunting through Slack and email for brief information. Writing developer specs. Reformatting updates for different audiences.

None of that work required my creative judgment or strategic expertise. But it was eating 12 to 15 hours per week.

Now that work takes maybe 3 to 4 hours per week (mostly reviewing what Claude produced rather than doing it from scratch). The 8 to 11 hours I got back doesn't mean I'm working less. It means I'm spending that time on work that actually requires 18 years of experience.

Skills Work Best for Checklist Work and Synthesis

The Skills that save me the most time are the ones handling objective verification (brand compliance, technical specs), information aggregation (gathering scattered documentation), format translation (stakeholder communications, developer handoffs), and constraint mapping (production requirements).

These are all tasks with clear criteria, consistent processes, defined outputs.

The Skills that don't work as well are the ones that try to encode creative judgment. I experimented with a Skill for evaluating concept quality and it was... not useful. It could identify whether a design followed compositional principles, but it couldn't tell me if the concept was strategically sound or creatively distinctive.

Process and checklist work can be systematized. Creative judgment can't.

This Changes Where Your Expertise Actually Adds Value

Once Skills handle the first-pass compliance work and information synthesis, your role shifts.

I used to spend a lot of time on initial reviews. Catching guideline violations. Gathering information. Writing documentation. That work still happens, but now Claude (using my Skills) does the first pass.

I spend my time on second-order questions. Not "is the logo too small" but "does this design advance our positioning or just execute a tactic?" Not "where did I see that audience insight" but "how do we translate this insight into creative direction?" Not "what are the specs for this component" but "is this the right interaction pattern for this experience?"

The work that requires pattern recognition from seeing thousands of projects. The strategic decisions that depend on understanding the business context. The creative leaps that make work distinctive rather than just adequate.

That's where 18 years of experience actually matters. That's where I'm spending my time now.

You Can't Just Brain Dump Your Process

The hardest part of creating Skills isn't the technical setup. It's articulating your process clearly enough that it can be followed systematically.

I thought I could just describe how I check brand compliance and it would work. It didn't. I had to actually think through: What do I measure first and why? What's the threshold for flagging an issue? How do I distinguish between objective violations and subjective concerns? What context does someone need to act on this feedback?

This is valuable work even if you never create a Skill. Making your expertise explicit makes you better at teaching it to your team.

The Skills I use most are the ones where I was clearest about separating objective criteria from subjective judgment. When I tried to blend them, the Skill became inconsistent.

Skills Scale Process Knowledge Better Than Documentation

We've all worked at companies with brand guidelines that sit in a shared folder, unread. Process documentation that's technically available but rarely consulted. Templates that exist but get used inconsistently.

Skills are different because they're automatically invoked when relevant. You don't have to remember to check the brand guidelines. Claude loads the brand compliance Skill when you ask it to review a design. The knowledge gets applied consistently because the system prompts its use.

For creative leaders, this means your standards get maintained even when you're not personally reviewing every piece of work. Guideline violations get caught. Documentation follows consistent formats. Information gathering follows the same process.

That consistency compounds. Fewer revision cycles. Less rework. Higher baseline quality even when you're not in the room.

Some Things This Isn't

Skills handle process, checklists, information synthesis. They don't replace creative judgment, strategic decision making, or the ability to read room dynamics and manage stakeholder relationships.

I work with AI for creative production regularly (Midjourney for concept exploration, Veo3 for video production, custom GPTs for various specialized tasks). But Skills serve a different purpose. They're about automating the tedious work and creating consistent processes, not generating creative output.

They also make junior team members more effective faster because they have access to the same compliance checks, information gathering processes, documentation standards that senior team members use. But those team members still need to develop their own judgment over time. Access to good process doesn't replace experience.

The difference between asking Claude to check brand compliance and asking Claude to check brand compliance using your specific brand standards and flagging criteria is substantial. One gives you generic feedback that may or may not be relevant. The other gives you consistent evaluation against your actual standards.

Is This Worth Your Time?

The setup time per Skill is maybe 2 to 4 hours for something straightforward, longer for complex processes. I've created five Skills over the past month and spent probably 15 to 20 hours total, including iteration and refinement.

The time savings: I'm spending maybe 8 to 11 hours less per week on compliance checks, information gathering, documentation work. That's 32 to 44 hours per month. The ROI was positive after the first two weeks.

But the more significant benefit isn't time savings. It's consistency and focus.

Work gets evaluated against the same standards regardless of whether I personally reviewed it. Documentation follows the same format across designers and projects. Information gathering follows the same process for every brief. That consistency means fewer surprises, less rework, higher baseline quality.

And I'm spending my time on work that actually requires my expertise. The strategic creative direction. The judgment calls that come from seeing thousands of projects. The stakeholder relationships that determine whether good work actually ships.

If you're a creative leader who spends significant time on compliance checks, information gathering, documentation work, or reformatting content for different audiences, this is probably worth exploring.

How to Start

Don't try to build a comprehensive library of Skills immediately. Start with one task that eats your time without requiring your creative judgment.

For me, that was brand compliance checking. For you, it might be developer handoff documentation, production requirement synthesis, information gathering for creative briefs, stakeholder communication formatting, or something else entirely.

Pick one. Spend a few hours documenting how you actually do it. Create the Skill. Use it for a week. Refine it based on what works and what doesn't.

Then pick the next thing.

After five Skills, you'll have automated a meaningful portion of the tedious work that consumes your time without requiring your expertise. That's leverage that's hard to get any other way.

If you're already working with Skills for creative leadership work, I'm curious what you've built. The more we share frameworks, the less we all have to start from scratch.