Add YouTube companion runbook skill

README.md

@@ -99,6 +99,8 @@ agent-skills/
   media/
     aura-asset-images/
       SKILL.md
+    build-youtube-companion-runbooks/
+      SKILL.md
     unsplash-asset-images/
       SKILL.md
   ui/
@@ -177,7 +179,7 @@ Conventions:
 
 ## Current library
 
-This snapshot contains **123 skills** across five categories.
+This snapshot contains **128 skills** across five categories.
 
 Use `find agent-skills -name SKILL.md | sort` for the source of truth.
 
@@ -201,9 +203,10 @@ Operational skills for repeatable Codex work:
 - `write-like-meng-on-x` - calibrate concise X drafts against an authored voice corpus.
 - `x-bookmark-quote-posts` - turn recent X bookmarks into source-backed quote-post drafts.
 
-### Media (2)
+### Media (3)
 
-Image sourcing skills:
+Media production and image sourcing skills:
+- `build-youtube-companion-runbooks` - package verified videos into titles, thumbnails, chapters, descriptions, social copy, publication gates, and upload checks.
 - `aura-asset-images` - use Aura Assets for stock-style design and marketing imagery.
 - `unsplash-asset-images` - pick high-quality Unsplash assets by use case, crop, and ratio.
 
@@ -236,7 +239,7 @@ Player systems and feedback:
 Assets, performance, QA, and release:
 - `build-hybrid-game-assets`, `build-vesperfall-review-assets`, `optimize-threejs-games`, `test-playable-web-games`, `ship-web-games`
 
-### Web design (81)
+### Web design (85)
 
 Conversion and implementation:
 - `build-awwwards-quality-sites`, `landing-page`, `pricing-page`, `tailwindcss`, `animation-systems`, `webgl-landing-steering`

