“Make me a tutorial outline” gets a sterile list of steps. A good tutorial outline picks one specific outcome, names the learner level, and gates each step with a success check the learner can verify on their own screen. The 12 templates below force every prompt to carry those three things, plus prerequisites and a “what next” bridge.
TL;DR
- Lead with the outcome the learner walks away with, not the topic.
- Name a single learner level (absolute beginner, comfortable with the basics, experienced) so the model calibrates depth.
- Give every step a verifiable success check (“you should see X”) and put prerequisites up front.
- Tutorials teach a beginner end-to-end; how-to guides assume context. Don’t mix the two shapes (see Diátaxis).
- Best models as of June 2026: Claude Opus 4.7 or Sonnet 4.6 for long, well-structured outlines (1M-token context, so you can paste an entire existing tutorial to refactor); GPT-5.5 Thinking when you also want the model to reason about pacing and pitfalls.
Who this is for
DevRel writers, course creators, founders writing onboarding docs, and tech bloggers turning a side project into a guide.
When not to use these prompts
Skip them for reference docs (different format — a catalog, not a journey) and for explanation pieces. And never outline a tutorial for a task you haven’t completed yourself end-to-end; the model will happily invent steps that don’t run.
What every tutorial outline prompt needs
Six elements separate a usable outline from a sterile step list:
- Outcome: the one thing the learner can do at the end (“deploy a static site to Firebase Hosting”), stated as a finished artifact, not a topic.
- Learner level: absolute beginner, comfortable with the basics, or experienced — this drives how much you explain.
- Time budget: 15, 30, 60 minutes. It caps scope and tells the model when to split into a series.
- Prerequisites: knowledge, tools, accounts, and a one-line setup check the reader runs before step 1.
- Per-step success check: a verifiable “you should see X” so learners never get stuck silently.
- What next: the bridge from the finished tutorial to a real project, so engagement survives the last step.
Best for
- Blog tutorial outline
- Course module outline
- Documentation walkthrough
- Internal onboarding doc
- Workshop / talk outline
Which model to run these in (June 2026)
| Model | Why for outlining | Note |
|---|---|---|
| Claude Sonnet 4.6 | Clean, structured outlines; 1M-token context | Free tier limited; Pro $20/mo |
| Claude Opus 4.7 | Best long-form structure; paste a full tutorial to refactor | Max plans; API 5/25 per 1M tokens |
| GPT-5.5 (Thinking) | Reasons about pacing and pitfalls | Plus $20/mo; default ChatGPT model |
| Gemini 3.1 Pro | Strong for long docs, 1M context | Google AI Pro $19.99/mo |
The templates are model-agnostic — they work in any of the above. For refactoring a long existing tutorial, prefer a 1M-token model (Opus 4.7, Sonnet 4.6, or Gemini 3.1 Pro) so the whole draft fits in one prompt.
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.
FAQ
- How long should a tutorial be?: Aim for 15-30 minutes of reader time. Beyond that, use template 7 to split into a series where each part ships a usable artifact.
- Code first or prose first?: Outcome first, then why, then steps with code, then verify. Skip “history of X” intros that bury the payoff.
- Should each step have a screenshot?: Only when text alone misleads. Screenshots rot faster than text — every UI redesign breaks them.
- How do I keep tutorials evergreen?: Pin framework and model versions explicitly, anchor time-sensitive claims with a date, and revisit semi-annually. Template 12 turns a stale tutorial into a patch list.
- Tutorial or how-to?: A tutorial teaches a beginner end-to-end through a guaranteed-to-work path; a how-to guide assumes a competent reader solving one task. Pick one shape per piece — the Diátaxis framework explains why conflating them confuses readers.
- Which AI model should write the outline?: As of June 2026, Claude Sonnet 4.6 or Opus 4.7 produce the cleanest structure and can hold a full existing tutorial in context (1M tokens). GPT-5.5 Thinking is strong when you want it to reason about pacing.
- Should AI write the whole tutorial?: Use AI for the outline and a first draft. Always run every step yourself on a clean machine before publishing — that is the one thing a model cannot verify for you.