# Absorbed skill: social-media-shorts-growth-engine

---
name: social-media-shorts-growth-engine
description: Design and operate a growth-oriented short-form video engine for YouTube Shorts, TikTok, Instagram Reels, and adjacent channels, with human approval before posting.
version: 1.0.0
tags: [shorts, tiktok, youtube-shorts, reels, content-strategy, growth, monetization, approval-workflow]
---

# Social-Media Shorts Growth Engine

Use this skill when the user wants to build, improve, or operate an automated/semi-automated system for short-form social media content: YouTube Shorts, TikTok, Instagram Reels, Facebook Reels, Pinterest, LinkedIn video, or similar.

## Core principle

Do **not** treat the task as “make videos.” Treat it as a **growth engine**:

1. Generate many sharply positioned ideas.
2. Score hooks and scripts before rendering.
3. Produce previews.
4. Send the user a review package.
5. Post only after explicit approval.
6. Capture analytics.
7. Feed performance back into the next batch.

A technically correct content generator that produces generic content is failure with extra rendering time. Charming, but still failure.

### JARVIS-operated / human-approved default

For the user's AutoShorts/Retention-Studio direction, assume the machine is **operated and maintained by JARVIS/Hermes**. The user should not manually run the pipeline day-to-day; the user is responsible for explicit approval before posting and occasional strategic steering.

Operational consequences:

- JARVIS owns ideation, queueing, scoring, preview generation, quality gates, metadata generation, analytics review, maintenance, and experiment planning.
- Phase 1: the user manually uploads approved final videos to YouTube/TikTok; JARVIS provides the video file path plus platform-specific titles, descriptions/captions, hashtags, tags, and copy instructions.
- Phase 1 must not call platform APIs, upload, schedule, or post. The posting pack is a side-effect-free manual handoff.
- Later automation phases may upload/post only after explicit approval for the exact package/version.
- The user approves or rejects exact preview packages before any upload/posting boundary.
- Daily video volume is a configurable policy to decide later, not a renderer/platform-adapter constant.
- Never treat vague consent as approval. Approval must target the exact preview package/version.
- Build automation around strategy gates and analytics learning before scaling volume.

## Recommended workflow

### 1. Define content pillars

Start with 2–4 pillars, not a vague infinite topic pool. For each pillar define:

- audience
- positioning
- tone
- hook patterns
- visual rules
- no-go topics
- platform fit
- monetization angle

Example pillar structure:

```json
{
  "pillar": "ai_life_systems",
  "positioning": "AI as a servant for ordinary life systems, never as values or authority.",
  "tone": ["clear", "useful", "values-first", "non-hype"],
  "hook_patterns": ["AI is a bad god, but a good servant."],
  "visual_rules": ["screen-recording friendly", "human remains in control"],
  "no_go": ["fake earnings", "overpromising automation"]
}
```

### 2. Build a testbatch before building a full automation platform

For a new channel or unvalidated strategy, create a small batch first:

- 3 ideas per pillar
- 6 short growth candidates, usually 20–45 seconds
- 1–3 monetization-length candidates, usually 60+ seconds where the platform rewards length
- one clear hypothesis per idea

Each idea should include:

- id
- pillar
- title
- platform target
- duration
- hook
- script outline
- visual concept
- caption
- CTA
- quality score
- risk/policy notes

### 3. Add a script quality gate

Before rendering, score each draft for:

- hook strength in the first 1–2 seconds
- novelty / non-generic angle
- emotional pull
- clarity
- retention risk
- comment/share potential
- AI-slop risk
- policy/copyright risk

Render only drafts above the threshold, e.g. 8/10.

### 4. Use a human approval loop

Default to semi-automatic operation first. Send a Telegram review package with:

- preview video or script draft
- pillar and format
- title
- duration
- hook
- caption
- hashtags
- quality score
- policy notes
- suggested platforms

Recommended approval commands:

- `Freigabe alle`
- `Freigabe YouTube`
- `Freigabe TikTok`
- `Freigabe Instagram`
- `Ablehnen`
- `Ändern: <requested change>`

