Packaging Youtube Thumbnails

Packaging YouTube Thumbnails

Overview

Turn new content into differentiated packages using a saved channel profile and evidence-backed performance memory. Keep identity, episode packaging, and performance learning separate.

REQUIRED SUB-SKILL: Use imagegen for raster generation or editing when available. Otherwise return production-ready briefs and state the rendering blocker.

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, channel analytics, or source assets.

Resolve <skill-root> as the installed directory that contains this SKILL.md. Use that absolute directory for every bundled helper and reference. Never assume the current working directory is the skill directory.

Mode Gate

Default mode: production

Resolve the profile in order:

1. a user-supplied path;
2. the current project's channel profile.

If neither profile exists, switch to identity bootstrap. This public package does not bundle a creator profile, likeness, channel analytics, or approved brand assets.

When a usable profile resolves:

• Validate it with python3 <skill-root>/scripts/thumbnail_guard.py profile --profile <profile-path>. Missing output roots or approved reference paths make the profile unusable; repair or bootstrap it instead of improvising.
• Load it before developing hooks.
• Load any user-reviewed co-design calibration and approved winning references before proposing titles or visual directions.
• Do not re-audit the channel, browse its Videos grid, or rewrite the profile.
• Use its identity rules, approved references, output root, and avoid list.
• Treat the new transcript, recording, notes, brief, links, and user additions as one source pack. Latest explicit user instructions win.
• Read references/performance-learning.md. If the profile output root contains performance state, generate its preflight brief; missing state never blocks a first run.

Identity bootstrap or refresh

Audit the channel only when:

1. no usable profile exists;
2. the user explicitly requests a refresh; or
3. the user supplies new brand examples and asks to replace or update the saved rules.

Inspect roughly 20 recent long-form thumbnails, then save or update a profile using references/channel-profile-template.md. Do not refresh merely because time has passed.

Production Workflow

0. Apply co-design calibration

When the user identifies a prior package as successful, preferred, or co-designed, inspect it before developing new hooks. Extract five things: the promise pattern, title pattern, visual grammar, rejected tendencies, and which elements must repeat versus vary.

If an approved reference is a platform screenshot, distinguish the creative from platform chrome. Crop to the creative when practical and explicitly exclude progress bars, duration badges, player controls, surrounding titles, metrics, and other interface overlays from generation prompts.

Keep the evidence classes separate:

• A direct correction, approval, or statement of preference is identity and workflow evidence. Apply it immediately to the current run.
• Public views or an isolated result are directional performance context, not causal proof.
• Studio readbacks and repeated comparable results belong in the performance ledger.

When the user explicitly asks to remember the lesson or update the skill, persist the durable preference in the active channel profile or a linked calibration reference. Save the approved visual reference with the profile, increment the profile version and review date, and state the evidence class. On later runs, start from that calibration instead of making the user rediscover it. Preserve distinct promise lanes; do not copy a podium, trophy, comparison, or other visual device when the new episode has no matching status relationship.

1. Read the source pack

Read all supplied content. Extract the viewer, thesis, verdict, proof, tension, stakes, consequence, and caveats. Exclude incomplete tests from claims. Verify product/model spelling. Assign concise topic tags and a comparison group for performance retrieval.

For roundups, workflow collections, tool lists, and how I use it episodes, run a count-and-spike audit before writing titles:

• Count every named item, then count only items with enough explanation or proof to support the promise. Use the substantive count in numeric titles and thumbnail copy.
• Identify timestamped content spikes such as achieved numbers, concrete outputs, strong opinions, mistakes, insider information, or unusually sharp lines.
• Let the substantive inventory and strongest two or three spikes determine whether the package should lead with a list, personal proof, outcome, verdict, or framework.

For show-and-tell episodes, identify the exact artifact, native result readback, screen, physical prop, or before/after that proves the promise. Prefer it as the dominant object. Do not replace available first-party proof with an abstract AI metaphor.

For future-of-work, framework, and trend-adjacent episodes, run a practical-value check before packaging. State what the viewer can build, change, decide, or do differently after watching. Keep that useful outcome as the title's main promise when the transcript supports it; use identity tension, urgency, or a trending product to sharpen the package rather than replace the takeaway.

Treat a current product or cultural moment as a trend only after verifying a recent launch, expansion, or sustained attention. When the episode contains a real use or demonstration, the product may become the thumbnail's concrete proof object even if the title stays broader. Put the product in the title only when the opening and a substantial share of the episode deliver a product-centered promise. Otherwise protect against trend-click and retention mismatch.

2. Load performance evidence

Generate a brief from <output-root>/_performance/ when a ledger exists. Use comparable packages, their numeric Studio snapshots, recent repetition, and approved lessons as evidence—not immutable identity rules. Surface a 72-hour subject collision before proposing packages. Let observed results influence the hypotheses and risks, but never infer causality from raw public views or fewer than three comparable Studio readbacks.

3. Create the requested packages

Read references/packaging-rubric.md. Use distinct lanes:

1. Verdict or contrarian tension.
2. Specific proof, outcome, or transformation.
3. Decision utility, framework, or real-work test.

Create the user's requested number of packages; default to three only when no count is given. Keep set IDs and their headline-thumbnail pairings stable through revision rounds. For each, provide the exact title, thumbnail copy, composition, component inventory, hook logic, and risk. Make the options materially different promise hypotheses, not cosmetic treatments. Prefer zero to four thumbnail words. Score every package, recommend one, and render immediately when requested.

When the source contains real creator usage, favor personal proof over abstract category language when the active channel calibration supports it. A concrete count, named product, real job or outcome, and explicit utility such as a setup or workflow to copy usually form a stronger list-package hypothesis than a generic AI workforce or trend summary. Do not force this shape when the source lacks the count or first-party use.

When a practical promise and a career-identity promise are both supported, keep them as distinct test lanes. A playbook or traits title should promise usable guidance; identity tension may supply the stakes in the thumbnail instead of displacing the utility from every candidate.

When an upstream brief requires a stricter score, honor it. For show-and-tell-video-slate, require 9.0+ overall with no dimension below 8.5; a numerical package remains conditional until its proof pointer is available.

Apply the rubric's simplicity and semantic-clarity gates before scoring. Do not render a candidate that exceeds its component budget or depends on unfamiliar, unexplained symbols.

4. Verify visible brands

Resolve the exact app or product mark before rendering. Check user-supplied files and installed first-party app resources before falling back to official model pages, launch pages, or brand kits. Distinguish an app icon from its parent-company logo, product-family mark, campaign art, mascot, and wordmark. Classify each mark, pass the verified file as a labeled input, and record its source, local path, and classification in the manifest. If the user corrects a mark, treat that correction as a hard constraint and recheck every affected current variant.