From alemtuzlak-skills
Use when the user wants to write a video script for a product demo, feature walkthrough, launch video, or social media video about a feature or product change
npx claudepluginhub alemtuzlak/skills --plugin alemtuzlak-skillsThis skill uses the workspace's default tool permissions.
Write video scripts for product demos, feature walkthroughs, and launch videos. Handles pacing, visual directions, timing, and platform-appropriate lengths.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Analyzes competition with Porter's Five Forces, Blue Ocean Strategy, and positioning maps to identify differentiation opportunities and market positioning for startups and pitches.
Share bugs, ideas, or general feedback.
Write video scripts for product demos, feature walkthroughs, and launch videos. Handles pacing, visual directions, timing, and platform-appropriate lengths.
Resolve the argument (if provided) in this order:
.md containing "Executive Summary" or "Key Messages") -> marketing brief.md with blog post structure) -> blog post#\d+ pattern -> PR... or .. -> git ref rangeIf no argument is provided, ask: "What should the video be about? You can provide a marketing brief, blog post, changelog, PR URL/number, git ref range, file/directory path, or just describe the feature."
If multiple interpretations match, confirm with the user.
digraph video_script {
rankdir=TB;
"Resolve input" [shape=box];
"Phase 1: Discovery" [shape=box];
"Phase 2: Configure" [shape=box];
"Phase 3: Outline" [shape=box];
"Outline approved?" [shape=diamond];
"Phase 4: Write" [shape=box];
"Phase 5: Review" [shape=box];
"Approved?" [shape=diamond];
"Phase 6: Output" [shape=box];
"Resolve input" -> "Phase 1: Discovery";
"Phase 1: Discovery" -> "Phase 2: Configure";
"Phase 2: Configure" -> "Phase 3: Outline";
"Phase 3: Outline" -> "Outline approved?";
"Outline approved?" -> "Phase 3: Outline" [label="no, revise"];
"Outline approved?" -> "Phase 4: Write" [label="yes"];
"Phase 4: Write" -> "Phase 5: Review";
"Phase 5: Review" -> "Approved?";
"Approved?" -> "Phase 4: Write" [label="revisions"];
"Approved?" -> "Phase 6: Output" [label="yes"];
}
Do NOT skip phases. Ask questions at a natural pace. If the user answers multiple at once, accept bundled answers and skip ahead.
If the user says "just pick defaults" or similar, pick reasonable defaults, state what you chose, and ask for a single confirmation.
| Input type | What to read |
|---|---|
| Marketing brief | Extract problem statement, value prop, audience, key messages. Skip to Step 3. Still do Step 2 if brief lacks product context. |
| Blog post | Extract headline, key points, audience, CTA. Skip to Step 3. |
| Changelog | Extract key entries, focus on the most impactful changes. Skip to Step 3. |
| Newsletter | Extract subject, key updates, CTA. Skip to Step 3. |
| PR | Diff, PR description, review comments, commit messages. For large PRs (20+ files), focus on user-facing changes. |
| Git refs | git diff and git log between refs. Prioritize user-facing changes. |
| Codebase feature | Read the specified files/directories. |
| Freeform text | Parse the user's description. If it lacks specifics, ask the user to provide more detail or point to a specific file/PR. |
User-facing changes include: new features, UI changes, API changes, performance improvements, bug fixes, and documentation updates. Internal changes include: refactors, test additions, CI changes, and dependency bumps.
Error handling:
gh not available -> inform user, offer alternative inputRead if they exist: README, docs/, package.json (or equivalent).
If nothing found, ask: "Can you briefly describe the product and who it's for?"
"Here's what I'll base the video script on:"
- Feature A - short description
- Feature B - short description
"Anything to add, remove, or correct?"
Do NOT proceed until the user confirms scope.
Before proceeding, scan for potentially sensitive content: security patches, internal pricing, credentials, unreleased roadmap items, or content marked confidential. Flag anything questionable to the user.
Ask these questions:
Q1 - Video length:
Q2 - Script type:
Q3 - Tone: Read existing repo content to detect voice. Confirm:
"Based on your existing content, the tone seems [e.g. conversational and developer-friendly]. Should I match that or go a different direction?"
If no content to analyze, ask directly.
Q4 - CTA: Infer from context:
"I'd suggest the CTA be: [inferred CTA]. Want to go with that or something different?"
Generate a structured outline with timing. Use the appropriate template based on video length:
Short-form (30-90 seconds) - 3-4 sections:
## [Working title] - [total duration]
1. **Hook** (0:00-0:05) - [approach]
- Key point
- Visual: [what to show]
2. **Problem** (0:05-0:15) - [pain point to establish]
- Visual: [what to show]
3. **Solution** (0:15-0:45) - [feature walkthrough]
- Key point A
- Visual: [what to show]
- Key point B
- Visual: [what to show]
4. **CTA** (0:45-0:60) - [action to take]
- Visual: [end screen]
Estimated total: ~X words (~Y seconds at 135 WPM)
Medium-form (3-5 minutes) - 5-8 sections:
## [Working title] - [total duration]
1. **Hook** (0:00-0:10) - [approach]
- Visual: [what to show]
2. **Problem** (0:10-0:30) - [pain point, context, why this matters]
- Visual: [what to show]
3. **Solution overview** (0:30-1:00) - [high-level what you built]
- Visual: [what to show]
4. **Deep-dive: [Feature A]** (1:00-2:00) - [walkthrough]
- Key points
- Visual: [screen recording steps]
5. **Deep-dive: [Feature B]** (2:00-3:00) - [walkthrough]
- Key points
- Visual: [screen recording steps]
6. **Deep-dive: [Feature C]** (3:00-3:45) - [walkthrough]
- Key points
- Visual: [screen recording steps]
7. **Recap** (3:45-4:30) - [summarize key benefits]
- Visual: [summary slide or side-by-side]
8. **CTA** (4:30-5:00) - [action to take]
- Visual: [end screen]
Estimated total: ~X words (~Y seconds at 135 WPM)
Scale the number of deep-dive segments to match the features being covered.
Present the outline and wait for approval before writing.
| Video length | Target words | WPM |
|---|---|---|
| 30 seconds | ~65 words | 130 |
| 60 seconds | ~135 words | 135 |
| 90 seconds | ~200 words | 135 |
| 3 minutes | ~400 words | 135 |
| 5 minutes | ~675 words | 135 |
Target 130-145 WPM for conversational delivery. Flag any section that runs over its allocated time.
Voiceover script:
## [Title]
### Hook (0:00-0:05) - ~15 words
VISUAL: [Description of what's on screen]
[Narration text here.]
### Section Name (0:05-0:20) - ~30 words
VISUAL: [Description of what's on screen]
[Narration text here.]
Two-column script:
| Time | Visual | Narration |
|---|---|---|
| 0:00-0:05 | [Screen: landing page loads] | [Narration text] |
| 0:05-0:15 | [Screen: click settings menu] | [Narration text] |
| 0:15-0:30 | [Screen: toggle dark mode] | [Narration text] |
Talking-head script:
## [Title]
### Hook (0:00-0:05) - ~15 words
CAMERA: [Speaker on camera, medium shot]
[Speaker text here. Conversational, direct to camera.]
### Section Name (0:05-0:20) - ~30 words
CAMERA: [Cut to screen recording]
VOICEOVER: [Narration over screen recording]
CAMERA: [Back to speaker]
[Speaker text here.]
The first 3-5 seconds determine whether viewers keep watching. The hook must:
Always include visual directions inline, regardless of script type:
VISUAL: / SCREEN: for screen recordings and footageCAMERA: for talking-head camera directionsInclude estimated duration and word count for every section:
### Section Name (0:15-0:30) - ~30 wordsPresent the complete script with timing breakdown:
"Here's the script:"
[Full script]
Timing breakdown:
- Hook: 5s (~15 words)
- Problem: 10s (~25 words)
- Solution: 30s (~70 words)
- CTA: 10s (~20 words)
- Total: 55s (~130 words at 135 WPM)
"Want any changes?"
Wait for approval. Only proceed to output once the user confirms.
Always print the final approved script to terminal.
Then ask: "Want me to save this to scripts/<slug>.md? Or a different path?"
Create the directory if it doesn't exist. If file already exists, ask whether to overwrite or create a versioned copy.
gh not available -> inform user, offer alternative input/blog-post or /social-copy)