Who holds
the plan?

Not "which is stronger" —
but who holds the plan.

Here's the way to remember it: what a Skill saves is the instructions; what a Workflow saves is the orchestration process itself. They aren't even the same kind of thing, so a Workflow doesn't replace a Skill — they each do their own job.

Switch and watch: who gets the plan,
where the results pile up

Switch between the three and keep an eye on two things: which box the block marked PLAN slides into, and where each step's intermediate results land on the right.

The plan changes hands, column by column

Don't read this table across the rows, comparing strength. Read it down the columns: watch how "who holds the plan" gets handed from the leftmost column all the way to the right. The highlighted row is the dividing line.

Every row comes straight from code.claude.com/docs/en/workflows [Official].

Three files, here's what each looks like

Those distinctions sound abstract, but on disk they're just three different files. Put them side by side and the table's "what you can reproduce" row gets concrete fast.

---
name: security-scout
description: scan a single file for injection risk, in isolation
tools: Read, Grep
model: sonnet
---
You are a security reviewer. Read only the given file and find
unvalidated input that flows into dangerous sinks. Return each as
{ file, line, risk }. Don't fix anything, don't wander off-topic.

---
name: pdf-fill
description: fill PDF form fields. Use when data needs
  to be written into a PDF form.
---
# Fill a PDF form

1. List every field with pdftk dump_data_fields
2. Map the user's data to field names
3. Build an FDF, then write it back with pdftk fill_form

→ field-name reference: references/field-map.md

export const meta = {
  name: 'bug-hunt',
  description: 'find bugs across the repo, verify each before reporting',
  phases: [{ title: 'Find' }, { title: 'Verify' }],
}

// find in parallel by dimension; verify each finding the moment it appears
const found = await pipeline(DIMENSIONS,
  d => agent(d.prompt, { phase: 'Find', schema: BUGS }),
  rv => parallel(rv.bugs.map(b => () =>
    agent(`Try to refute this: ${b.title}`,
          { phase: 'Verify', schema: VERDICT })
      .then(v => ({ ...b, ok: v.isReal })))))

return found.flat().filter(b => b.ok)   // keep only the ones verified true

Samples are illustrative: Subagent / Skill follow the official file formats; the Workflow script follows the official runtime API (agent() / pipeline() / parallel() / meta).

Keep results out of the context,
and the context won't rot

This is exactly why a Workflow can run for hours, even days, on end. With a Skill or Subagent, every intermediate result gets stuffed back into the context window: the bigger the task, the fuller the window, and the more it rots. A Workflow keeps those results in script variables, so Claude only ever sees the final answer.

How a workflow reaches
results a single pass can't

The real trick isn't "running more agents." It's writing the quality patterns straight into the loop: let several conclusions poke holes in each other, draft a few versions from different angles and weigh them, and keep iterating until the answers settle.

Each does its own job, and they stack

The two aren't even on the same level. Every agent a workflow fans out can have a skill attached before it starts work. They're meant to be used together, not picked between.

When to reach for which

Bun: Zig → Rust, 11 days

This is the scale case the docs single out. Four workflows chained together: the first maps out every memory lifetime in the Zig code, the second ports it into Rust file by file — two reviewers per file — the third runs builds and tests on a loop until both go green, and the last runs optimizations overnight, opening a separate PR for each spot for a human to review.