If approval is ambiguous, do not post. Ask once in the project topic.

### 4b. Phase-1 manual posting pack

For the user's current TrueTraceShorts phase, do not automate platform posting yet. After approval and final render, prepare a manual posting pack instead:

- final video file path;
- YouTube title;
- YouTube description;
- YouTube hashtags;
- YouTube tags/keywords;
- TikTok caption;
- TikTok hashtags;
- platform-specific copy/paste instructions;
- explicit note that no platform upload was performed.

The pack must be side-effect-free: no platform API calls, no upload, no scheduling, no posting, no external calls. The user's phase-1 workload is manually uploading the approved file and copying the prepared metadata.

### 5. Keep platform strategy separate from rendering

Rendering code should not hardcode content strategy. Keep separate config files for:

- niches/pillars
- platforms
- script formats
- visual styles
- approval workflow
- analytics schema

This lets the same renderer support different formats and prevents prompt spaghetti. Prompt spaghetti is still spaghetti even if it is wearing a YAML hat.

## Platform notes

### YouTube Shorts

- Shorts can be vertical or square and up to 3 minutes long.
- YouTube Partner Program Shorts route typically requires 1,000 subscribers and 10M valid public Shorts views in the last 90 days.
- Alternative longform YPP route: 1,000 subscribers and 4,000 valid public watch hours in the last 12 months.
- Shorts views in the Shorts feed do not count toward the 4,000 longform watch hours.
- Practical early growth tests often work best at 20–45 seconds; longer Shorts need a strong story or payoff.

### TikTok

- Creator Rewards availability depends on country/account eligibility.
- TikTok Creator Rewards generally requires a non-business account in good standing, 10,000 followers, and 100,000 authentic views in the last 30 days before joining, subject to country availability and current terms.
- Reward-eligible videos generally need to be at least 1 minute long and meet quality/originality criteria.
- This creates a strategy split:
  - 20–45s for growth and format discovery.
  - 60–75s for monetization candidates once a format works.

### Instagram / Facebook Reels

Useful for republishing 9:16 assets and testing share/save behavior. Treat direct payout as volatile; prefer indirect monetization through audience, affiliate, newsletter, or products.

### LinkedIn / X / Pinterest

Use selectively:

- LinkedIn: AI/productivity/workflows.
- X: AI demos, build-in-public, technical positioning.
- Pinterest: evergreen checklists, routines, faith/life prompts.

## Repository scaffold

A clean shorts-engine repo can start as:

```text
AutoShortsBot/
  autoshorts/
    config/
    ideas/
    scripting/
    rendering/
    review/
    publishing/
    analytics/
  configs/
    niches/
    platforms/
  data/
    drafts/
    performance/
  scripts/
  tests/
  README.md
  .gitignore
  pyproject.toml
```

Never commit:

- `.env`
- OAuth tokens
- API keys
- generated credentials
- rendered videos or large media outputs unless explicitly intended
- raw analytics exports with sensitive account data

## Implementation quality

When coding the engine, prefer TDD for deterministic parts:

- structured video candidate validation
- testbatch validation and duplicate-id checks
- renderable-candidate filtering before any renderer runs
- candidate factory conversion from raw drafts to validated `VideoCandidate` objects
- duration classification
- stable candidate-id generation and default hashtag derivation
- review formatting
- analytics import
- approval command parsing
- platform metadata generation
- script quality gates

A strong first implementation path is deterministic gating before any renderer exists:

