# Arcade Source Content > Use when turning raw product material, a list of subtopics, and a list of demos into per-subtopic scene files for an Arcade video or slide deck. Triggers on requests to build deck source content, fill the scene template per subtopic, or prepare a product story for Arcade handoff. - Skill: `mrudisill26/arcade-source-content` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add mrudisill26/arcade-source-content` - Raw SKILL.md: https://api.skillmd.com/api/skills/mrudisill26/arcade-source-content/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: mrudisill26 (https://skillmd.com/u/mrudisill26) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/mrudisill26/arcade-source-content --- # Arcade Source Content ## Overview Turns raw product material + named subtopics + a demo list into **one scene file per subtopic**, all sharing identical variable names so Arcade can rebuild the same visual template with different copy. **Core principle:** the product layer is written once and repeated verbatim; only the subtopic layer varies. Everything is driven by the demos. ## Inputs Ask for whatever is missing. Do not proceed on assumptions. | Input | What it is | |---|---| | Raw content | Product pages, decks, notes, pasted text — the source of all copy | | Subtopics | 5–8, named by the user. One output file each. | | Demos | Name + description + link. Drives key points. | ## Process ### 1. Write the product layer — once Derive from raw content, then reuse **byte-identical** in every file: `Scene 1 Title`, `Scene 1 Subtitle`, `Scene 2 Kicker`, `Word 1/2/3`, `Scene 2 subtitle`, closing `TITLE`, closing `Subtitle`. Only `Top left corner` changes between files. Before writing any file, draft these seven values as one block and check them against every subtopic — they must work for all of them, not for the subtopic you happen to be writing. If a value only fits one subtopic, it belongs in the subtopic layer. ### 2. Assign demos to subtopics A demo may serve more than one subtopic — reuse is fine and expected. A demo that fits nowhere goes in the coverage report as unused; do not force it into a subtopic. ### 3. Count key points from demos **Key points = demos assigned to that subtopic, capped at 4, minimum 1.** One demo, one key point. When a subtopic has 5+ demos, pick the strongest 4 and list the rest as surplus in the coverage report. Scene numbering follows the count: | Key points | Key point scenes | Closing scene | |---|---|---| | 1 | 4 | 5 | | 2 | 4, 5 | 6 | | 3 | 4, 5, 6 | 7 | | 4 | 4, 5, 6, 7 | 8 | A 2-demo subtopic emits 2 pillars and closes on Scene 6. Renumbering the closing scene is correct; a 7-scene file for a 2-demo subtopic is not. ### 4. Pick the Scene 2 demo Scene 2's demo previews the subtopic. Use the subtopic's **broadest** demo, and prefer one that is not already a key point demo. When every demo is already a key point demo (common at 1–2 key points), reuse the strongest and note it in the coverage report. When one demo is a clear **overview** of the subtopic rather than a specific capability ("Automation for AIOps" next to three named integrations), reserve it for Scene 2. It becomes the preview and does not count toward the key point total from step 3. A demo with no link is not usable. Exclude it from key point counting and list it in the coverage report under unusable, so the count reflects what can actually ship. ### 5. Write the subtopic layer Per key point, from the raw content — not from the demo description alone: a Kicker, a Title, and exactly 3 bullets. ### 6. Emit files ``` -source-content/ 00-coverage.md 01-.md 02-.md ``` Current directory unless the user gives a path. ## Field Contract Every field, every file. `template.md` in this directory is the structure to copy; `example.md` is the quality bar to match. Read both before writing. | Field | Shape | |---|---| | `Scene 1 Subtitle` | The product promise in **one short sentence, ≤10 words**, ending in a period. "One platform to automate it all." | | `Word 1/2/3` | Three single **verbs**, imperative mood, each ending in a period. "Automate." "Orchestrate." "Scale." Never adjectives. | | `Scene 2 subtitle` | Product positioning, one sentence, 10–20 words. | | `Scene 3 Subtitle` | The subtopic's promise, one sentence, ≤12 words. | | `Pillar N` | 1–3 words, sentence case, loose theme label. | | `Pillar N desc` | Scene (3+N)'s Title, **verbatim, character for character**. | | `Kicker` | 1–3 words, **ALL CAPS**. The theme, not the product. Reword the Pillar label rather than copying it. | | `Title` | A claim, not a topic label. ≤8 words, ends with a period. | | `Bullet 1/2/3` | Exactly 3. **8–16 words each.** No bullet restates its Title. | | `DEMO` | ` — ` and nothing else. No description, no commentary. | | `Top left corner` | This file's subtopic name, on every scene. | | Closing `Subtitle` | `, , and with .` — the product name is required. | Match the capitalization style the user used for the product name. ## Bullets escalate Three bullets, three jobs, in order: 1. **Capability** — what it does 2. **Mechanism** — how it works 3. **Outcome** — why it matters to the buyer ``` Bullet 1: Let AI identify the best fix; AAP carries it out consistently. Bullet 2: Integrate via event-driven triggers or direct API calls. Bullet 3: Position AAP as the trusted execution layer beneath any AI stack. ``` Every bullet traces to a claim in the raw content or a demo description. Do not invent metrics, customer names, or capabilities. ## Coverage report `00-coverage.md` is part of the deliverable, because handoff decisions get lost in chat: - Table: subtopic → key point count → demos used - **Demos used in more than one subtopic**, and where - **Unused demos**, with a one-line note on why none fit - Anything inferred rather than sourced, marked `` in the file it appears in ## Common Mistakes | Mistake | Fix | |---|---| | Rewriting Scene 1/2/closing copy for each subtopic | Product layer is written once and pasted verbatim. Only `Top left corner` varies. | | Padding to 3 pillars by borrowing a demo from another subtopic | Emit 2 pillars, drop the last key point scene, renumber the closing scene. | | Putting the demo description in the `DEMO` field | ` — `. The description informed the bullets; it does not ship. | | Kicker copied from the Pillar label | Pillar is a loose label; Kicker is ALL CAPS and reworded. | | Titles as topic labels ("AI-Driven Remediation Capabilities") | Write a claim: "AI recommends. Ansible executes." | | 25-word bullets stacked with em-dashes | 9–16 words. Cut the clause after the dash. | | Emitting `TODO` to keep the scene count at 7 | Never. Drop the scene instead. | | Reporting reuse and orphan demos only in chat | They belong in `00-coverage.md`. | ## Before handing off Check each generated file: - [ ] Product-layer fields are identical across all files (diff them) - [ ] Scene count = key points + 4, closing scene numbered correctly - [ ] Every `Pillar N desc` matches its scene's `Title` verbatim - [ ] Every `DEMO` is `name — link` and the link was supplied by the user - [ ] Every key point scene has exactly 3 bullets - [ ] `Top left corner` present on every scene - [ ] No placeholder or `TODO` text ## Next step These files are the input to `arcade-booth-generate`, which turns one of them at a time into a generated Arcade video.