agent-skills/codex/write-repo-readme/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: write-repo-readme
+description: Write or rewrite a GitHub README that matches the owner's existing repos, with every claim checked against the code and every link verified before commit. Use when asked to create a README, fix an outdated one, make a repo presentable before sharing it, or set up a repo's About panel, description, topics, or preview image.
+---
+
+# Write a repo README
+
+A README is the landing page for a repo someone is about to share. It gets read once, quickly, by people deciding whether to click through. Two things sink it: claims that are wrong, and a voice that doesn't match the author's other work.
+
+Never write it from memory of the project. Read the code, measure the numbers, and check every link.
+
+## First, match the house style
+
+Before drafting anything, read two or three of the owner's existing READMEs. This is the step that matters most and the easiest one to skip.
+
+```bash
+gh api "users/<owner>/repos?per_page=100&sort=updated" --jq '.[] | select(.fork==false) | "\(.name)|\(.stargazers_count)|\(.description // "-")"'
+gh api repos/<owner>/<repo>/readme --jq '.content|@base64d'
+```
+
+Pick their most recent substantial projects, not their most starred, since old repos reflect an older voice. Note their section names, whether they use bullets or prose, whether they open with a live link, whether they include a preview image, and how technical they let the middle get. Follow what you find rather than importing a generic template.
+
+## Structure
+
+Adapt to the house style, but this order works for a project people can look at:
+
+1. **Title** — the project's name. Not the domain it deploys to, not the repo slug if that differs from what the thing is called.
+2. **One paragraph** saying what it is and what you can do with it. Concrete verbs.
+3. **Live link**, prominent, if there is somewhere to see it running.
+4. **Preview image** immediately after.
+5. **Inspiration or credits**, when the project started from someone else's work. Put it near the top rather than burying it at the bottom.
+6. **What is inside** — features as bullets, each naming a behavior rather than a technology.
+7. **How it is made** — the two or three genuinely interesting mechanisms, explained well enough that a builder learns something. This is the section people remember.
+8. **Run locally** — a copy-pasteable command.
+9. **Deployment**, if not obvious.
+10. **Other projects**, when asked for.
+11. **Credits.**
+
+## Verify every claim
+
+Anything countable goes in only after you measure it:
+
+```bash
+du -h index.html            # file sizes
+du -ch assets/*.woff2       # asset totals
+rg -c "<pattern>"           # counts of items, routes, entries
+```
+
+Check feature claims against the source. If you write that it supports reduced motion, grep for `prefers-reduced-motion` first. If you write that it has no external requests, load the page and confirm zero cross-origin entries in `performance.getEntriesByType('resource')`.
+
+Describing other projects: take the words from the source, never invent them. A repo's own `description` field, or the site's own `og:description`:
+
+```bash
+gh api repos/<owner>/<repo> --jq '.description'
+curl -sL -A "Mozilla/5.0 ..." <url> | grep -oiE '<meta[^>]*og:description[^>]*>'
+```
+
+Writing your own marketing copy for someone's product puts words in their mouth. Quote what they already say about themselves.
+
+## Hunt for stale infrastructure claims
+
+READMEs rot at the deployment line first. A project that moved hosts still tells people about the old one, and that is the first sentence a visitor reads. Before finishing, check that the stated host, URL, branch and build command are still true, and delete config files belonging to hosts no longer in use.
+
+## Link-check before committing
+
+Every link, no exceptions. One bad URL in a README that just got tweeted is the whole cost of this step:
+
+```bash
+grep -oE 'https://[^)]+' README.md | sort -u | while read u; do
+  printf "  %-52s %s\n" "$u" "$(curl -s -o /dev/null -L -w '%{http_code}' --max-time 12 -A "Mozilla/5.0" "$u")"
+done
+```
+
+Chase anything that isn't 200. Some hosts block bots and need a real user-agent before you conclude the link is dead.
+
+## Capture a preview image
+
+If the project is visual and running somewhere, a still belongs at the top. Screenshot the live site, not localhost, so the image proves the deployed thing works.
+
+Use the Codex in-app browser. Set a `1600 x 1000` viewport, load the deployed URL,
+wait for fonts, media, and entrance motion to settle, stage the most representative
+state, and save a browser-only screenshot. Reset the viewport when finished.
+
+**Stage the UI before the shutter.** A default screenshot catches the page at rest, which usually means the interesting feature is idle and invisible. Drive the page into the state that shows it working, then shoot. Call the project's own functions to do it rather than faking input.
+
+Convert down before committing, since a 2x PNG runs several megabytes:
+
+```bash
+sips -Z 2400 -s format jpeg -s formatOptions 82 /tmp/preview.png --out assets/preview.jpg
+```
+
+Then look at the result before committing it. A preview that misrepresents the project is worse than none.
+
+## Set the About panel
+
+The README isn't the only thing people see. A repo with no description or homepage looks abandoned in search results and link unfurls:
+
+```bash
+gh repo edit <owner>/<repo> \
+  --description "<one sentence: what it is and what you do with it>" \
+  --homepage "<live url>" \
+  --add-topic <topic> --add-topic <topic>
+```
+
+## Don't decide these alone
+
+- **A license.** Adding one grants rights on the owner's behalf. Point out that it's missing, recommend a common choice, and let them pick.
+- **Which projects to list.** Propose a short set and say what you left out and why. A full inventory reads as a résumé; three or four well-chosen links get clicked.
+- **Claims about people, revenue, or usage** that you cannot verify from a source. Leave them out and say you did.
+
+## Report back
+
+Say what you verified rather than asserting it is correct: the numbers you measured, the link-check result, any stale claim you found and fixed. Flag the parts you wrote rather than sourced, since those are the ones the owner needs to read closely.

