Making the Framework Work

In Prompt, Workflow, Agent I laid out a pattern for decomposing work into atomic tasks that might be done with AI. The pattern looks like this:

Role – Verb Noun → Output (Done-when?)

Research Assistant – Summarize – The attached paper → Five bullet points. That kind of thing. The idea was to give you a structured way to look at your own work and figure out where AI fits. Identify the verbs, assess the complexity, decide if you need a Prompt, a Workflow, or an Agent.

It turns out you can take that pattern and make it executable. Not as a thought exercise, but as a working tool inside Claude Code — Anthropic’s command-line interface for Claude. The tool is called a skill, and this post walks through how to build one.

What Is a Skill?

A Claude Code skill is a folder containing a Markdown file called SKILL.md. That’s it at its most basic. The Markdown file contains instructions — domain knowledge, workflows, examples — that Claude reads and follows when the skill is triggered.

Skills live in ~/.claude/skills/. Each folder is one skill. The structure looks like this:

~/.claude/skills/my-skill/
├── SKILL.md            # Required — the instructions
└── references/         # Optional — supporting docs

The SKILL.md file has two parts. A YAML frontmatter block at the top that tells Claude what the skill does and when to use it. And a Markdown body that tells Claude how to do it.

The frontmatter is the trigger mechanism. Claude reads the description field and decides whether the skill matches what you’re asking for. This means the description needs to be specific about both purpose and activation — not just what the skill does, but the kinds of phrases that should invoke it.

The Workflow Decomposer Skill

Here is what the frontmatter looks like for the skill built from the Prompt, Workflow, Agent framework:

---
name: workflow-decomposer
description: >
  Decomposes task descriptions into atomic skills using the
  Role-Verb-Noun-Output pattern. Use when the user wants to:
  (1) Break down a complex task into automatable steps,
  (2) Identify which parts of their work can use AI,
  (3) Design a workflow or skill,
  (4) Understand task complexity (Prompt vs Workflow vs Agent).
  Triggers on phrases like "decompose this task",
  "break this down", "what skills do I need",
  "is this a prompt or workflow", "help me automate".
---

The body of SKILL.md encodes the six-step process from the original blog post as executable instructions. When triggered, the skill:

1. Identifies the work product — what actually gets shipped
2. Decomposes into atomic tasks using Role – Verb Noun → Output
3. Flags GenAI-friendly verbs — rated by confidence (high: Summarize, Extract, Classify; medium: Compare, Analyze; lower: Decide, Evaluate)
4. Assesses complexity — Prompt, Workflow, Agentic Workflow, or Agent
5. Outputs a decomposition table in structured Markdown
6. Generates SKILL.md templates for each atomic task on request

That last step is where it gets interesting. The skill does not just analyze your work — it produces new skills. Each atomic task it identifies can become its own installable skill, ready to use.

From Description to Working Skills

Let’s look at how this works end-to-end. Say you type:

/workflow-decomposer "Create a blog post from a collection of research notes"

The skill identifies the work product (a published blog post) and decomposes it into four atomic tasks:

Four verbs — Extract, Generate, Rewrite, Format — all high-confidence GenAI verbs. Four tasks in a linear chain. Complexity level: Workflow.

Now ask the skill to generate SKILL.md templates for each task, and you get four installable skills: extract-research-themes, generate-blog-draft, rewrite-for-style, and format-blog-post. Each one has its own frontmatter, process steps, input/output definitions, and done-when criteria.

You run them as a chain:

/extract-research-themes  →  /generate-blog-draft  →  /rewrite-for-style  →  /format-blog-post

Each step is a checkpoint where you review and adjust before continuing. That is the human-in-the-loop pattern built in by default — and it addresses the Verification Burden by keeping you in the loop at natural breakpoints rather than asking you to verify a single large output.

What Makes This Useful

Notice what happened. A single sentence — “create a blog post from research notes” — became four defined, bounded, reusable tools. Each one works on its own. /rewrite-for-style is useful for any draft, not just blog posts. /extract-research-themes works on any collection of notes.

This is the Simplification principle applied to tooling. Strip the work down to its atomic components, give each one clear boundaries, and they become composable. You can swap out a single step without rebuilding the whole chain. You can reuse pieces across different workflows.

The skill also tells you something important about your work’s complexity. If the decomposition is full of high-confidence verbs in a linear chain, automation is straightforward. If you see lower-confidence verbs like Decide or Evaluate, or if the tasks branch and loop, you know you are moving up the complexity ladder toward Agent territory — and you should plan accordingly, including where to put human checkpoints.

In the spirit of making frameworks practical, the short version is this: if you have described your work using Role – Verb Noun → Output, you already have the blueprint for a working tool. The gap between a framework on a blog and a skill in your terminal is one Markdown file.

The workflow-decomposer skill is available on GitHub if you want to try it yourself.