Claude Code Skills: How I Automated My Coding Workflow

When AI codes without a method, it charges ahead. Claude Code skills impose discipline - brainstorming before implementing, systematic debugging, TDD. Here's how I use them day to day, followed by Anthropic's official best practices for writing effective skills.

The problem: AI without a method

You ask Claude Code to "add a logout button." The AI charges ahead. It writes code, modifies three files, and delivers a result. Sometimes it's exactly what's needed. Sometimes it made assumptions about placement, style, behavior - and you have to redo everything.

The problem isn't code quality. It's the absence of process. A good human developer doesn't code immediately. They think first: where should the button go? Does it need a confirmation? What happens on the session side? The AI skips this step unless you force it to.

This is exactly what skills in Claude Code do: they impose a workflow on the AI before it touches the code.

What is a skill?

A skill is a text file (Markdown) that Claude Code loads on demand. This file contains instructions, checklists, rules - a complete workflow the AI must follow to accomplish a type of task.

Think of it as an operating procedure. When a surgeon operates, they follow a precise protocol - not because they don't know how to operate, but because the protocol prevents oversights. Skills are the AI's protocol.

Concretely, a skill is:

• A file .md with YAML frontmatter (name, description, trigger)
• Stored in .claude/skills/ (project-local) or ~/.claude/skills/ (global)
• Invocable manually (/skill-name) or automatically by Claude Code when it detects a relevant context

Claude Code natively supports the skill system, but the collection I use - superpowers - is an open source project created by Jesse Vincent (obra). You can also create your own or install skills from other community repos.

The meta-skill: using-superpowers

Among all the skills I use, one stands out: using-superpowers. It's not a skill that does something - it's a skill that tells Claude Code how to use all the other skills.

Its core rule is simple:

Before any action or response, check whether a skill might apply. Even at a 1% chance, invoke it.

Why is this necessary? Because without this rule, Claude Code tends to "rationalize" not using a skill. It thinks "this is just a simple question" or "let me explore the code first." The meta-skill blocks these reflexes and enforces discipline.

The skill even defines a list of trap thoughts :

It also defines a priority order : process skills (brainstorming, debugging) come before implementation skills (frontend-design, etc.). The logic: decide how to do it before doing it.

My favorite skills and how I use them

Brainstorming - thinking before coding

This is the skill I invoke most often. Every time I ask to "add X" or "build Y", the brainstorming skill triggers and forces Claude Code to:

1. Explore the project's context (files, recent commits)
2. Ask clarifying questions - one at a time
3. Propose 2-3 approaches with their trade-offs
4. Present a design and wait for my approval

The golden rule: no code is written until the design is approved. Even for a "simple" button.

In my workflow on thisishumanmade.com for example, when I asked to "add an English version of the site", the brainstorming skill first identified the need to restructure the URLs (/en/ for the homepage, /en/offer/ for the offer), adapt the relative paths, and update Firebase for status translations. Without this brainstorming, the AI would probably have just duplicated the HTML file.

Systematic Debugging - debugging with method

When something doesn't work, the temptation is to propose an immediate fix. The systematic-debugging skill forces a different approach:

1. Observe and reproduce the problem
2. Formulate hypotheses
3. Test each hypothesis methodically
4. Confirm the root cause before fixing it

This is a rigid type skill - you follow it to the letter, no shortcuts. The reason: debugging is exactly the area where shortcuts cost the most. A fix that treats the symptom instead of the cause will come back to haunt you.

Test-Driven Development - tests first

The TDD skill enforces the classic cycle: Red → Green → Refactor. Write a failing test, write the minimal code to pass it, then refactor. Claude Code naturally applies this cycle when the skill is active.

What's interesting is that the AI is particularly good at TDD, because it doesn't have the human impatience to "just write the code first." Once the skill is loaded, it follows the protocol mechanically - exactly what you want.

Verification Before Completion - no "it's done" without proof

This skill prevents Claude Code from declaring victory too early. Before saying "it's done", it must:

