opencode-skills-collection 4.0.73 → 4.0.75

package/bundled-skills/film-crew/references/reroll-review.md

@@ -0,0 +1,46 @@
+# Reroll review: change one thing, then reroll
+
+AI video is probabilistic. Some rerolls are just the dice. Many are the prompt. The job
+here is to tell those apart and change **one** thing at a time, so each reroll teaches you
+something.
+
+## 1. Classify the failure
+
+| Class | Looks like | Most likely fix |
+|---|---|---|
+| **Dice** | The prompt is followed, the clip is just weaker than the last one | Reroll unchanged (new seed). Nothing to fix. |
+| **Ignored action** | The key event doesn't happen (the cup never spills) | Make the action the *first* clause; describe its start and end; cut everything else in the shot |
+| **Two things fighting** | Half an action, half another | Split into two shots |
+| **Physics break** | Liquid behaves like jelly, objects pass through each other | Frame tighter, slow the action, simplify the background, lock the camera |
+| **Identity drift** | Character looks different from other shots | Paste the continuity descriptors verbatim, or switch to image-to-video from one reference |
+| **Camera chaos** | Warped geometry, swimming background | One move only, slower, or locked-off |
+| **Look drift** | Color/light changes between shots | Paste the gaffer's line verbatim; name the source and color temperature |
+| **Artifacting** | Extra fingers, melting faces, flicker | Tighter framing, fewer subjects, add the negative prompt if supported |
+| **Text garbage** | Nonsense letters | Remove readable text from the shot |
+
+## 2. Decide
+
+- Same failure twice in a row → it's the prompt, not the dice. Apply the fix.
+- Different failures each time → the shot is too ambitious. Simplify it (split, tighten, slow down).
+- 3+ rerolls with no improvement → go back to the DP and director: re-block the shot.
+
+## 3. Report format
+
+```
+CLASS: Ignored action
+EVIDENCE: in 4/4 clips the cup lands upright; no liquid leaves it
+CHANGE (one): lead with the action — "Black coffee sloshes out of a tipping paper cup…" —
+              and cut the barista from the frame
+KEEP: lens, light, seed policy
+```
+
+## A worked example
+
+The upstream [ai-film-crew repository](https://github.com/HEOJUNFO/ai-film-crew) shows ten generations of one prompt in its `assets/ten-rerolls.png`:
+*"A barista bumps a customer's elbow and a paper coffee cup slips and spills onto the café
+floor next to white sneakers, slow motion, handheld close-up, warm morning light."*
+
+Across ten rerolls the cup falls, rolls, or lands upright. The spill (the whole point)
+barely happens. Diagnosis: **two things fighting** (the bump and the spill share one shot)
+plus **ignored action** (the spill is the last clause). The crew fix is in the upstream repository's
+`examples/coffee-spill-15s/SHOT_LIST.md`.

package/bundled-skills/film-crew/references/roles/director.md

@@ -0,0 +1,38 @@
+# Director
+
+**Job:** decide what this video is *for* and what happens, beat by beat. Everyone else
+executes your call.
+
+## Output (keep it under ~12 lines)
+
+```
+LOGLINE: one sentence, subject + action + turn.
+INTENT: what the viewer should do/feel/understand at the end (one line).
+HOOK (0–1.5 s): the first frame. Must be legible with sound off.
+BEATS:
+  1. 0.0–2.5 s  — …
+  2. 2.5–6.0 s  — …
+  …
+ENDING: button / reveal / loop point.
+```
+
+## Rules
+
+- **Open on motion or a question, never on an establishing shot.** In a vertical feed the
+  first 1.5 s decides whether anyone sees the rest.
+- **One idea per video.** If you need "and also", it's two videos.
+- **Beats are visible events,** not moods. "She realizes" is not a beat; "she stops
+  mid-sip and looks at the receipt" is.
+- **Budget for the model.** A beat that needs complex physics (pouring, cloth tearing,
+  hands manipulating small objects, crowds interacting) gets its own short shot, framed
+  tight, with nothing else going on.
+- **Loop if you can.** For short-form, an ending that cuts cleanly back to frame one
+  earns rewatches.
+- Product videos: the product must be on screen, unobstructed, by beat 2. Hero it once,
+  in the gaffer's best light, with no hands in the hero shot. If hands are the point
+  (handmade, cooking, a demo), give them their own shots and keep the hero shot clean.
+
+## Questions to ask yourself before handing off
+
+- Could a stranger describe this video in one sentence after watching it once?
+- Which beat would I cut if I had to lose 3 seconds? (Cut it now.)

package/bundled-skills/film-crew/references/roles/dp.md

@@ -0,0 +1,28 @@
+# Director of photography (DP)
+
+**Job:** decide exactly what the camera sees in each shot and how it moves.
+
+## Output: one line per shot
+
+```
+S1  ECU | 100mm macro | eye level | locked-off        | 2.5 s
+S2  MS  | 35mm        | low angle | slow push-in      | 4 s
+S3  WS  | 24mm        | high angle| handheld, drifting| 3 s
+```
+
+Shot sizes: ECU (extreme close-up), CU, MCU (chest up), MS (waist up), MWS, WS (full body), EWS (establishing).
+
+## Rules
+
+- **One camera move per shot.** Push-in, pull-out, pan, tilt, truck (sideways), pedestal
+  (up/down), orbit, handheld, or locked-off. Combining moves ("orbit while pushing in and
+  tilting up") is the #1 source of warped geometry.
+- **Name the lens.** 24mm reads wide and energetic, 35–50mm natural, 85–135mm compressed
+  and intimate, macro for texture. Models respond to focal lengths.
+- **Match move speed to duration.** A 3-second shot gets a *slow* move or none.
+- **Tight on hard physics.** Pours, spills, hands and small objects: frame close, keep the
+  background simple, lock the camera or move it very slowly.
+- **Vertical framing (9:16):** stack the composition vertically; keep faces in the upper
+  third and important action out of the bottom 15% (UI overlays live there).
+- **Vary sizes between consecutive shots** (e.g. WS → CU), or the cut will look like a jump.
+- Avoid "cinematic" as a camera instruction. It's a vibe, not a shot.

package/bundled-skills/film-crew/references/roles/editor.md

@@ -0,0 +1,34 @@
+# Editor
+
+**Job:** make the shots add up to a video: durations, order, cuts, pacing. You think about
+the timeline, not the frame.
+
+## Output
+
+```
+TOTAL: 15.0 s  (sum of shots, trimmed)
+S1 2.5 s  → hard cut
+S2 4.0 s  → match cut on motion
+S3 3.0 s  → smash cut
+…
+GENERATE: each shot +1 s handles (so S2 is generated at 5 s, used at 4 s)
+HOOK CHECK: frame 1 is S1 ECU, motion starts at 0.2 s ✅
+LOOP: last frame of S5 matches S1 composition ✅/❌
+```
+
+## Rules
+
+- **Fit the model.** Every shot must be ≤ the model's max clip length (see
+  `references/model-prompting.md`). If a beat needs longer, split it into two shots with a
+  change of angle.
+- **Generate long, use short.** Plan 0.5–1 s of handles at each end. The first and last
+  frames of AI clips are often the weakest.
+- **Fixed-length models** (only preset lengths such as 5 s / 10 s): generate at the
+  shortest preset and pick the strongest section. A 2.5 s shot uses the best 2.5 s of a
+  5 s clip; note which section in the timeline.
+- **Short-form pacing:** 1.5–3 s per shot is normal; a 6 s static shot kills retention
+  unless something is happening in it.
+- **Cut on action.** If S1 ends with a hand moving right, S2 should start with motion
+  continuing right.
+- **Text goes in the edit,** not the prompt. Note captions/supers here with timings.
+- Call out any shot that exists only for coverage. Coverage costs generations.

package/bundled-skills/film-crew/references/roles/gaffer.md

@@ -0,0 +1,30 @@
+# Gaffer
+
+**Job:** light the scene so it looks intentional and stays consistent between shots.
+
+## Output
+
+```
+TIME / SOURCE: late afternoon sun through west window (motivated)
+KEY: camera-left, 45°, soft
+FILL: low, bounce from white tabletop
+RIM / BACK: warm sun edge on hair
+COLOR TEMP: warm key ~3200K vs cool ambient ~5600K
+CONTRAST: medium-high, deep shadows
+PRACTICALS: pendant bulbs visible in background, slightly blown
+LOOK: 35mm film, fine grain, mild halation
+```
+
+## Rules
+
+- **Motivate the light.** Say where it comes from (window, neon sign, streetlight,
+  monitor glow). Unmotivated "dramatic lighting" gives you random results.
+- **Same key direction in every shot of a scene,** or the cut breaks continuity.
+- **Contrast beats brightness.** Flat, evenly lit prompts are what make AI video look
+  like AI video. Ask for shadows.
+- Color: pick one warm/cool contrast and hold it. Write it in plain words plus a
+  temperature if useful.
+- Night scenes: name the sources (sodium streetlight, phone screen, neon). "Dark" alone
+  gets you murk.
+- Products: soft key, clean rim to separate from background, a highlight that shows the
+  material (gloss, brushed metal, glass).

package/bundled-skills/film-crew/references/roles/production-designer.md

@@ -0,0 +1,43 @@
+# Production designer
+
+**Job:** make the world consistent. You write the **continuity bible**: the exact words
+every other role must paste, verbatim, whenever a character, prop or location appears.
+
+Video models have no memory between clips. The *only* continuity you get is identical
+wording. Paraphrasing a character ("a woman in a red coat" → "the lady in crimson")
+gives you a different person.
+
+## Output
+
+```
+CHARACTERS
+  C1  <age range> <build> <hair: length, color, style> <skin tone> <face detail>,
+      wearing <top, color, material> and <bottom>, <one distinctive accessory>
+LOCATIONS
+  L1  <place type>, <era/style>, <3 concrete set details>, <floor/wall materials>
+PROPS
+  P1  <object>, <material>, <color>, <size cue>, <state: new/used/half-full…>
+PALETTE
+  3–5 colors, named plainly ("mustard yellow, teal, off-white")
+```
+
+Every entry gets two versions:
+- **FULL** — the whole description, for shots where the whole subject is in frame.
+- **TIGHT** — only what a close-up can see (e.g. `C1-TIGHT: weathered hands, short
+  clean nails, a thin silver ring, sleeves of a faded olive sweatshirt pushed up`).
+
+Close-ups use TIGHT verbatim; wider shots use FULL verbatim. Pasting a whole-person
+description into an ECU of hands drags the rest of the person (and the set) into frame.
+
+## Rules
+
+- 20–35 words per character. Concrete nouns and colors, no adjectives like "beautiful".
+- One **distinctive anchor** per character (a yellow beanie, a scar, round glasses).
+  Anchors survive model drift better than faces do.
+- Avoid real people, brands and logos. Describe the *type* ("a white leather low-top
+  sneaker") not the brand.
+- Props that matter to the story get a state ("a paper cup, lid off, full to the brim
+  with black coffee"). State is what makes the action physically possible.
+- Keep locations simple enough to re-generate: 3 set details, not 12.
+- If the user supplies a reference image, write the bible *from the image* so the text
+  and the image agree.

package/bundled-skills/film-crew/references/roles/script-supervisor.md

@@ -0,0 +1,35 @@
+# Script supervisor
+
+**Job:** protect continuity and catch the shots that will fail *before* anyone spends a
+generation on them. You have veto power: any shot you flag gets rewritten.
+
+## Checklist (run on every shot)
+
+**Continuity**
+- [ ] Every recurring character/prop/location is pasted verbatim from the continuity bible.
+- [ ] Key light direction and color temperature match the rest of the scene.
+- [ ] Screen direction is consistent (subject moving left→right keeps moving left→right).
+- [ ] Props are in the right state (the cup that spilled in S2 isn't full in S3).
+
+**Feasibility**
+- [ ] One subject action, one camera move.
+- [ ] Duration ≤ model max, with handles.
+- [ ] No readable text, logos, UI or signage in frame (unless the model handles text).
+- [ ] Hard physics (liquids, cloth, hands with small objects, multiple people touching) is
+      framed tight, isolated, and given a simple background.
+- [ ] Nothing depends on a specific real person's likeness or a trademark.
+- [ ] Counts are small: "two dogs" works better than "five dogs".
+
+**Unslop** (see `references/unslop.md`)
+- [ ] No empty quality words ("stunning, 8k, masterpiece, hyper-realistic, cinematic").
+- [ ] No mood-only instructions; every feeling is translated into something visible.
+- [ ] Skin, materials and motion have texture and imperfection specified where it matters.
+
+## Output
+
+```
+S2 ⚠️  two actions (pours AND turns to customer) → split into S2a / S2b
+S4 ⚠️  sign text "OPEN" in frame → remove, add in edit
+S3 ✅
+HIGHEST RISK: S2a (liquid physics). Reroll plan: tighten to ECU, lock camera.
+```

package/bundled-skills/film-crew/references/roles/sound.md

@@ -0,0 +1,23 @@
+# Sound
+
+**Job:** plan what the audience hears. Run this role only if the target model generates
+audio, or the user will add music/SFX in the edit.
+
+## Output
+
+```
+MUSIC: <genre, tempo in BPM, energy curve> (added in edit)
+S1 SFX: ceramic clink, café murmur (low)
+S2 DIALOGUE: C1: "Not again." (quiet, deadpan)
+S3 SFX: liquid splash, sneaker squeak
+```
+
+## Rules
+
+- **Audio-capable models:** put spoken lines in double quotes with the speaker named, keep
+  lines under ~8 words per shot, and name 1–2 SFX plus ambience. Too many sound cues
+  produce mush.
+- **Silent models:** don't write sound into the prompt at all. It wastes tokens and can
+  drift the visuals. Put sound in the edit notes.
+- Cut points should land on beats of the music (tell the editor the BPM).
+- Short-form: design for sound-off first. If a line is essential, it also goes in a caption.

package/bundled-skills/film-crew/references/templates/shot-list.md

@@ -0,0 +1,38 @@
+# SHOT LIST — <title>
+
+**Format:** <aspect> · <total length> · target model: <model>
+**Mode:** text-to-video | image-to-video (reference: <file/description>)
+**Brand / product:** <name, or "none given — generic">
+**Logline:** <one sentence>
+
+## Crew notes
+**Director** — intent, hook, beats
+**Production designer** — continuity bible (C1…, L1…, P1…)
+**DP / Gaffer** — look summary in two lines
+**Editor** — timeline summary
+**Sound** — (if applicable)
+**Script supervisor** — flags resolved
+
+## Shots
+| # | Time | Size · Lens · Move | Action (one) | Gen length | Risk |
+|---|---|---|---|---|---|
+| S1 | 0.0–2.5 | ECU · 100mm · locked | … | 4 s | low |
+
+## Prompts
+
+### S1
+```
+<prompt>
+```
+Negative (if supported): `<negative prompt>`
+
+## Edit notes
+- Captions / supers: <text> @ <time>
+- Music / SFX: <cue> @ <time>
+
+## Reroll plan
+| Shot | Likely failure | Change before reroll |
+|---|---|---|
+| S1 | … | … |
+
+**Highest-risk shot:** S? — <why>

package/bundled-skills/film-crew/references/unslop.md

@@ -0,0 +1,29 @@
+# Unslop: why AI video looks like AI video, and what to write instead
+
+| Slop signal | Usual cause in the prompt | Write instead |
+|---|---|---|
+| Plastic, poreless skin | "beautiful", "flawless", "perfect skin" | "visible pores, slight shine on the forehead, faint under-eye shadows" |
+| Everything evenly lit | no light source named | a motivated key ("hard sun through blinds, camera-left") and deep shadows |
+| Floaty slow-motion drift | no speed given, "cinematic" | real-time speed, or a stated speed ("normal speed", "2x slow motion") |
+| Camera wandering aimlessly | no camera instruction | one named move, or "locked-off tripod shot" |
+| Morphing hands / objects | complex hand action, wide framing | tight framing, simple grip, one object, slow action |
+| Faces changing between shots | paraphrased character descriptions | verbatim continuity-bible descriptors, or image-to-video from one reference |
+| Oversaturated, HDR-ish color | "vibrant", "8k", "ultra HD" | a film look ("Kodak Portra 400, soft contrast, fine grain") and a limited palette |
+| Symmetrical stock-footage framing | no composition choice | a lens, an angle and an off-center subject ("subject in left third") |
+| Gibberish text | signage, labels, UI in frame | no readable text in frame; add text in the edit |
+| Nothing actually happens | a mood instead of an action | one visible, physical action with a start and an end |
+
+## Words that add nothing
+
+`stunning, masterpiece, best quality, 8k, 4k, ultra-detailed, hyper-realistic, award-winning, trending, epic, cinematic (alone), breathtaking`
+
+Delete them. They don't hurt much on their own, but they push out words that would help.
+
+## Words that tend to help
+
+- A **lens** (24mm, 50mm, 85mm, macro)
+- A **camera move** (slow push-in, locked-off, handheld)
+- A **light source** (window light, sodium streetlight, overhead fluorescent)
+- A **film stock or look** (35mm film grain, Super 8, VHS camcorder, iPhone front camera)
+- **Imperfection** (scuffed, fingerprints, wrinkled, condensation, frayed)
+- **Real-time physics cues** (splashes, drips, recoils, bounces)

package/bundled-skills/mcp-dependency-drift-audit/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: mcp-dependency-drift-audit
+description: "Statically audit MCP configs for mutable npm/npx package references before approval or CI, without executing discovered MCP servers."
+category: security
+risk: safe
+source: "https://github.com/tomelias10/mcp-drift-check"
+source_repo: tomelias10/mcp-drift-check
+source_type: community
+date_added: "2026-09-25"
+author: tomelias10
+tags: [mcp, ai-security, supply-chain, devsecops, sarif]
+tools: [claude, cursor, gemini, codex, windsurf]
+license: MIT
+license_source: "https://github.com/tomelias10/mcp-drift-check/blob/v0/LICENSE"
+---
+
+# MCP Dependency Drift Audit
+
+## Overview
+
+Audit Model Context Protocol configuration files for npm/npx package references that can resolve to different code after the configuration was reviewed. The workflow is deliberately static: it reads config text, classifies version selectors, and recommends reproducibility fixes without starting discovered MCP servers.
+
+Dependency mutability is a review-boundary signal, not proof that a package is malicious, vulnerable, or compromised.
+
+## When to Use This Skill
+
+- Before approving `.mcp.json`, Cursor, VS Code, GitHub Copilot, Claude, or Windsurf MCP configuration.
+- When adding an MCP configuration gate to pull requests or CI.
+- During an AI-agent security review where npm/npx-backed MCP servers are configured.
+- When checking whether a previously reviewed MCP config can silently resolve to newer package code.
+
+## How It Works
+
+### Step 1: Locate and read MCP configs without executing them
+
+Inspect known project paths such as `.mcp.json`, `.github/mcp.json`, `.cursor/mcp.json`, `.vscode/mcp.json`, and `.windsurf/mcp.json`, plus any MCP config explicitly supplied by the user.
+
+Read them as text/JSON only. Never run a discovered `command` or `args` value as part of this audit. Stay inside the requested workspace by default; only include user-level/global MCP configuration if the user explicitly asks for machine-wide scope.
+
+### Step 2: Use MCP Drift Check when already available
+
+If `mcp-drift-check` is already installed, use the workspace-scoped mode from the intended repo root:
+
+```bash
+mcp-drift-check scan-workspace --markdown
+```
+
+For CI evidence:
+
+```bash
+mcp-drift-check scan-workspace --sarif mcp-drift.sarif --markdown
+```
+
+If the scanner is not installed, explain that the following command fetches the open-source scanner from GitHub and get user approval before running it:
+
+```bash
+uvx --from git+https://github.com/tomelias10/mcp-drift-check mcp-drift-check scan-workspace --markdown
+```
+
+If the user declines network access or installation, continue with the manual rules below.
+
+### Step 3: Apply the manual static rules
+
+For npm/npx-style package selectors:
+
+| Selector | Classification | Reason |
+| --- | --- | --- |
+| `package@1.2.3` | SAFE | Exact package version is reproducible. |
+| bare `package` or `@scope/package` | HIGH | A later resolution can select different package code. |
+| `package@latest` | HIGH | The selector is explicitly mutable. |
+| `package@^1.2.0`, `~1.2.0`, `>=1.2.0`, wildcard | MEDIUM | Resolution can change within the allowed range. |
+| local path, script, binary, unknown executable | REVIEW | npm version-drift rules do not establish update behavior. |
+
+Treat `-y` / `--yes` as context only. It suppresses interactive confirmation but is not a vulnerability by itself.
+
+### Step 4: Recommend remediation without inventing versions
+
+For mutable npm/npx references, recommend pinning to an exact version that the team has actually reviewed and then updating that pin deliberately.
+
+Do not guess the version to pin. If registry lookup is needed, explain that it requires network access and ask before querying it.
+
+Pinning improves reproducibility. It does not establish package provenance, vulnerability status, authorization safety, prompt-injection resistance, or runtime isolation.
+
+### Step 5: Produce a bounded report
+
+Return:
+
+| Config | MCP server | Package/reference | Classification | Why | Recommended next step |
+| --- | --- | --- | --- | --- | --- |
+
+Then state:
+
+- No MCP servers were executed during the audit.
+- Mutable dependency references are review/reproducibility signals, not breach claims.
+- A clean dependency-drift result is not a complete MCP security assessment.
+
+## Examples
+
+### Example 1: Audit before approval
+
+**User:** `Audit this repo's MCP config before we approve it. Do not run any MCP servers.`
+
+**Expected shape:**
+
+```text
+.mcp.json | browser | @example/browser-mcp@latest | HIGH
+Reason: @latest can resolve to different package code later.
+Next step: pin the exact version your team reviews and update it deliberately.
+
+No MCP servers were executed.
+```
+
+### Example 2: Add a CI gate
+
+For GitHub Actions:
+
+```yaml
+- uses: actions/checkout@v4
+- uses: tomelias10/mcp-drift-check@v0
+```
+
+MCP Drift Check can also emit SARIF 2.1.0 for GitHub Code Scanning. The action defaults to workspace-only discovery; machine-wide user-level scanning remains an explicit `scan-all` choice.
+
+## Best Practices
+
+- ✅ Read config text only during discovery and classification.
+- ✅ Keep the default scope to the requested workspace/repository.
+- ✅ Separate reproducibility findings from vulnerability or compromise claims.
+- ✅ Pin only a version the team has actually reviewed.
+- ✅ Keep sensitive config values out of reports and public issues.
+- ❌ Do not execute server commands found in a config to "verify" a static finding.
+- ❌ Do not treat a clean result as a general MCP security guarantee.
+
+## Limitations
+
+- This workflow only covers dependency mutability/review drift for package-backed MCP configuration.
+- It does not assess prompt injection, tool poisoning, OAuth/authorization, server implementation flaws, malware, provenance, or runtime sandboxing.
+- Local executables and non-npm launch paths require separate review.
+- A static config can be reproducible and still unsafe for other reasons.
+
+## Security & Safety Notes
+
+- The default workflow is read-only, local, and workspace-scoped.
+- Never execute discovered MCP server commands during this audit.
+- Never include credentials, tokens, private headers, or secret values in the output.
+- The optional `uvx` path makes a network fetch from the declared GitHub source; obtain user approval before running it.
+- If deeper active testing is requested, stop and establish explicit authorization and scope before any intrusive action.
+
+## Common Pitfalls
+
+- **Problem:** Calling an unpinned dependency a vulnerability.
+  **Solution:** Describe it as a reproducibility/review-drift signal unless separate evidence establishes security impact.
+- **Problem:** Pinning to today's registry version without knowing what was reviewed.
+  **Solution:** Ask for the reviewed version or, with approval, reconstruct relevant package history; do not guess.
+- **Problem:** Treating `-y` as the core finding.
+  **Solution:** Report it only as context; the version selector determines the dependency-drift classification.
+- **Problem:** Scanning user-level MCP configs when the user only asked about one repo.
+  **Solution:** Use `scan-workspace` by default; use `scan-all` only when machine-wide scope is explicit.
+
+## Related Skills
+
+- `@mcp-server-security` - Broader MCP server hardening, authentication, authorization, transport, and runtime controls.
+- `@supply-chain-security` - Broader software supply-chain assessment beyond MCP configuration.
+- `@sast-scanning` - Static application-security analysis for source code rather than MCP launch configuration.
+
+## Additional Resources
+
+- [MCP Drift Check stable v0](https://github.com/tomelias10/mcp-drift-check/tree/v0) - MIT zero-execution scanner, GitHub Action, workspace-scoped mode, and SARIF output.
+- [Public MCP dependency drift examples](https://site-creator-vinext-starter.surfaceproof.workers.dev/research/mcp-dependency-drift) - Commit-specific public configuration examples and methodology limitations.