1. Add structured `VideoCandidate` and `TestBatch` models before rendering code. Require candidate id, pillar, title, platforms, duration, hook, script outline, visual concept, caption, CTA, hashtags, quality score, policy notes, and one clear hypothesis.
2. Validate candidates and batches: reject missing strategic fields, unsupported platforms, out-of-range durations, empty batches, and duplicate candidate ids.
3. Add a `ContentPillar` registry and validate candidate pillar/platform fit before review or rendering.
4. Add a deterministic candidate factory: `CandidateDraft → create_candidate() → VideoCandidate`. It should generate stable ids, derive default hashtags, classify duration (`growth_short`, `monetization_candidate`, `experiment`), append the duration class to policy notes, require a hypothesis, and enforce both candidate and pillar-fit validation.
5. Add an approval parser that accepts only explicit commands such as `Freigabe alle`, `Freigabe YouTube`, `Freigabe TikTok`, `Freigabe Instagram`, `Ablehnen`, and `Ändern: <requested change>`.
6. Treat vague consent like `passt schon` as `needs_clarification`; never publish on ambiguous approval.
7. Add a conservative script quality gate before rendering, e.g. average hook/novelty/clarity/retention ≥ 8, AI-slop risk below threshold, and no high policy risk.
8. Add a Telegram review package renderer that surfaces the candidate, gate status, policy notes, preview path, and only relevant platform approval commands.
9. Test these deterministic pieces first with RED-GREEN-REFACTOR before adding renderers, image generation, video generation, or publishing APIs.

Rendering and external API calls can be integration-tested separately.

For this AutoShortsBot/Retention-Studio workflow, prefer a free-first renderer path before any paid video provider: `free_production_jobs → local_motion_renderer → FFmpeg MP4`. The local renderer should use Pillow/FFmpeg procedural motion, mechanism layers, kinetic captions, and generated metadata; preserve exact scene durations from render manifests, exclude text-only LLM refinement jobs from rendering, and keep generated local renders out of git (`data/local_motion_renders/`). NVIDIA/build.nvidia.com LLMs are optional text-refinement helpers only, not video generation.

When Hermes has the `openai-codex` image-generation backend available, GPT Image 2 is a good cloud-side keyframe/thumbnail/concept generator for the pipeline: `script idea → GPT Image 2 keyframe → human review → Wan/ComfyUI I2V or local renderer → deterministic captions/overlays`. Because GPT Image 2 runs cloud-side, it does not compete with local/remote GPU VRAM used by Wan/ComfyUI video jobs. Use low/medium for iteration and high for final keyframes; still add captions, labels, numbers, UI text, and audit-sensitive facts later in the deterministic renderer rather than trusting baked image text.

If the user wants more realistic footage without spending money, first check whether a local GPU/ComfyUI host is available. Preferred path when reachable: `scene spec → ComfyUI/Wan API over Tailscale → imported_ai_clips/<video_id>/scene_XX.mp4 → local captions/mechanism layers/FFmpeg assembly`. For a 16 GB A5000 Laptop GPU, use the `comfyui` skill reference `wan-video-tailscale-a5000.md`: Wan2.1 T2V 1.3B FP8, `--lowvram`, CPU text encoding, VAE tiling, and a small smoke-test ladder before quality probes. If no local GPU path is available or quality is insufficient, use the hybrid free-tier handoff rather than pretending local procedural graphics are realistic: `free_production_jobs → free_ai_video_handoff → manual browser generation in free-tier tools (PixVerse/Pika/CapCut/Hailuo only with existing free credits) → import clips under data/imported_ai_clips/ → local captions/mechanism layers/FFmpeg assembly`. Guardrails: no paid top-ups, no subscriptions, avoid Pro templates, no baked captions/logos/watermarks where possible, and keep imported clips out of git.

For this AutoShortsBot/Retention-Studio workflow, prefer a free-first renderer path before any paid video provider: `free_production_jobs → local_motion_renderer → FFmpeg MP4`. The local renderer should produce moving mechanism/caption previews, not final static cards. When the user has a capable local/remote GPU (e.g. RTX A5000 16 GB via Tailscale), promote the path to `ComfyUI/Wan or LTX local clip generation → imported_ai_clips → hybrid local renderer → FFmpeg`, with free web providers (PixVerse/Pika/CapCut) only as fallback. External free-tier AI video tools can still be used manually for realistic b-roll, but keep paid top-ups/subscriptions disabled and store downloaded clips under `data/imported_ai_clips/<video_id>/scene_XX.mp4`. Generate provider handoff packets for manual browser generation and imported-clip assembly plans so missing clips fall back to local placeholders.