• Run verification commands (tests, build, lint)
• Confirm the output is as expected
• Provide evidence (actual output, not assumptions)

How many times has an AI told you "there, it's fixed" when the code doesn't even compile? This skill eliminates that problem.

Dispatching Parallel Agents - parallelizing intelligently

When an implementation plan contains independent tasks, this skill lets you launch several subagents in parallel. Each agent works on its task without blocking the others. This is particularly useful for migrations or refactors that touch many files.

Anthropic's official best practices

After seeing how I use skills day to day, let's now look at Anthropic's official recommendations for writing good ones. These best practices come directly from the official documentation and apply whether you use Claude Code, the Agent SDK, or the API.

The core message: a good skill is concise, well-structured, and tested in real conditions.

Principle #1: conciseness above all

The context window is a shared resource. Your skill coexists with the system prompt, the conversation history, the other skills' metadata, and your query. Every token counts.

Anthropic's golden rule:

Claude is already very smart. Only add the context it doesn't already have.

Before writing a single line in a skill, ask yourself three questions:

• "Does Claude really need this explanation?"
• "Can I assume it already knows this?"
• "Does this paragraph justify its token cost?"

The concise version assumes Claude knows what a PDF is and how libraries work. Three times fewer tokens, same result.

Principle #2: calibrate the degrees of freedom

Not all skills should be equally directive. Anthropic offers a telling analogy: imagine Claude as a robot on a path.

• Narrow bridge with cliffs - there's only one safe route. Give exact instructions, no margin. Example: a database migration that must run in a precise order.
• Open field with no obstacles - plenty of paths lead to success. Give general direction and let Claude find the best path. Example: a code review where context determines the approach.

Structuring a skill well

Naming

Anthropic recommends the gerund form (verb + ing) for skill names: processing-pdfs, testing-code, managing-databases. This is clearer than vague names like helper or utils.

Technical constraints for the field name :

• 64 characters maximum
• Lowercase letters, digits, and hyphens only
• No reserved words (anthropic, claude)

The description - the critical factor

The description in the frontmatter is what lets Claude discover your skill among potentially 100+ available skills. Two rules:

1. Write in the third person - the description gets injected into the system prompt; an "I can help you" or "You can use this" creates discovery problems
2. Include both the "what" AND the "when" - describe what the skill does and in what context to use it

Progressive disclosure

The SKILL.md must stay under 500 lines. Beyond that, split the content into separate files that Claude loads on demand. When the user asks a question about form filling, Claude only loads the relevant file - not the API reference, not the examples. Result: fewer tokens consumed, more room for conversation history.

Important rule: keep references at a single level of depth. The SKILL.md points to files, but those files must not point to other files.

Mistakes to avoid

Too many options

Don't present 5 libraries to choose from. Give a default choice with an alternative if needed.

Perishable information

Avoid time-bound references that will become false ("if you do this before August 2025..."). Document the current method, and move old patterns into a collapsible block marked as deprecated.

Inconsistent terminology

Pick a term and stick with it throughout. Don't mix "API endpoint", "URL", "API route" and "path" in the same skill. Consistency helps Claude understand and follow the instructions.

Developing a skill iteratively

Anthropic's most interesting recommendation concerns the development process itself. Instead of writing a perfect skill on the first try, they propose a cycle with two instances of Claude:

1. Complete a task without a skill - work with "Claude A" using normal prompting. Note the information you provide multiple times
2. Ask Claude A to create the skill - it natively knows the format and structure of skills
3. Test with Claude B - a fresh instance with the skill loaded, on similar tasks
4. Observe the behavior - does it find the right information? Apply the rules? Miss something?
5. Go back to Claude A - "When Claude B used this skill, it forgot to filter by date. How can we improve it?"
6. Iterate - this observe-refine-test cycle is continuous

Another tip: create evaluations before writing the skill. First identify where Claude fails without a skill, build test scenarios, then write the minimum instructions needed to pass those tests. This is TDD applied to skills.