agent-skills/game-development/develop-game-epithets/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: develop-game-epithets
+description: Develop and preliminarily screen original game protagonist epithets or role-titles from verified lore. Use for requests to name a player-character role like "Ashen One," generate dark-fantasy or genre-native hero titles, compare candidates, research game/storefront/entertainment/trademark/domain/handle conflicts, or prepare a naming recommendation before implementation. Treat the work as research, not legal clearance, and do not change production names or code unless the user separately approves a candidate and requests implementation.
+---
+
+# Develop Game Epithets
+
+Create a concise, speakable protagonist identity that belongs to the actual game world, then perform a current preliminary conflict screen and recommend one candidate.
+
+## Hold the implementation boundary
+
+- Treat naming as read-only research unless the user explicitly asks to implement an approved candidate.
+- Do not rename files, symbols, UI copy, routes, assets, or production data during naming research.
+- Preserve existing project changes and inspect the repository read-only.
+- Label every trademark result as preliminary screening, not legal advice or clearance.
+
+## Follow the workflow
+
+### 1. Verify the lore
+
+Identify the authoritative project path and inspect the current source rather than relying on the brief or model memory.
+
+Use `rg` and targeted file reads to find:
+
+- player and character-select labels;
+- world, level, location, and faction names;
+- death, revival, checkpoint, and quest copy;
+- inventory, relic, weapon, rarity, and item language;
+- bosses, enemies, NPC address, and dialogue;
+- title-card, objective, and ending copy.
+
+Record a compact evidence table with file links or source citations. Separate what the repository **establishes** from what it **does not establish**.
+
+If no authoritative project source is available, say so explicitly and switch
+to **brief-only mode**. Treat only the facts the user supplied as canon, cite
+them as user-provided brief evidence, and list every material unknown. Do not
+invent a repository, imply that source verification occurred, or block a
+creative round that can be completed honestly from the brief.
+
+### 2. Define the naming territory
+
+Extract:
+
+- protagonist function;
+- verified wound, curse, return loop, obligation, or lack thereof;
+- world metaphysics;
+- central motifs and verbs;
+- emotional tone;
+- vocabulary to own;
+- vocabulary to avoid because it belongs to enemies, other properties, or unsupported lore.
+
+Mark creative interpretations as interpretations. Never invent a curse, bloodline, scar, religion, rank, or chosen status to justify a name.
+
+### 3. Generate a broad candidate field
+
+Generate at least 30 genuinely distinct candidates across several structures:
+
+- compact compounds;
+- agent nouns and offices;
+- ritual or material identities;
+- participial or state titles;
+- two-word noun phrases;
+- sentence-like mythic titles.
+
+Do not submit 30 suffix swaps. Honor every hard constraint literally across the entire field. Avoid saturated structures and terminology identified by the user.
+
+Favor names that:
+
+- remain concise and pronounceable;
+- work with and without an article;
+- can be addressed aloud;
+- look strong in UI;
+- coexist cleanly with the game title;
+- communicate without fantasy word soup.
+
+Run a deterministic constraint audit before judging the field:
+
+```bash
+printf '%s\n' "Candidate One" "Candidate Two" |
+  python3 <skill-directory>/scripts/validate_candidate_field.py \
+    --require RequiredTerm --ban BannedTerm --min-count 30
+```
+
+Use the default substring matching when a required or banned element also
+matters inside a compound. Use `--match word` only when the constraint applies
+to a standalone word. Fix every reported violation before continuing.
+
+### 4. Run the first screen
+
+Evaluate every candidate for:
+
+- intended and accidental meaning;
+- pronunciation and likely mishearing;
+- person-title grammar versus weapon, attack, boss, location, or event grammar;
+- genericness and search ownership;
+- resemblance to famous game titles, characters, classes, factions, or generated-name vocabulary;
+- unsupported lore claims;
+- article and capitalization behavior;
+- dialogue fit.
+
+Advance roughly 8–12 candidates. Reject obvious same-field conflicts immediately.
+
+### 5. Perform current conflict research
+
+Read [research-checklist.md](references/research-checklist.md) before researching finalists.
+
+Run the bundled exact-surface helper as a first pass:
+
+```bash
+python3 <skill-directory>/scripts/knockout_screen.py "Candidate One" "Candidate Two" --format markdown
+```
+
+Then browse current sources. Search:
+
+- exact, spaced, hyphenated, concatenated, plural, singular, and likely phonetic variants;
+- games, characters, studios, novels, music, tabletop properties, fantasy products, and active brands;
+- Steam, itch.io, Epic, GOG, PlayStation, Xbox, Nintendo, Apple App Store, and Google Play;
+- USPTO, WIPO Global Brand Database, TMview/EUIPO, and UK IPO;
+- exact `.com` plus one or two useful game-oriented domains through registry RDAP;
+- major social/video handles where feasible.
+
+Use primary and official sources for trademark, registry, and storefront claims. Date-stamp every check and identify the jurisdiction.
+
+Respect the active environment's browser policy. If the task requires the Codex in-app browser, use it and do not substitute Chrome.
+
+For USPTO, search combined-mark exact forms and relevant close variants across all statuses. Include likely Nice classes 9, 41, and 28 without assuming other classes are irrelevant.
+
+If an official database is blocked, state that clearly. Do not imply a blocked check succeeded and do not treat an aggregator as equivalent to the official register.
+
+Reject a candidate with a meaningful current game, character, entertainment, or active-brand conflict even if no exact registered trademark appears.
+
+Classify the research state before deciding:
+
+- **Preliminary screen completed:** current broad-web and close-variant review,
+  major storefront review, official trademark checks for the relevant core
+  jurisdictions, and registry checks were all performed with documented
+  results.
+- **Degraded screen:** automation, indexed snippets, or only some required
+  sources were available. Present a **research-incomplete creative
+  front-runner**, list every missing check, and do not invite production
+  adoption yet.
+- **Blocked screen:** current conflict research could not be performed. Return
+  the creative work separately from the research blocker; do not call any
+  candidate screened.
+
+Use only careful conclusions:
+
+- “No obvious exact conflict found in this preliminary screen.”
+- “No registry object was returned.”
+- “The direct route returned HTTP 404.”
+
+Never say “available,” “cleared,” “safe,” or “guaranteed.”
+
+### 6. Score and decide
+
+Score the shortlist from 1–10 on:
+
+- lore fit;
+- distinctiveness;
+- spoken quality;
+- visual/UI quality;
+- searchability;
+- trademark risk;
+- storefront collision risk;
+- domain and handle practicality.
+
+Treat the score as a decision aid, not arithmetic proof. A meaningful entertainment conflict is a knockout even when the total score is high.
+
+If no candidate survives responsibly, generate a new round instead of lowering the standard.
+
+### 7. Stress-test the finalists
+
+Test the winner in at least these contexts:
+
+1. character-select heading;
+2. NPC address;
+3. death or revival line;
+4. inventory title;
+5. quest text;
+6. return announcement;
+7. spoken boss taunt.
+
+Also test:
+
+- canonical capitalization;
+- direct address without an article;
+- narrative use with an article;
+- pairing beside the game title;
+- singular/plural ambiguity;
+- likely voice pronunciation.
+
+Do not invent unsupported lore merely to make a test line work.
+
+### 8. Deliver one recommendation
+
+Use [report-template.md](references/report-template.md) for the full handoff.
+
+Lead with:
+
+- one clear recommendation, or a research-incomplete creative front-runner
+  when the required screen is degraded;
+- a short lore-grounded rationale;
+- the material conflict caveat.
+
+Then provide:
+
+- 2–4 strong fallbacks;
+- a compact comparison table;
+- winner dialogue/UI tests;
+- a rejection ledger for attractive failures;
+- direct sources and exact queries/databases checked;
+- research date and jurisdictions;
+- the preliminary-screening disclaimer;
+- the required counsel/expanded-clearance next step.
+
+For a completed preliminary screen, end with the exact single recommended
+name. For a degraded or blocked screen, end instead with
+`Research-incomplete creative front-runner: <Name>` so the final line cannot be
+mistaken for an adoption recommendation. State that no production rename was
+performed.
+
+## Keep the evidence honest
+
+- Distinguish exact matches, close matches, component crowding, and ordinary-language noise.
+- Treat search-engine non-results as low visible saturation, not proof of non-use.
+- Treat domain and handle state as volatile.
+- Prefer a clear name with a disclosed caveat over an opaque coined word that merely looks unique.
+- Preserve rejected candidates and reasons so later rounds do not repeat known failures.

agent-skills/game-development/develop-game-epithets/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Develop Game Epithets"
+  short_description: "Create and screen lore-native protagonist titles"
+  default_prompt: "Use $develop-game-epithets to create and preliminarily screen a protagonist epithet for my game from its current lore."