## JARVIS-operated content machine businessplan

When the user asks how the content machine should operate as a business/process, frame it as a **JARVIS-operated, human-approved growth engine**. JARVIS owns ideation, scoring, scripting, preview generation, post metadata, queue maintenance, analytics review, and implementation upkeep. The user should only need to set high-level strategy occasionally and give explicit approval before posting.

For the current TrueTraceShorts setup, phase 1 is manual posting: JARVIS prepares the final video and the complete YouTube/TikTok metadata pack; the user manually uploads/copies it. Later automation may be designed, but only behind the same exact-version approval boundary. TrueTraceShorts should keep its name/handles for phase 1 but reposition around `Systems over prompts.` and mechanism-reveal AI workflow content; see `references/truetrace-branding-manual-posting.md` for the concrete channel description, TikTok bio, manual posting pack shape, and implemented module/API names.

Always describe the pipeline from idea to post with the approval boundary visible:

```text
Research -> Idea -> Strategy Score -> Script -> Quality Gate -> Preview -> Social Draft -> Approval Package -> Human Approval -> Final Render -> Manual Posting Pack -> User Manual Upload -> Analytics -> Next Batch
```

The plan should cover descriptions/captions, hashtags/tags, platform metadata, daily volume policy, branding, and what input is still needed from the user. See `references/jarvis-content-machine-businessplan.md` and `references/truetrace-branding-manual-posting.md` for condensed operating notes.

## Strategy gates for follower conversion

When designing or scoring candidates, optimize for the full viewer path:

1. **Stop:** first 1–3 seconds create novelty, contradiction, visual anomaly, or a specific curiosity gap.
2. **Stay:** every 3–5 seconds opens or resolves a clear loop; fast cuts alone are not retention.
3. **Feel:** the candidate targets a concrete emotion such as relief, awe, frustration, identity pride, or amusement.
4. **Trust:** the video contains specificity, proof, tradeoffs, source-backed examples, or transparent reasoning.
5. **Follow:** the viewer can predict what future value this account will provide and why this worldview is distinct.

Prefer fields/gates such as `hook_type`, `first_2_seconds`, `curiosity_gap`, `viewer_identity`, `target_emotion`, `share_reason`, `future_value_promise`, and `follow_reason` before rendering.

Use **variety inside a stable promise**, not random topic hopping:

- 70% proven repeatable formats
- 20% controlled variations
- 10% experiments

Stable: worldview, tone, visual grammar, quality standard, and audience promise. Vary: hook type, payoff type, emotional lane, examples, format family, and visual layer.

Good initial public-safe series families for this user's JARVIS-operated content machine:

- `AI System Autopsy` — problem → cause → system fix → result.
- `Prompt vs System` — fragile prompt hack vs repeatable system.
- `One Rule, One Example` — one principle demonstrated with one concrete use case.
- `AI Hype Court` — claim → evidence → verdict → better action.

Do **not** assume AI-workflow content will work just because AI is popular. The user explicitly challenged this: the space is saturated, and generic AI tips are weak. Before rendering at scale, create a concrete 5-concept testbatch with hooks, outlines, visual mechanism plans, YouTube/TikTok metadata, and hypotheses so the user can judge whether the direction is actually promising. Treat the first batch as an experiment; if retention/follows are weak, pivot instead of defending the niche.

After the user accepts a direction, make the next proof tangible: select the strongest 3 concepts and build local MP4 timing previews plus approval/manual-upload packages. Keep this as a side-effect-separated preview pipeline, e.g. `Candidate -> ScriptDraft -> ShotPlan -> RenderManifest -> LocalPreviewPlan -> PNG scene cards -> FFmpeg MP4 timing preview -> SocialMediaDraft -> ContentPreviewApprovalPackage -> ManualPostingPack`. Resolve preview output directories to absolute paths before creating FFmpeg concat plans to avoid relative-path duplication inside concat-file rendering. See `references/shorts-subtitles-tts-preview-packages.md`.

