A multi-step skill is a skill with dependency: stage two runs only on what stage one produced, so the model works through the nuance instead of jumping to a shallow answer.
A multi-step skill is a pipeline: each stage takes only the previous stage's output as its input, produces a fixed output format, and the skill ends with a self-check that fails the run if a stage was skipped or an earlier answer was reused without being produced.
How to build one, in five steps
You are not writing a clever prompt, you are laying out an assembly line. Here is the whole method. The skeleton you download below is exactly these five steps, ready to fill in.
- Break the job into stages, one output each. Write the job as the ordered steps you would do by hand: read, then sort, then draft, then check. Each stage should produce one thing you could tick off. A stage that tries to do two jobs at once is the first place the skill gets muddled, so split it.
- Give every working stage the same four parts. Input is what it may read, Do is its one job, Output format is the exact shape it prints, and a "Stop and wait for me if" line makes a thin input a question rather than an invented answer. Only the final assemble stage skips the stop line.
- Add the dependency line: each stage reads only the stage before it. Tell each stage to use only the previous stage's Output and never reach back to the raw input. If it cannot point at "Output of Stage 2", it cannot pretend it used it, which stops the model sprinting to the end and back-filling the middle.
- Make it print each stage's output as it goes. The headings are not decoration. They are the exact thing the next stage reads, and the thing that lets you watch the chain work. No printed output for a stage means no proof it ran.
- End with a scoreboard that can fail the run. A final self-check that scores whether the stages ran in order, used only the prior output, and invented nothing, and prints FAILED if not. A skill that grades its own honesty is worth far more than one that always sounds finished.
Build your own: the skeleton
This is the whole method in one file. Download it, then swap the bracketed parts for your own job, and add or remove stages so each one has a single, checkable output. The skeleton is what you keep. The example after it is just the skeleton filled in once, so you can see the shape.
--- name: [Your skill name in short kebab-case, the way you would name a file. Say what the whole pipeline does, not one stage of it. For a bakery owner turning supplier emails into a weekly order, order-supplier-emails beats a vague name like emails or admin. One clear job, lowercase, hyphens between words.] description: [One plain clause naming what it does, then the exact phrases a user would type to reach for it, even without naming the skill. This line is the only thing that makes a skill fire, so put the real words in. For the bakery order skill: "Turn the week's supplier emails into one order sheet. Use when I say sort the supplier emails, what do we need to order, or build this week's order." Write the phrases you actually say, not tidy ones you never would.] --- # [Your skill name] (a pipeline) Run the stages below IN ORDER. Each stage reads ONLY the Output of the stage before it, never the raw input again once you have passed Stage 1. Print every stage's result under a heading "Output of Stage N" so the next stage has an exact thing to use. The final stage prints the result and the Scoreboard, no heading needed. Do not answer the final stage first. ## Stage 1: [Name, for example Pull] - Input: [The raw thing the user pastes in at the start, named plainly so the stage knows what it is reading. For the bakery skill this is the block of supplier emails pasted under the request, quantities, prices and all. Name the actual thing, not "the input".] - Do: [The one job of this stage, in plain instructions, with a clear line saying what NOT to do so it does not run ahead. For the bakery: read every email once and pull each line that names an item, a quantity or a price, keeping the supplier's name against it, and do not add up anything or drop a line yet. Invent no item and no price that is not written in the emails.] - Output format, print exactly: Output of Stage 1 [The exact shape it must print, as headed lists or a simple layout, so the next stage has something precise to read. For the bakery: a RAW LINES list, one bullet per item with supplier, quantity and price exactly as written.] - Stop and wait for me if: [The condition where a thin or wrong input should become a question, not a guess. For the bakery: the pasted block holds no emails, or none of them mention an item. Say what you can see and stop, do not invent an order.] - Dependency: none, this is the first stage. ## Stage 2: [Name] - Input: ONLY the Output of Stage 1. - Do: [One job that works only on Stage 1's output, moving or grouping it rather than fetching anything new. For the bakery: group the raw lines by supplier and flag any item that appears twice at different prices, so a duplicate is caught before the order is built.] - Output format, print exactly: Output of Stage 2 [The shape this stage prints, headed so Stage 3 can read it cleanly. For the bakery: a BY SUPPLIER list, each supplier with its items under it, and a CLASHES list for anything priced two ways.] - Stop and wait for me if: [The condition where there is nothing to work with. For the bakery: Stage 1 produced no lines to group.] - Dependency: use only what appears in the Output of Stage 1. Add nothing new. ## Stage 3: [Name] (add or delete stages to fit your job) - Input: ONLY the Output of Stage 2. - Do: [One job on Stage 2's output, the step that turns sorted material into the near-final thing. For the bakery: write each supplier's line as one order row, item, quantity and price, and total each supplier, using only the numbers already in Stage 2. Never invent a quantity or a price to fill a gap, mark it (missing) instead.] - Output format, print exactly: Output of Stage 3 [The shape, headed. For the bakery: an ORDER ROWS list per supplier with a running total, and a NEEDS A NUMBER FROM YOU list for anything marked (missing).] - Stop and wait for me if: [The condition where the stage cannot do its job honestly. For the bakery: an item has no quantity or no price anywhere in Stage 2, so it cannot be ordered without a guess.] - Dependency: trace every item back to the Output of Stage 2. ## Final stage: Assemble and self-check - Input: the Outputs of the stages above. - Do: assemble the final result, then run the Scoreboard and print it under it. - Output format: [Your final shape, the clean thing you actually want to walk away with. For the bakery: a THIS WEEK'S ORDER sheet grouped by supplier with a total per supplier and a grand total, then a SINGLE THING TO CHECK FIRST line naming whatever still needs a number from you.] ## Scoreboard, run every time and print it Score each line 0, 1 or 2. 2 means fully, 1 partly, 0 no. - Stages ran in order, none skipped: [ ] - Each stage used only the prior stage's Output, nothing re-invented: [ ] - Every output format was followed exactly: [ ] - No invented fact, and every gap marked: [ ] TOTAL: [ ] out of 8. If any line scores 0, or a stage was skipped, print "FAILED. Rerun from the first weak stage." and name that stage.
For example: a skill you can run on Cowork
Here is that skeleton filled in for one real job: turning messy meeting or call notes into decisions, sharp actions and open questions. It is a good one to try on Cowork, where you can watch each stage feed the next in front of you.
Download it, add it as a skill in Claude, then call it with your notes pasted underneath. When you build your own, the stages are all you change.
--- name: notes-to-actions description: Turn messy meeting or call notes into clear decisions, sharp actions and open questions, one stage at a time. Use whenever the user pastes raw notes and wants to know what was decided and what to do next, or says "sort my notes", "what were the actions", "pull the decisions", or "turn this call into a to-do list", even if they do not name the skill. --- # Notes to actions (a pipeline) Run the four stages below IN ORDER. Each stage reads ONLY the Output of the stage before it, never the raw notes again once you have passed Stage 1. Print every stage's result under a heading "Output of Stage N" so the next stage has an exact thing to use (Stage 4 is the final recap, so it prints the recap and the Scoreboard, no heading needed). After Stage 4, run the Scoreboard and print it. Do not answer the final recap first. ## Stage 1: Pull - Input: the raw notes the user pasted. - Do: read once, do not summarise. Pull every decision, every action or task, and anything left open or unresolved. Keep any name or date attached to an item. Invent nothing. - Output format, print exactly: Output of Stage 1 RAW DECISIONS: - ... RAW ACTIONS: - ... RAW OPEN: - ... - Stop and wait for me if: the notes are empty, or are clearly not notes. Say what you see instead and stop. - Dependency: none, this is the first stage. ## Stage 2: Sort - Input: ONLY the Output of Stage 1. Do not look at the raw notes again. - Do: move each bullet into the right one of three lists. If a bullet could be two, put it under Actions and add "(also reads as a decision)". Drop pure chatter. - Output format, print exactly: Output of Stage 2 DECISIONS: - ... ACTIONS: - ... OPEN QUESTIONS: - ... - Stop and wait for me if: Stage 1 produced nothing to sort. - Dependency: you must sort only bullets that appear in the Output of Stage 1. If you add anything new here, you have failed. ## Stage 3: Sharpen - Input: ONLY the ACTIONS list inside the Output of Stage 2. - Do: rewrite each action as one line that starts with a verb, with (owner) if the item names one and (date) if it gives one, otherwise (no owner) or (no date). Never invent an owner or a date. - Output format, print exactly: Output of Stage 3 SHARP ACTIONS: - [verb] ... (owner) (date) NEEDS A LINE FROM YOU: - any action too vague to start with a verb - Stop and wait for me if: every action is too vague to sharpen. List them under NEEDS A LINE FROM YOU rather than guessing. - Dependency: every SHARP ACTION must trace to one bullet in the Stage 2 ACTIONS list. Do not pull actions from anywhere else. ## Stage 4: Assemble and self-check - Input: the DECISIONS and OPEN QUESTIONS from the Output of Stage 2, and the SHARP ACTIONS from the Output of Stage 3. - Do: assemble the final recap, then run the Scoreboard and print it under it. - Output format, print exactly: DECISIONS - ... ACTIONS - [verb] ... (owner) (date) OPEN QUESTIONS - ... MOST IMPORTANT NEXT STEP - one line naming the single thing to do first. - Dependency: use only the Outputs of Stage 2 and Stage 3. Do not reach back to the raw notes. ## Scoreboard, run every time and print it Score each line 0, 1 or 2. 2 means fully, 1 means partly, 0 means no. - Stages ran in order, none skipped: [ ] - Each stage used only the prior stage's Output, nothing re-invented from the raw notes: [ ] - Every output format was followed exactly: [ ] - No invented name, date, number or decision, and every gap marked with (no owner), (no date) or NEEDS A LINE FROM YOU: [ ] TOTAL: [ ] out of 8. If any line scores 0, or a stage was skipped, print: "FAILED. Rerun from the first weak stage." and name that stage.
The scoreboard is the point
Most skills never tell you when they cut a corner. This one grades its run out of eight after the last stage, and fails itself if a stage was skipped or an earlier answer was reused. It will say "I did that wrong, run it again" rather than hand you a confident, broken answer. Here is what it prints.
| Stages ran in order, none skipped | 0 to 2 |
| Each stage used only the prior stage's output, nothing re-invented | 0 to 2 |
| Every output format was followed exactly | 0 to 2 |
| No invented facts, and every gap marked | 0 to 2 |
Any zero, or any skipped stage, and it prints "FAILED. Rerun from the first weak stage." When it does fail, you do not rewrite anything: reply "rerun from Stage 2", or whichever stage it named, and it redoes the chain from there.
If it fails the same stage twice, your notes are probably too thin for that stage, the input's fault rather than the skill's. The failure to watch for is the model reaching back to the raw notes: if Stage 3 mentions something missing from the Output of Stage 2, the scoreboard catches it and you rerun that stage.
How you run it, and why it is not autonomous
A multi-step skill does not go off and finish the job on its own. It works through the stages in order and prints each one's output as it goes, and you stay in the loop the whole time: you can read Stage 1 before it moves on, stop it, or hand it a missing line.
In a hands-on surface like Cowork this is the point you can see: each stage genuinely needs the one before it, Stage 2 works on Stage 1's output and Stage 3 on Stage 2's, so the chain does real work in front of you instead of one hidden leap to the answer.
You can run it two ways. Let it work through all four stages in a single reply, or paste one stage's output into the next yourself when you want to check or edit between steps. Either way you are driving.
Saving it as a skill is optional but worth it once the job repeats, because then it is one slash command away. Just know a skill like this walks through its stages with you rather than running as an autopilot.
If a job spans more than one sitting, you need not start over. Each stage prints its Output, so drop the last finished one into a running note, and next time paste it back in and tell the skill to carry on from there. You still start each run, it just picks up where the chain got to.
What it actually produces
Here is the pipeline run on a few messy lines, so you can see each stage hand its output to the next rather than picture it.
You paste in:
Sarah to send the deck by Friday. We agreed to push the launch to Q2. Still unsure on the budget, need to check with finance. Tom said the pricing page is out of date. Good call today.
Output of Stage 1 RAW DECISIONS: - push the launch to Q2 RAW ACTIONS: - Sarah to send the deck by Friday - check the budget with finance - pricing page is out of date (Tom) RAW OPEN: - budget not decided Output of Stage 2 DECISIONS: - Push the launch to Q2 ACTIONS: - Sarah to send the deck by Friday - Check the budget with finance - Update the pricing page OPEN QUESTIONS: - What is the budget Output of Stage 3 SHARP ACTIONS: - Send the deck (Sarah) (Friday) - Check the budget with finance (no owner) (no date) - Update the pricing page (no owner) (no date) NEEDS A LINE FROM YOU: - none DECISIONS - Push the launch to Q2 ACTIONS - Send the deck (Sarah) (Friday) - Check the budget with finance (no owner) (no date) - Update the pricing page (no owner) (no date) OPEN QUESTIONS - What is the budget MOST IMPORTANT NEXT STEP - Chase Sarah's deck, it has the nearest deadline. Scoreboard, out of 8 - Stages ran in order, none skipped: 2 - Each stage used only the prior stage's output: 2 - Every output format was followed exactly: 2 - No invented facts, every gap marked: 2 TOTAL: 8 out of 8.
Notice what did not happen. It never invented an owner or a date it was not given, it marked those gaps instead. The budget stayed an open question rather than becoming a made-up figure. And the most important next step came out of the actions it had already sharpened, not a fresh guess. That is the chain holding.
Two smaller shapes, so you know when not to build a pipeline
The reference kit. Some skills just need the same two or three files loaded before every job: your voice sample, your rules, your never-use words. The stages are a fixed reading order: Stage 0 loads the references, then the job runs against them. Reach for this when the steps are independent but the context always applies.
Process capture, which is how you build the pipeline. You do not write a good pipeline from a blank page, you capture one. Do the job once, out loud, narrating every move, or screen-record yourself doing it and describe what you clicked and why.
Hand that transcript to Claude and ask it to turn your steps into a staged skill with the anatomy above. Then you edit a draft that already matches how you work, instead of inventing the stages from scratch. Process capture is the way you get your first real pipeline, rather than a third product to choose on day one.
Where the line is
- The honest bit: more stages is not more quality. Split only where the job changes shape. Three or four stages that depend on each other beat six that mostly repeat, because every extra stage is another place the chain can break. Two is often enough; if you cannot name what Stage 2 reads from Stage 1, you have one.
- The scoreboard grades honesty, not correctness. It can confirm the skill followed its own stages and invented nothing. It cannot tell you the notes you pasted were right. You still read the output before you act on it.
Build one from a job you already do in a fixed order
Pick something you handle in the same rough order every time: a refund email, a weekly review, turning a brief into a plan. Narrate yourself doing it once and hand that to Claude to draft the stages, or start from the notes-to-actions file above and swap the stages for yours.
Keep a Dependency line on every stage naming exactly which earlier Output or Outputs it may read, keep the scoreboard, and run it on something real today. You will see it either hold the chain or fail itself, and both are useful.
Questions people ask
How to create a custom skill for Claude?
Start from the skeleton on this page: break the job into stages with one output each, give every stage an input, one job, an output format and a stop line, and end with a self-check that can fail the run. Then add the file as a skill in Claude.
What makes a skill multi-step and not just long?
Dependency. Each stage runs only on the output of the stage before it, not on the raw request. If every stage just re-reads the original ask, you have one long prompt in four paragraphs.
How do I stop Claude skipping to the final answer?
Number the stages, tell it to print each stage's output under its own heading, make the next stage read only that, and add a scoreboard at the end that fails the run if a stage was skipped or redone from scratch.
How do I build one without writing it from scratch?
Process capture. Do the job once and narrate every step, hand that transcript to Claude, and ask it to turn your steps into a staged skill. You edit a draft instead of facing a blank page.