screencast_tutorials v1.0.0

name: "screencast_tutorials" description: "Plan, record, and edit task-first software tutorial screencasts. Triggers when making a screen-recorded tutorial, software demo video, walkthrough, or how-to video: task-first outlines, the show-once-say-once rule, zoom emphasis for detail, and pacing so viewers can follow along."

Screencast Tutorials

Purpose

Turn one user task into a short, watchable screen-recorded tutorial. The skill covers the full run: pick the task, build a task-first outline, set up a clean recording environment, record with deliberate pacing, edit hard, caption, and ship. It is built for software tutorials and product walkthroughs, not talking-head content.

Workflow

1. Lock the task and outcome

Finish this sentence: "After this video, the viewer can ___." One verb, one outcome. If you need an "and," make two videos. A tutorial covers one task; an onboarding walkthrough chains tasks into chapters, one chapter per video.

List the 3 to 5 key moments that make up the task. Cut everything else. A tutorial that shows everything teaches nothing.

2. Build the outline

Use the storyboard template in assets/storyboard.md. For each scene record: time estimate, what is on screen, the one deliberate action, and the narration line for it. Read the whole outline aloud once. Target length: 60 seconds to 3 minutes for a task tutorial. If it runs long, cut a moment, not the pacing.

Write the opening as the outcome first: "Here is how you publish a report in under a minute." Never open by describing the menu. Transitions are one sentence each: "Now that the report is built, let's share it." They keep momentum and give the narration natural breathing room.

If several scenes share a concept, connect them with one unifying example that carries through the video. One continuous example is easier to remember than disconnected clicks.

3. Prep the environment

• Recording account with realistic demo data, no real user or customer data anywhere on screen.
• Neutral wallpaper, no personal files or photos visible. Close everything that is not part of the task.
• Notifications off: OS do-not-disturb, phone on silent, messaging apps closed. One notification pop-up can ruin a take and leak private info.
• Pre-load every file, tab, and login the task needs. Test the recorder, mic, and system-audio capture before the real take.
• Plan each click in order and write the path into the storyboard. Hunting for a button on camera reads as uncertainty.

4. Record

Show-once-say-once. Say the narration line once while doing the action once. Do not explain what you just showed in different words right after showing it. If the action is clear on screen, the narration names what changed and why. If the narration already said it, do not pause the action to show it again. Duplication doubles runtime and halves attention.

• Move the mouse slowly and deliberately. Pause a beat after each click so the viewer registers cause and effect.
• Zoom on the thing you are doing. Anything smaller than a thumbnail needs a zoom: a full-screen recording is hard to read on a laptop and worse on a phone. Zoom on each action to tell the viewer where to look; it also hides the irrelevant parts of the screen.
• When you use a keyboard shortcut, say it out loud once and show it on screen if your recorder supports a keystroke overlay. Never use an unnamed shortcut; the viewer cannot learn what they cannot see named.
• Speak a touch faster than casual conversation. The viewer has pause and rewind. Vary your tone; a flat read sounds like a terms-of-service page.
• Record system audio on its own track when the software makes meaningful sounds, so you can duck app audio under narration in the edit.
• When you stumble, pause three seconds, then redo the sentence cleanly at a normal pace. Do not restart the whole take. The pause marks a clean cut point in the edit.

5. Edit

Record loosely, cut hard. Remove every pause where nothing happens, every page load, every moment of reading rather than doing. A ninety-second tutorial that moves beats a four-minute one that is complete.

• Cut on motion; no scene lingers after its action lands. Hard cuts are the default transition. Dissolves only for time passing.
• Keep the face out of the dense middle. If you use a webcam, be present for the intro and the close, small or absent during the detailed middle where it covers the screen.
• Captions: generate them, then read every line and fix product names and terms by hand. Automatic captions misspell the exact words the tutorial depends on. Proofread captions are part of a finished tutorial, not an extra.
• End on the outcome, restated once: the thing the viewer can now do.

Output Contract

A finished tutorial delivers:

1. The video file, 60 seconds to 3 minutes for a single task.
2. The storyboard from assets/storyboard.md, filled in and matching the final cut scene for scene.
3. A proofread caption file (SRT or VTT) with correct product names.
4. A one-line update note listing which screens the video shows, so future releases know which tutorials to redo when a screen changes.

If any of these is missing, the tutorial is not finished. Say so plainly instead of shipping it half done.

Operating Rules

1. One video, one task, one outcome. Split, don't stretch.
2. Open with the outcome, never with the menu or a logo.
3. Every claim about the software is checked against the actual software before recording. Never narrate a behavior you have not verified on screen.
4. No notification, personal file, or real user data appears on screen, ever.
5. Unverifiable timing promises ("it takes ten seconds") get cut or reworded to what you actually measured.
6. Effects are minimal: zooms and callouts serve the current action. If a transition exists to look fancy, remove it.
7. Captions ship with the video. No exceptions for published tutorials.
8. If the software changed since the storyboard was written, re-verify every scene before recording. A stale storyboard produces a wrong tutorial.