Hard no-go for public content: never make videos about JARVIS/Hermes, the user, their collaboration, private/behind-the-scenes material, politics, legally sensitive loopholes, rule-bypassing, private-data misuse, morally objectionable exploitation, or anything that could enable lawbreaking. JARVIS operation is an internal production model, not a public content angle.

## Pitfalls

- **Generic advice content:** “4 tips to be healthier/productive” is usually too weak unless the hook, identity, or story is sharp.
- **Generic AI tips positioning:** if a video could belong to any AI tips account, penalize it. Protect the differentiator: systems over prompts, transparent constraints, mechanism-first visuals, and safe public artifacts. Do not turn JARVIS/the user/the collaboration into public content.
- **Premature niche confidence:** when the user questions whether AI content is saturated, do not reassure vaguely. Produce concrete test concepts and hypotheses, then propose a small preview batch and analytics-based pivot criteria.
- **AI-image slop:** avoid generated images containing fake UI text, gibberish signs, distorted hands/faces, or abstract generic graphs. These damage trust fast.
- **Too much automation too soon:** validate scripts and formats before building posting APIs.
- **No analytics loop:** producing content without tracking retention, likes, shares, comments, and follows is blind output.
- **Format fatigue:** repetition creates familiarity, but identical hook/payoff/visual patterns across consecutive videos become template spam. Track recent similarity before scaling daily volume.
- **Mixed language drift:** decide language per channel or per pillar before rendering. Mixed English/German drafts are fine for ideation, not final voiceover unless intentional.
- **Baked caption text:** do not rely on AI-generated images/videos for subtitles, labels, UI text, or facts. Use renderer-owned captions/overlays so errors remain editable and brand-safe.
- **GPU contention from local TTS:** for early Shorts production, prefer non-GPU TTS such as EdgeTTS for the baseline while the GPU is needed for ComfyUI/Wan/Qwen image/video work. Treat NVIDIA Magpie or local TTS as A/B candidates, not defaults, until voice quality, cost, and operational reliability are proven.
- **Whisper confusion:** Whisper is STT/alignment/QA, not TTS. Use it later to verify spoken audio and subtitle timing; do not select it as the voice-generation model.

## References

- `references/autoshortsbot-case-study.md` — case-study details from the AutoShortsBot setup: first testbatch shape, repo scaffold, and approval loop.
- `references/approval-first-bot-foundation.md` — implementation pattern for the first safe bot slice: explicit approval parser, quality gate, Telegram review package, and TDD test shape.
- `references/idea-candidate-testbatch-foundation.md` — deterministic `VideoCandidate`/`TestBatch` foundation before rendering: validation rules, renderable filtering, and test shape.
- `references/content-pillar-registry-foundation.md` — strategic `ContentPillar` registry pattern: default `ai_life_systems`, pillar/candidate fit validation, and TDD test shape.
- `references/candidate-factory-foundation.md` — deterministic `CandidateDraft → create_candidate() → VideoCandidate` layer: stable ids, duration classes, default hashtags, hypothesis requirement, and tests.
- `references/jarvis-operated-content-machine.md` — session-derived strategy notes for a JARVIS-operated, human-approved content machine: hook/follower psychology, variety vs identity, series families, and next implementation gates.
- `references/jarvis-content-machine-businessplan.md` — business/process plan for a JARVIS-operated content machine: idea-to-post pipeline, minimal user role, approval boundary, metadata generation, daily volume policy, and strategy scoring gate.
- `references/truetrace-branding-manual-posting.md` — TrueTraceShorts-specific brand positioning and phase-1 manual posting handoff: YouTube description, TikTok bio, visual direction, metadata pack shape, and no-go boundaries.
- `references/truetrace-concept-testbatch.md` — concrete 5-concept TrueTraceShorts testbatch pattern for validating saturated AI-workflow positioning before rendering at scale.
- `references/shorts-subtitles-tts-preview-packages.md` — top-3 timing preview package pattern, FFmpeg relative-path pitfall, Hormozi-inspired renderer-owned captions, and EdgeTTS/Magpie/Whisper TTS guidance.