“Make me a tutorial outline” gets a sterile list of steps. Good tutorial outlines pick one specific outcome, name the learner level, and gate each step with a success check the learner can verify.
Who this is for
Devrel writers, course creators, founders writing onboarding docs, tech bloggers turning a project into a guide.
When not to use these prompts
Don’t use these for reference docs — different format. Don’t use them when you haven’t actually completed the task yourself.
Prompt anatomy / structure formula
Every tutorial outline prompt should carry six elements:
- Audience: one specific reader, not “anyone interested in X”.
- Goal: one outcome — read / click / sign up / agree / share.
- Voice: brand voice or author voice with 2-3 anchor adjectives.
- Constraints: word count, banned phrases, must-include facts.
- Format: paragraph, bulleted, headed sections, table.
- Examples: 1-2 examples of the tone you want — best lever for matching voice.
Best for
- Blog tutorial outline
- Course module outline
- Documentation walkthrough
- Internal onboarding doc
- Workshop / talk outline
12 copy-ready prompt templates
1. Outcome-first outline
I want to write a tutorial that ends with the learner achieving: `{outcome}`. Learner level: `{level}`. Time budget: `{minutes}` minutes. Output an outline with: (1) one-sentence promise, (2) prerequisites, (3) 5-8 numbered steps each with a success check, (4) common-pitfalls section, (5) what to do next.Variables to swap: outcome, level, minutes
2. Beginner-friendly outline
Rewrite this outline for absolute beginners. (1) Replace each jargon term with a plain-English version + a one-line side note for advanced readers, (2) Add a "first try" with a known-good fixture, (3) Halve any step that has > 3 substeps.3. Tutorial prerequisites section
For tutorial topic `{topic}`, write the prerequisites section. Cover: (1) Knowledge prereqs, (2) Tools / accounts needed, (3) Working setup checks (a one-liner the reader can run), (4) Time estimate. Don't list optional reading.Variables to swap: topic
4. Success check per step
For this outline, append a success check to each step: a one-line "you should see X" the reader can verify before moving on. Don't add a check that requires output unavailable in the step itself.5. Common-pitfalls section
For this tutorial, list 5 common pitfalls. For each: (1) symptom (what the learner will see), (2) cause, (3) one-line fix. Order by likelihood — most-frequent pitfall first.6. Cross-platform variants
For commands or code in this tutorial that differ on macOS / Windows / Linux, produce a small variant table. Don't fork the whole tutorial — only the lines that differ.7. Series structure for a long tutorial
My tutorial would be 90+ minutes. Split into a 3-part series. Each part: outcome, time budget, prerequisites (linking back to part 1), final state at end of part. Don't cliff-hang — each part must produce a usable artifact.8. Video script outline from a written tutorial
Convert this written tutorial outline into a video script outline: (1) Cold-open hook (5s), (2) "What we'll build" (15s), (3) Steps with screen-action notes, (4) Outro CTA. Optimise for retention: each section ≤ 60s of screen time.9. Workshop adaptation
Adapt this tutorial outline for a 60-minute live workshop: (1) Pre-work attendees must do, (2) In-room steps, (3) Pair-programming moments, (4) Q&A pause points, (5) Wrap with shipped artifact.10. Course module outline
Turn this tutorial into a course module: (1) Learning objectives (3-5), (2) Lessons (each with title + length + outcome), (3) Quiz at end with 3 questions, (4) Capstone exercise. Phrase objectives with measurable verbs (build, configure, deploy).11. Outline gap audit
Audit this outline for gaps: (1) Steps that assume an unstated prerequisite, (2) Jumps in difficulty, (3) Missing error-recovery, (4) Steps that produce no observable result. Output a fix list.12. Tutorial outline for a new framework version
Update this tutorial for `{frameworkVersion}`. List: (1) Steps that need rewrite due to API change, (2) New idiomatic patterns the old tutorial misses, (3) Deprecated terms to remove. Don't propose a full rewrite if 4 patches do it.Variables to swap: frameworkVersion
Common mistakes
- Outlining a tutorial you haven’t actually run end-to-end.
- Missing success checks — learners get stuck silently.
- Listing prerequisites at the END.
- Single-platform commands without variants.
- Cliffhanger endings in multi-part series.
- Treating reference docs and tutorials as the same shape.
- Forgetting “what next” — readers want the bridge to a real project.
How to push results further
- Lead with the outcome, not the topic.
- Limit each step to one new concept.
- Verifiable success checks — “you should see X” is gold.
- Add pitfalls before code; learners spot them mid-step.
- Time-box: split if > 30 min.
- Always include “what next” — keeps engagement after the tutorial ends.
- Test the outline by running it yourself on a clean machine.
Practical depth notes
Use these prompts as starting points, not final answers. For Tutorial Outline Prompts: 12 Templates for Step-by-Step Guides, the useful extra work is to replace every generic placeholder with a real constraint: audience, channel, length, brand voice, examples to imitate, and examples to avoid. Run at least two versions with different constraints, then compare the outputs side by side instead of accepting the first polished response.
A good result should pass three checks: it is specific enough that another person could reuse it, it avoids vague praise or filler, and it gives you an editable artifact rather than a broad suggestion. If the output feels generic, add one concrete reference, one forbidden pattern, and one measurable success criterion before rerunning the prompt. Before saving a prompt as reusable, test it on one realistic input and one edge case. The realistic input proves the template can produce the normal deliverable; the edge case shows whether it handles messy constraints, missing context, or an unusual audience. Keep the better output, but also keep the failed version with a note on what was missing. That small failure log is what turns a prompt collection from a list of nice sentences into a practical working library.
FAQ
- How long should a tutorial be?: Aim for 15-30 minutes. Beyond, split into a series.
- Code first or prose first?: Outcome first → why → steps with code → verify. Skip “history of X” intros.
- Should each step have a screenshot?: Only when text alone misleads. Screenshots rot faster than text.
- How do I keep tutorials evergreen?: Pin framework versions; revisit semi-annually.
- Tutorial or how-to?: Tutorial teaches a beginner; how-to assumes context. Pick one shape per piece.
- Should AI write the whole tutorial?: AI for outline + draft. Always run the steps yourself before publishing.