A multi-step skill is a skill with dependency: stage two runs on what stage one produced, not on the original request. That way the model works through the nuance instead of jumping to a shallow, high-level answer. Below is how to build one, with a real example to run on Cowork.
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. For each stage, write its Input (what it is allowed to read), its Do (the one job), its Output format (the exact shape it must print, under a heading like "Output of Stage 2"), and a "Stop and wait for me if" line so a thin input becomes a question rather than an invented answer. The fifth part, the dependency line, comes in the next step, and the final assemble stage is the one exception that needs no stop line.
- Add the dependency line: each stage reads only the stage before it. This is the move that makes it multi-step and not one long prompt. 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, and that is what 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] description: [What it does in one plain clause, plus the phrases a user would say that should trigger it, for example "sort my X", "turn this into Y", even if they do not name the skill.] --- # [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 pasted]. - Do: [the one job of this stage, in plain instructions]. - Output format, print exactly: Output of Stage 1 [the shape it must produce] - Stop and wait for me if: [the condition where it should pause and ask, not guess]. - Dependency: none, this is the first stage. ## Stage 2: [Name] - Input: ONLY the Output of Stage 1. - Do: [one job, working on Stage 1's output]. - Output format, print exactly: Output of Stage 2 [the shape] - Stop and wait for me if: [condition]. - 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]. - Output format, print exactly: Output of Stage 3 [the shape] - Stop and wait for me if: [condition]. - 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]. ## 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, upload it under Customize, Skills, then call it with your notes pasted underneath. When you build your own, this is all you change: the stages, for yours.
--- 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 is made to. After the last stage it grades its own run out of eight, and it fails itself if a stage was skipped or an earlier answer was quietly reused. That is what quality means here: not a nicer recap, but a skill that will say "I did that wrong, run it again" instead of handing 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.". A skill that can fail itself is worth more than one that always sounds finished. 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 to do its job, which is the input's fault, not the skill's. The failure to watch for is the model quietly reaching back to the raw notes: if Stage 3 mentions something that was not in the Output of Stage 2, that is the exact thing the scoreboard catches, and the fix is to 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, because 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: upload it under Customize, Skills so it is one slash command away. Just know a skill like this is not an autopilot, it is a set of stages it walks through with you.
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. Not every multi-step skill is a chain. Some just need to load the same two or three files before every job: your voice sample, your rules, your list of words never to use. The stages here are not a pipeline, they are a fixed reading order. Stage 0 loads the references, then the job runs against them. Reach for this when the steps do not depend on each other but the context always does.
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 actually work, instead of inventing the stages from scratch. Process capture is not a third product to choose on day one, it is the way you get your first real pipeline.
Where the line is
- The honest bit: more stages is not more quality. Split only where the job genuinely changes shape. Three or four stages that truly depend on each other beat six that mostly repeat, because every extra stage is one more place the chain can quietly break. Two is often enough, and if you cannot name what Stage 2 reads that Stage 1 produced, you do not have two stages, 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.
A couple of quick questions
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.