show-and-tell-video-slate
GitHub将授权构建、工作流和数据分析转化为高质量创始人演示视频,通过严格的质量门禁筛选并组合成15分钟长片。用于决定拍摄内容、制作展示类商业视频及包装概念。
Trigger Scenarios
Install
npx skills add ericosiu/ai-marketing-skills --skill show-and-tell-video-slate -g -y
SKILL.md
Frontmatter
{
"name": "show-and-tell-video-slate",
"description": "Turn authorized current builds, workflows, dashboards, analytics, and completed work into proof-led founder videos, then rank and combine the strongest filmable artifacts into exact 15-minute long-form slates with strict title and thumbnail evaluation. Use when deciding what to film, creating show-and-tell business videos, combining thin topics into complete episodes, or requiring packaging concepts to clear explicit quality gates."
}
Show-and-Tell Video Slate
Turn real work into videos whose opening promise is repaid by a visible artifact, workflow, result, or before/after.
Preamble
From the repository root, run the privacy-preserving version check and telemetry initializer when available:
python3 telemetry/version_check.py 2>/dev/null || true
python3 telemetry/telemetry_init.py 2>/dev/null || true
Remote telemetry is opt-in. Never log content, URLs, paths, credentials, names, business data, or proof artifacts.
Set the scope
State the authorized sources, owner, channel, viewer, runtime, deliverable, and stop condition. Keep source systems read-only. Never search unrelated accounts, repositories, conversations, or credentials.
Ask the user to rank these outcomes when not already known:
- money created;
- money saved;
- productive capacity created.
Load any supplied creator voice guide before writing titles or hooks. Reject packages that violate it even if their numeric scores pass.
Inventory filmable evidence
Inspect only supplied or authorized builds, repositories, demos, agent runs, dashboards, analytics, and workflow outputs. For every candidate record:
- viewer and business outcome;
- visible artifact and demonstration path;
- claim status: achieved, estimate, anecdote, forecast, target, or plan;
- proof pointer, freshness, and privacy limits;
- mechanism, lesson, and viewer action;
- missing pickup, capture, redaction, or validation.
Do not upgrade remembered results into verified evidence. Label provisional candidates.
Apply the show-and-tell gate
Read references/selection-rubric.md. Reject or repair a candidate unless:
- the first 30 seconds can show a real outcome, build, screen, output, or physical artifact;
- the demonstration explains or proves the package;
- one promise can sustain 15 minutes without padding;
- the viewer receives a usable mechanism or decision;
- the ending resolves the opening promise completely.
Framework-only topics must use real case studies. Product walkthroughs must lead with the viewer outcome rather than a feature list.
Combine carefully
Combine ideas only when they share one mechanism, viewer, and payoff. Examples include sales and recruiting workflows that use the same outreach loop, multiple cost controls inside one audit system, or a demonstrated content result paired with the loop that produced it.
Do not combine unrelated proof points merely to reach the runtime. Route thin ideas to shorter formats.
Build an exact 15-minute spine
Use 900 seconds unless the user overrides it:
0:00-0:30show the outcome and promise;0:30-2:00establish the stakes and baseline;2:00-5:00show what was built;5:00-10:00demonstrate how it works;10:00-13:00show receipts, limitations, and lessons;13:00-15:00give the implementation path and close the promise.
Score and package
Use the nine episode lenses in references/selection-rubric.md. Require a 90+ average, with Demoability and Payoff Integrity each at least 90.
Create exactly three materially different packages:
- verdict or contrarian conclusion;
- specific proof or transformation;
- decision utility or implementation framework.
Require every package to score at least 9.0/10 with no dimension below 8.5. Use zero to four thumbnail words and no more than three major visual groups. Prefer the real artifact, result screen, dashboard, output, or physical prop over an abstract metaphor.
After the slate passes, use content-eval for deeper panel review, video-content-engine for the production plan, and shortform-idea-grill for complete short-form derivatives when those skills are installed. Use a compatible thumbnail-packaging skill when available. Keep achieved results distinct from plans and forecasts.
Validate
Read references/output-contract.md, save the structured slate as JSON, and run:
python3 scripts/evaluate_slate.py slate.json --output slate-eval.json
python3 scripts/evaluate_slate.py slate.json --validate-only
The validator checks runtime, artifact evidence, claim proof, episode scores, packaging lanes, thumbnail word count, component budget, and package score floors.
Deliver
Return the ranked slate, combination decisions, exact run of show, first-30-second promise, proof and pickup ledger, three packages per episode, evaluation readback, winning package, and shoot order.
Separate ready from repair. A strong package never overrides missing proof. Do not render, publish, schedule, upload, or change a live asset without explicit approval.
Lifecycle
- Tracked state: keep run evidence, slate JSON, evaluation reports, and decisions in a user-selected private runtime folder, not in the skill.
- Success test: at least one episode passes the episode and show-and-tell gates, every surfaced package passes deterministic validation, and every achieved claim has a proof pointer.
- Repeat trigger: run when choosing a recording slate, after a meaningful build ships, or when new first-party results arrive. Do not schedule by default.
- Learning writeback: store user corrections, failed proof checks, and post-publication performance evidence in the private runtime folder.
- Promotion: validate after one real build produces a passing slate and a complete recording. Treat as production-ready after three useful slates and at least two measured content readbacks.
- Retirement: archive if three consecutive runs add no differentiated ready episode or another workflow absorbs the complete process.
Version History
- 2eb0f34 Current 2026-08-20 00:20


