Designing Workflow Skills

Designing Workflow Skills

Build workflow-based skills that execute reliably by following structural patterns, not prose.

Essential Principles

Claude decides whether to load a skill based solely on its frontmatter description. The body of SKILL.md — including "When to Use" and "When NOT to Use" sections — is only read AFTER the skill is already active. Put your trigger keywords, use cases, and exclusions in the description. A bad description means wrong activations or missed activations regardless of what the body says.

"When to Use" and "When NOT to Use" sections still serve a purpose: they scope the LLM's behavior once active. "When NOT to Use" should name specific alternatives: "use Semgrep for simple pattern matching" not "not for simple tasks."

Unnumbered prose instructions produce unreliable execution order. Every phase needs:

• A number (Phase 1, Phase 2, ...)
• Entry criteria (what must be true before starting)
• Numbered actions (what to do)
• Exit criteria (how to know it's done)

Skills use allowed-tools: in frontmatter. Never list tools the component doesn't use. Never use Bash for operations that have dedicated tools (Glob, Grep, Read, Write, Edit).

Most skills should include TodoRead and TodoWrite in their tool list — these enable progress tracking during multi-step execution and are useful even for skills that don't explicitly manage tasks.

SKILL.md stays under 500 lines. It contains only what the LLM needs for every invocation: principles, routing, quick references, and links. Detailed patterns go in references/. Step-by-step processes go in workflows/. One level deep — no reference chains.

Every workflow instruction becomes tool calls at runtime. If a workflow searches N files for M patterns, combine into one regex — not N×M calls. If a workflow spawns subagents per item, use batching — not one subagent per file. Apply the 10,000-file test: mentally run the workflow against a large repo and check that tool call count stays bounded. See anti-patterns.md AP-18 and AP-19.

Not every step needs the same level of prescription. Calibrate per step:

• Low freedom (exact commands, no variation): Fragile operations — database migrations, crypto, destructive actions. "Run exactly this script."
• Medium freedom (pseudocode with parameters): Preferred patterns where variation is acceptable. "Use this template and customize as needed."
• High freedom (heuristics and judgment): Variable tasks — code review, exploration, documentation. "Analyze the structure and suggest improvements."

A skill can mix freedom levels. A security audit skill might use high freedom for the discovery phase ("explore the codebase for auth patterns") and low freedom for the reporting phase ("use exactly this severity classification table").

Prerequisites

See setup-environment.md for the shared environment setup. Install pre-commit hooks before making any commits:

uv sync --all-groups
uv run pre-commit install

When to Use

• Designing a new skill with multi-step workflows or phased execution
• Creating a skill that routes between multiple independent tasks
• Building a skill with safety gates (destructive actions requiring confirmation)
• Structuring a skill that uses subagents or task tracking
• Reviewing or refactoring an existing workflow skill for quality
• Deciding how to split content between SKILL.md, references/, and workflows/

When NOT to Use

• Simple single-purpose skills with no workflow (just guidance) — write the SKILL.md directly
• Writing the actual domain content of a skill (this teaches structure, not domain expertise)
• Non-skill Claude Code development — this is specifically for skill architecture

Pattern Selection

Choose the right pattern for your skill's structure. Read the full pattern description in workflow-patterns.md.

How many distinct paths does the skill have?
|
+-- One path, always the same
|   +-- Does it perform destructive actions?
|       +-- YES -> Safety Gate Pattern
|       +-- NO  -> Linear Progression Pattern
|
+-- Multiple independent paths from shared setup
|   +-- Routing Pattern
|
+-- Multiple dependent steps in sequence
    +-- Do steps have complex dependencies?
        +-- YES -> Task-Driven Pattern
        +-- NO  -> Sequential Pipeline Pattern

Pattern Summary

Structural Anatomy

Every workflow skill needs this skeleton, regardless of pattern:

---
name: kebab-case-name
description: "Third-person description with trigger keywords — this is how Claude decides to activate the skill"
allowed-tools:
  - [minimum tools needed]
---

# Title

## Essential Principles
[3-5 non-negotiable rules with WHY explanations]

## When to Use
[4-6 specific scenarios — scopes behavior after activation]

## When NOT to Use
[3-5 scenarios with named alternatives — scopes behavior after activation]

## [Pattern-Specific Section]
[Routing table / Pipeline steps / Phase list / Gates]

## Quick Reference
[Compact tables for frequently-needed info]

## Reference Index
[Links to all supporting files]

## Success Criteria
[Checklist for output validation]

Anti-Pattern Quick Reference

The most common mistakes. Full catalog with before/after fixes in anti-patterns.md.

Tool Assignment Quick Reference

Map your component type to the right tool set. Full guide in tool-assignment-guide.md.

Key rules:

• Use Glob (not find), Grep (not grep), Read (not cat) — always prefer dedicated tools
• List only tools that instructions actually reference
• Read-only components should never have Write or Bash

Rationalizations to Reject

When designing workflow skills, reject these shortcuts:

Reference Index

Success Criteria

A well-designed workflow skill:

• Has When to Use AND When NOT to Use sections
• Uses a recognizable pattern (routing, pipeline, linear, safety gate, or task-driven)
• Numbers all phases with entry and exit criteria
• Lists only the tools it actually uses (least privilege)
• Keeps SKILL.md under 500 lines with details in references/workflows
• Has no hardcoded paths (uses {baseDir})
• Has no broken file references
• Has no reference chains (all links one hop from SKILL.md)
• Includes a verification step at the end of the workflow
• Has a description that triggers correctly (third-person, specific keywords)
• Includes concrete examples for key instructions
• Explains WHY, not just WHAT, for essential principles