--- name: "corporate_training_video" description: "Plan, script, structure, assess, and maintain corporate training videos. Use when building employee training videos, compliance or onboarding modules, policy explainers, or SOP videos — covers learning-objectives-first design, Bloom's taxonomy verb selection, skimmable chapter markers, quiz checkpoints with teaching feedback, and version control for policy updates." --- # Corporate Training Video ## Purpose Turn a policy, SOP, or skill into a training video that employees actually finish and remember. Training videos fail when they are filmed before they are designed, when they are too long to skim, when nothing checks understanding, or when the policy changes and the video rots. This skill covers the full lifecycle: objectives first, skimmable structure, quiz checkpoints, and governance for updates. ## Workflow ### 1. Objectives first: write them before anything else No script, no recording, until each module has written learning objectives. Templates and verb tables live in `references/learning_objectives.md`. - One module = one to three objectives, each observable: the learner will *do* something you can see or test afterward ("identify three workplace hazards", not "understand safety"). - Pick verbs from Bloom's taxonomy matched to the goal (define/list for recall, demonstrate/solve for application, design/develop for creation), and match the video format to the level: explainer or talking head for remember/understand, screen recording or live demo for apply, scenarios and case studies for analyze/evaluate, expert interviews or project walkthroughs for create. - Open the video by stating what the viewer will learn and why it matters to their role. If the opening is company policy talking at them, attention is gone in a minute. - Tie every visual to the objective: a memo-writing module needs on-screen text; an emotional-intelligence module needs faces and acted scenarios. No decorative footage that serves no objective. ### 2. Structure for skimming: chapter markers Busy employees scrub training videos. Design for it. - Break the topic into modules of 3-7 minutes each. A 45-minute monolith gets re-watched at zero percent; twelve modules get re-watched as reference. - After picture lock, derive chapter boundaries from real topic shifts in the transcript: read in 60-120 second windows, mark at most one chapter start per window, label each in 3-6 plain words. Aim for 5-15 chapters. - YouTube chapter rules (verified against YouTube's own chapter docs, 2026): the first timestamp must be exactly `0:00`, you need at least three timestamps, and every chapter must be at least 10 seconds long. Put the block in the video description or the platform's chapter UI, never in the caption track. - Validate the block with `bin/check_chapters.py ` before publishing. If you trim the video after writing chapters, rewrite the timestamps — a middle cut makes the whole list wrong. - Use `assets/version-changelog.csv` as the per-video change log; version number and date go in the file name so the current version is always obvious. ### 3. Quiz checkpoints: check understanding, not patience Every module gets a checkpoint. Quizzes are formative — they teach, they don't just grade. - Place one checkpoint per module, right after the concept is taught, plus one summative check at the end. Keep each checkpoint short: 10-15 questions max, mixed difficulty. - Write questions tied to real on-the-job decisions, not recall trivia. "Which would you do first when the customer does X?" beats "Which statement is true?" every time. Full templates in `references/quiz_checkpoints.md`. - Every answer gets feedback that re-teaches: explain why the right answer is right and why each wrong answer is wrong. "Correct" / "Try again" teaches nothing. - End with a confidence rating ("How sure are you?") and one reflection prompt ("How will you apply this in your work this week?"). If nearly everyone misses a question, the teaching is the problem — fix the video, not the learners. - Accessibility is baseline: captions, transcripts, WCAG 2.1 AA player. A compliance quiz nobody with a screen reader can complete is a legal exposure, not a training win. ### 4. Version control: design for the policy change Policies change. Plan for that on day one, or the video rots. - The written policy or SOP is the source of truth, not the video. Give every SOP an ID and version number, and link each video module to the SOP version it teaches. - When the policy changes: update the SOP document first, regenerate or re-record only the affected module, review the new video against the updated SOP, then publish the new version and archive the old one. Never re-record the whole course for one changed segment. - Log every change in `assets/version-changelog.csv` (version, date, author, what changed, why). Retire outdated versions so employees can't find them; assign updates only to the roles the change affects. - Name an owner for each video. No owner = no updates = rot. The single most important maintenance metric is time from policy change to published update — track it. - For regulated topics, the delivery layer must export SCORM/xAPI, track completion with pass/fail, and keep a timestamped audit trail of who completed what, when. Retire an outdated module without breaking existing completion records. ## Output Contract Each production delivers: written learning objectives per module (verbs from Bloom's), the spoken script, the edited video, a validated chapter block, a quiz checkpoint per module plus an end-of-video check (each answer with teaching feedback), and a version changelog entry. Nothing is "done" until the chapters validate, the quiz answers all re-teach, and the changelog names the SOP version taught. ## Operating Rules 1. **Objectives before scripts, scripts before cameras.** A filmed-first training video is a lecture with better lighting. 2. **One module, one job, one skill to do.** If a module teaches three things, it is three modules. 3. **Design for the scrubber.** Employees re-find, not re-watch. Chapters are the feature, not a nicety. 4. **Every wrong answer is data.** Feedback re-teaches; a missed-by-everyone question flags broken teaching. 5. **The SOP is truth; the video is an asset.** When they drift, the asset gets rebuilt from the document, not the other way around. 6. **Never ship an unvalidated chapter block.** Run `bin/check_chapters.py` before publishing. 7. **No confident claims about rules you haven't checked.** Platform chapter rules, SCORM requirements, accessibility standards — verify each release cycle or leave them out.