opencode-skills-collection 4.0.72 → 4.0.74

package/bundled-skills/.antigravity-install-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "updatedAt": "2026-09-24T01:56:44.424Z",
+  "updatedAt": "2026-09-26T02:19:01.177Z",
   "entries": [
     "00-andruia-consultant",
     "007",
@@ -38,6 +38,7 @@
     "agent-harness-fault-injection",
     "agent-manager-skill",
     "agent-memory",
+    "agent-memory-discipline",
     "agent-memory-mcp",
     "agent-memory-systems",
     "agent-observability",
@@ -940,6 +941,7 @@
     "file-path-traversal",
     "file-uploads",
     "filesystem-context",
+    "film-crew",
     "find-bugs",
     "find-complementary-founders",
     "find-matching-tenders",
@@ -1603,6 +1605,7 @@
     "nfs-storage",
     "nft-standards",
     "nika",
+    "noaa-radar-satellite-fetching",
     "nodejs-backend-patterns",
     "nodejs-best-practices",
     "nosql-expert",
@@ -2204,6 +2207,7 @@
     "test-fixing",
     "test-framework-migration-skill",
     "test-guard",
+    "testdriver-e2e-testing",
     "testing-patterns",
     "testing-qa",
     "testng-skill",
@@ -2362,8 +2366,12 @@
     "warp-delegate",
     "warren-buffett",
     "wcag-audit-patterns",
+    "weather-data-lifecycle-management",
+    "weather-data-reproducibility",
     "weather-model-data-fetching",
+    "weather-model-run-discovery",
     "weather-observation-fetching",
+    "weather-pipeline-performance-diagnosis",
     "weaviate",
     "weaviate-cookbooks",
     "web-artifacts-builder",

package/bundled-skills/agent-memory-discipline/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: agent-memory-discipline
+description: "Rules for when an agent should recall from long-term memory before acting and when it should save decisions, corrections and failures afterwards. Works with any memory backend."
+category: memory
+risk: safe
+source: community
+source_repo: mnemoverse/agent-memory-discipline
+source_type: community
+date_added: "2026-09-23"
+author: mnemoverse
+tags: [agent-memory, long-term-memory, context-engineering, mcp, agent-skills]
+tools: [claude, cursor, gemini]
+license: "CC0-1.0"
+license_source: "https://github.com/mnemoverse/agent-memory-discipline/blob/main/LICENSE"
+---
+
+# Agent Memory Discipline
+
+## Overview
+
+Connecting a memory tool does not make an agent use it: tools register, the session runs, and nothing gets recalled or saved. This skill supplies the missing part, standing rules for when to read memory and when to write it.
+
+The problem it solves is specific. An agent with memory available still repeats settled questions, reverts corrected habits, and loses decisions between sessions, because nothing tells it when recall and save are due. The rules below make both moments explicit.
+
+## When to Use This Skill
+
+- Use when a memory tool or MCP memory server is connected but the agent is not using it consistently.
+- Use when the user complains that the assistant loses preferences, conventions or past decisions between sessions.
+- Use when setting up persistent memory for a project and the agent needs standing rules for reading and writing it.
+- Use when the user says "remember this", "what did we decide", "recall", or "save this for next time".
+
+## How It Works
+
+### Before You Start: Any Memory Backend
+
+The agent needs a memory tool it can call. Any backend works, and the rules are identical for each:
+
+- **Files.** A `memory/` folder of Markdown notes, one fact per file. No dependencies, fully greppable, versionable in git.
+- **A local MCP memory server.** Keeps everything on the local machine; several open-source options exist.
+- **A hosted memory service over MCP.** Adds portability across tools and machines at the cost of the data living elsewhere.
+
+Authentication is whatever the chosen backend requires: none for a local folder, the server's own configuration for a local MCP server, an API key or OAuth sign-in for a hosted service. This skill never handles credentials itself and never writes them into memory.
+
+### Step 1: Recall Before Acting
+
+Read memory **before** doing any of these, not after:
+
+- starting work on a project touched before
+- choosing a library, pattern, or tool
+- writing tests, commits, or documentation, where conventions apply
+- answering "how do we usually do X here"
+- anything the user phrases as "again", "like last time", or "as we agreed"
+
+Skip recall for one-off factual questions, arithmetic, or anything fully specified in the current message. Recall costs a tool call and context; spending it on a self-contained question is waste.
+
+Search with the words the user actually used, plus the project or repository name. If the first search returns nothing useful, try one broader query, then stop and proceed without memory rather than looping.
+
+### Step 2: Save After Deciding
+
+Write to memory when one of these has just happened:
+
+- a **decision** was made and will still matter next week ("we use pnpm", "the billing module stays untouched")
+- the user **corrected** the agent, which is the strongest signal there is
+- an approach **failed**, and why it failed
+- a preference was stated that applies beyond this task
+- a fact about the environment was discovered the hard way (a port, a flag, a service that must be running)
+
+Do **not** save: the contents of files that can be read again, restatements of the current task, transient state, anything the user marked as temporary, and anything containing secrets, tokens, or personal data.
+
+One memory, one fact. A paragraph containing four decisions cannot be superseded cleanly when one of them changes.
+
+### Step 3: Write It So It Survives
+
+A memory that is useless in three weeks was written wrong. Give each entry, in the text if the backend has no fields for it:
+
+- **what** was decided or observed, in one sentence
+- **why**, briefly, because the reason outlives the decision
+- **when** it became true, and when it stopped being true if it has
+- **where it came from**: a file, a commit, a conversation, a test run
+
+Prefer the user's own words over a paraphrase. Paraphrase drifts.
+
+### Step 4: Close the Past Instead of Overwriting It
+
+When something changes, the old memory is not wrong. It is **closed**.
+
+If the project moved from Redux to Zustand, "we use Redux" was true from January to June. Deleting it destroys the explanation for every component written in that window. Mark it superseded, keep its validity window, and write the new one alongside.
+
+This is the single most destructive habit in agent memory, and it stays invisible until someone asks a question about old code.
+
+### Step 5: Keep Contradictions Visible
+
+If recall returns two entries that disagree, do not pick the closer match and proceed. Surface both, with their dates, and ask or flag. A convention that a recent failure contradicts is exactly the situation where the user needs to be told, not smoothed over.
+
+### Step 6: Weigh Evidence and Policy Differently
+
+- **Evidence** is what happened: one run, one failure, one observation. Cheap, plentiful, individually unreliable.
+- **Policy** is what should happen: a convention, a decision, a rule. Expensive, and should be hard to change by accident.
+
+An observation becomes policy when a human confirms it, when it lands in a merged decision record, or when it has worked repeatedly. Never promote a single observation to a rule without one of those.
+
+### What Following This Skill Produces
+
+Two things, and nothing else:
+
+- **Recalled context, stated before the work starts.** The relevant entries are named with their dates and sources, so the user can see what the agent is relying on. Conflicting entries are shown side by side, not merged.
+- **New memory entries after decisions, corrections and failures.** One fact each, in this shape:
+
+```text
+Project uses pnpm, not npm. Stated by the user on 2026-08-11 after a lockfile conflict. Applies to all packages in this repo.
+```
+
+A superseded entry keeps its text and gains an end date and a pointer to the entry that replaced it. The full format, with closing and evidence examples, is in [references/entry-format.md](references/entry-format.md).
+
+## Examples
+
+### Example 1: A Correction
+
+The user says: *"stop using npm here, we're on pnpm."*
+
+1. This is a correction, which is the strongest save signal. Save it.
+2. Write the entry:
+
+```text
+Project uses pnpm, not npm. Stated by the user on 2026-08-11 after a lockfile conflict. Applies to all packages in this repo.
+```
+
+3. Do not also save "the user was annoyed", "ran npm install", or the lockfile contents.
+4. Next session, before running any package command in this repo, recall first and find it.
+
+### Example 2: A Contradiction
+
+Recall returns two entries:
+
+```text
+Integration tests run against the staging database (2026-06-02)
+Integration tests use a local container; staging is off limits after the incident (2026-08-19)
+```
+
+1. Do not pick one and continue. State both, with dates.
+2. Ask: *"Memory has two rules for integration tests; the August one says staging is off limits. Use the local container?"*
+3. After the answer, close the entry that no longer holds, with its end date, and keep the other.
+
+### Example 3: Closing an Entry That Stopped Being True
+
+Do not delete the old entry. Add an end date and a pointer to what replaced it, then write the new entry alongside:
+
+```text
+[closed 2026-06-30, replaced by "State management uses Zustand"] State management uses Redux. Decided in the January architecture review.
+State management uses Zustand. Migrated in June after the bundle size review. Applies to all new components.
+```
+
+## Best Practices
+
+- **Do:** recall before project-specific work, and name the entries you rely on with their dates and sources.
+- **Do:** save right after a decision, a correction, or a failure, in one sentence with its reason.
+- **Do:** keep one fact per entry, so a later change can supersede it cleanly.
+- **Do:** prefer the user's own words over a paraphrase.
+- **Don't:** overwrite or remove an entry that stopped being true; close it with an end date instead.
+- **Don't:** save file contents that can be read again, restatements of the current task, or transient state.
+- **Don't:** promote a single observation to a rule without human confirmation, a merged decision record, or repeated success.
+
+## Limitations
+
+- This skill installs no memory backend and requires no account. Without a memory tool the agent can call, it can only say that memory is unavailable and continue.
+- It decides when to recall and what to save. How well entries are found again depends on the backend's own search.
+- It does not resolve contradictions by itself. It surfaces them with their dates and asks the user which one holds.
+- What happens to an entry the user asks to remove depends on what the backend supports.
+- This skill does not replace environment-specific validation, testing, or expert review.
+- Stop and ask for clarification if required inputs, permissions, or safety boundaries are missing.
+
+## Security & Safety Notes
+
+- The skill contains no shell commands and makes no network calls of its own. It reads and writes memory only through the memory tool the user has already connected.
+- Never save secrets, tokens, passwords, or personal data into memory, and never write credentials into an entry.
+- A hosted memory backend stores entries outside the local machine. Choose the backend with that in mind.
+- When the user asks for an entry to be removed, close or remove it as the backend allows, and confirm what was removed.
+
+## Common Pitfalls
+
+- **Problem:** The memory tool is unavailable or failing.
+  **Solution:** Proceed without memory, say so in one line, and do not retry in a loop. Save the pending decision as soon as the tool is back, rather than dropping it.
+- **Problem:** Recall returns nothing.
+  **Solution:** Run one broader query, then continue without memory. An empty result is information: the topic is new, so a decision made now is worth saving.
+- **Problem:** Recall returns too much.
+  **Solution:** Keep the entries that match the current project and task; ignore the rest rather than pasting them into context.
+- **Problem:** Two entries disagree.
+  **Solution:** Show both with their dates and ask which holds. Do not resolve the conflict silently.
+- **Problem:** A save is rejected or filtered by the backend.
+  **Solution:** Report it once. Do not rephrase the same fact repeatedly to get it through.
+
+## Related Skills
+
+- `@memory-systems`: when designing the memory architecture itself (short-term, long-term, graph-based) rather than the habit of using it.
+- `@context-engineering`: when setting up rules files and session context, which this skill complements with rules for long-term memory.
+
+## Additional Resources
+
+- [Upstream repository](https://github.com/mnemoverse/agent-memory-discipline) (CC0-1.0)
+- [Agent Skills overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview)
+- [Claude Code skills](https://code.claude.com/docs/en/skills)
+- [Model Context Protocol](https://modelcontextprotocol.io), for connecting memory servers
+
+*Written and maintained by the team behind [Mnemoverse](https://mnemoverse.com), which is one hosted implementation. The rules above are deliberately backend-neutral and were written to be useful without it.*

package/bundled-skills/agent-memory-discipline/references/entry-format.md

@@ -0,0 +1,37 @@
+# Memory entry format
+
+Reference for Step 3 and Step 4 of the skill. Use fields when the backend has them; otherwise write the same information into the text of the entry.
+
+## A new entry
+
+| Part | What to write | Example |
+|---|---|---|
+| What | One sentence, the decision or observation | Project uses pnpm, not npm. |
+| Why | The reason, briefly | Lockfile conflict between npm and pnpm. |
+| When | The date it became true | 2026-08-11 |
+| Source | Where it came from | Stated by the user in the session |
+| Scope | Where it applies | All packages in this repository |
+
+As a single line:
+
+```text
+Project uses pnpm, not npm. Stated by the user on 2026-08-11 after a lockfile conflict. Applies to all packages in this repo.
+```
+
+## Closing an entry that stopped being true
+
+Do not delete it. Add an end date and a pointer to what replaced it, then write the new entry alongside.
+
+```text
+[closed 2026-06-30, replaced by "State management uses Zustand"] State management uses Redux. Decided in the January architecture review.
+State management uses Zustand. Migrated in June after the bundle size review. Applies to all new components.
+```
+
+## Evidence and policy
+
+Mark which kind an entry is, so a single observation is not read later as a rule.
+
+```text
+[evidence] The integration suite failed twice against staging on 2026-08-19.
+[policy] Integration tests use a local container; staging is off limits. Confirmed by the user on 2026-08-20.
+```

package/bundled-skills/antigravity-maintainer-batch-release/SKILL.md

@@ -115,7 +115,7 @@ Use `data/specialized-plugin-candidates.json` for specialized-plugin membership
 
 Treat the current catalog and the legacy user-site bridge as one public system:
 
-- Current catalog: `sickn33/agentic-awesome-skills` at `https://sickn33.github.io/agentic-awesome-skills/`.
+- Current catalog: `sickn33/agentic-awesome-skills` at `https://aaskills.tech/`.
 - Legacy bridge: `sickn33/sickn33.github.io` at `https://sickn33.github.io/antigravity-awesome-skills/`.
 
 For SEO, indexing, Pages, redirect, or infrastructure changes:
@@ -163,7 +163,7 @@ Every stable or prerelease version requires full release alignment. Creating the
 5. Merge that release PR through its required checks, update local `main` to equal `origin/main`, and wait for every source, release, or canonical-sync PR in the release path to close. Re-run the release-state and plugin gates if protected `main` moved.
 6. Run `npm run release:publish -- X.Y.Z`. It must resolve exactly one merged release PR from the same repository, authored by the repository owner, with base `main`, exact title `chore: release vX.Y.Z`, and head branch `release/vX.Y.Z`. Zero or multiple candidates fail closed; never select the newest approximate match. The command then verifies that exact protected merge before creating or reusing the tag and GitHub Release.
    The npm publication workflow must first check out protected `main`, verify that the peeled release tag is an ancestor of current `origin/main`, validate the version directly from the tagged `package.json`, and only then check out or execute tag-controlled code. It has no manual-dispatch bypass.
-7. Wait for publishing workflows, then bind every proof to the exact released commit: verify the tag/ref, GitHub Release, npm version and intended dist-tag, required CI, CodeQL, and the explicitly dispatched release-only Pages build from the exact immutable `vX.Y.Z` tag. Never dispatch Pages from `main` or another branch. Verify live `llms.txt`, `skills.json`, catalog and plugin routes, and the legacy redirect bridge; do not accept a successful run for a different SHA.
+7. Wait for publishing workflows, then bind every proof to the exact released commit: verify the tag/ref, GitHub Release, npm version and intended dist-tag, required CI, CodeQL, and the release-tag Pages build from the exact immutable `vX.Y.Z` tag using `deployment_target=release`. Never manually dispatch the release-tag build from `main` or another branch. A separate `deployment_target=main` dispatch may publish a protected main commit after source and canonical-sync work completes; it must verify current-main identity before build and again before deploy. Canonical-sync commits marked `[skip pages]` are never dispatched by canonical synchronization. Verify live `llms.txt`, `skills.json`, catalog and plugin routes, and the legacy redirect bridge; do not accept a successful run for a different SHA.
 8. After npm confirms `X.Y.Z` as the published dist-tag, discover every already-configured local AAS MCP host from its real configuration and update each one to the exact same package version before declaring the release complete. Updating existing AAS host entries is part of the release; creating a previously absent host configuration still requires explicit authorization.
    - Use the published package's `aas mcp configure` two-pass flow: first preview the change, then repeat the identical command with its approval digest. Supply absolute host-config, cache, and backup paths; require a backup when replacing an existing configuration.
    - Pin `agentic-awesome-skills@X.Y.Z` and `--version X.Y.Z`; never use `latest`, reuse an older cached runtime, or create a previously absent host configuration without explicit authorization.

package/bundled-skills/film-crew/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: film-crew
+description: "Turn a one-line AI video idea into a shot list and per-shot, model-ready prompts via a film crew (director, DP, gaffer, editor, script supervisor). Also fixes failing video prompts and diagnoses bad clips before a reroll. Works with Wan, LTX, Kling, Veo, Seedance, Hailuo, Runway."
+category: media
+risk: safe
+source: "https://github.com/HEOJUNFO/ai-film-crew/tree/533f61be2741c10932c6c86e47777cac9ffe3fe4/skills/film-crew"
+source_repo: HEOJUNFO/ai-film-crew
+source_type: official
+date_added: "2026-09-25"
+author: HEOJUNFO
+license: MIT
+license_source: "https://github.com/HEOJUNFO/ai-film-crew/blob/533f61be2741c10932c6c86e47777cac9ffe3fe4/LICENSE"
+tags: [video, text-to-video, shot-list, prompting, film]
+tools: [claude, codex, cursor, gemini]
+---
+
+# Film Crew
+
+You are the producer. You don't write one prompt and hope. You run the idea past a crew,
+each with one job, then hand the user a shot list and one prompt per shot that a video
+model can actually execute.
+
+Most failed AI video clips fail for boring, fixable reasons: two actions in one clip,
+no camera instruction, a subject described differently in every shot, physics the model
+can't do in 5 seconds, or a prompt that describes a *feeling* instead of a *frame*.
+The crew exists to catch those before generation, and to diagnose them after.
+
+## When to Use This Skill
+
+- Use when someone wants to plan an AI video (ad, short, music video intro) before generating clips.
+- Use when a text-to-video or image-to-video prompt keeps failing and needs a diagnosis and rewrite.
+- Use after a bad generation to decide the one change to make before the next reroll.
+- Do not use it to generate, edit or render video; it produces planning documents and prompts only.
+
+## Modes
+
+Pick the mode from the request. Default is **Plan**.
+
+| Mode | When | Output |
+|---|---|---|
+| **Plan** | "make a video of…", an idea, a script, a product | `SHOT_LIST.md` + per-shot prompts |
+| **Fix** | user pastes a prompt that isn't working | diagnosis + rewritten prompt |
+| **Review** | user describes or shares a generated clip | what went wrong + the one change to make before the next reroll |
+
+## Plan mode
+
+### 0. Intake (keep it short)
+
+Only ask what you can't reasonably default. Ask at most 3 questions, in one message.
+If the user said "just go", use the defaults.
+
+| Field | Default |
+|---|---|
+| Platform / aspect | 9:16 vertical, short-form feed |
+| Total length | 15 s |
+| Target model | model-agnostic (write the generic adapter) |
+| Mode per shot | text-to-video, unless the user has a reference image. **Real product or real person → ask for a photo and use image-to-video**; text-to-video invents a different mug. |
+| Audio | none in the prompt, unless the target model generates audio *and* the user wants it in-model (otherwise add it in the edit) |
+
+### 1. Run the crew, in order
+
+Read each role file before running that role. Each role writes its own short section.
+Keep every section terse: the output is a production document, not an essay.
+
+1. **Director** → `references/roles/director.md` — logline, intent, beat sheet with timings, the hook.
+2. **Production designer** → `references/roles/production-designer.md` — the *continuity bible*: locked descriptors for every recurring character, prop and location.
+3. **Director of photography** → `references/roles/dp.md` — per shot: size, lens, angle, height, ONE camera move.
+4. **Gaffer** → `references/roles/gaffer.md` — time of day, key direction, color temperature, practicals, contrast.
+5. **Editor** → `references/roles/editor.md` — shot durations that fit the model's clip length, cut types, first-frame hook, ending.
+6. **Sound** → `references/roles/sound.md` — only if the target model generates audio, or the user will add music/SFX in the edit.
+7. **Script supervisor** → `references/roles/script-supervisor.md` — continuity + feasibility + "unslop" pass. Has veto power: any shot it flags gets rewritten before output.
+
+### 2. Write the prompts
+
+Read `references/model-prompting.md`. For each shot, assemble the prompt from the crew's
+decisions in this order, then run it through the target model's adapter:
+
+```
+[shot size + lens + camera move] of [subject, verbatim from the continuity bible]
+[doing ONE visible action, present tense], in [location, verbatim from the bible].
+[lighting from the gaffer]. [style / film look]. [audio line, only if supported]
+```
+
+This order is the generic default. When the target model's adapter specifies a different
+order, **the adapter wins**.
+
+Rules that apply to every model:
+- One subject action and one camera move per shot. Two actions = two shots.
+- Paste continuity descriptors **verbatim** in every shot: the FULL version when the whole subject is in frame, the TIGHT version for close-ups. Never paraphrase either.
+- Describe what the camera sees, not what the viewer should feel. "Tense" is not a frame; "sweat on the upper lip, jaw clenched, eyes on the door" is.
+- No on-screen text, logos or readable signage unless the model is known to render text. Add text in the edit.
+- Keep each shot within the model's max clip length (see adapter). Plan for 1–2 s of handles.
+- Image-to-video: describe only motion and camera. Don't re-describe what's already in the image.
+
+### 3. Output
+
+Write `SHOT_LIST.md` using `references/templates/shot-list.md`. If the user is working in a repo
+or folder, save it there; otherwise print it. Include:
+- the crew sections (short),
+- the shot table,
+- one copy-paste prompt block per shot (plus negative prompt where the model supports it),
+- a **reroll plan**: for each shot, the most likely failure and what to change if it happens.
+
+End with one line telling the user which shot is highest-risk and why.
+
+## Fix mode
+
+1. Read `references/roles/script-supervisor.md` and `references/unslop.md`.
+2. Name the specific problems in the pasted prompt (max 5, most damaging first).
+3. Rewrite it using the Plan-mode prompt order. If it contains two actions, split it into two shots and say so.
+4. Show before → after. Keep the user's intent; change the mechanics.
+
+## Review mode
+
+Read `references/reroll-review.md`. Diagnose from what the user describes or shares
+(frames, a clip, a description). Classify the failure, then give **one** change to make
+before the next generation. Changing five things at once means you learn nothing from the reroll.
+
+## Limitations
+
+- It plans, diagnoses, and rewrites prompts; it does not generate, edit, or render video.
+- Output quality depends on the target model's current clip limits and prompt handling, which change often. Check the model's own docs before trusting an adapter's defaults.
+- Continuity locks hold only as far as the model honors them; long sequences may still drift and need a reroll.
+- It has no way to see a clip unless the user shares frames, a file, or a description of what happened.
+
+## Tone
+
+Talk like a working crew: specific, fast, no hype. Use real film vocabulary (it helps the
+models), but explain any term the user might not know in 3–5 words the first time.

package/bundled-skills/film-crew/references/model-prompting.md

@@ -0,0 +1,89 @@
+# Model prompting adapters
+
+The crew's decisions are model-agnostic. This file turns them into the phrasing each model
+family tends to follow best.
+
+> Video models change every few months. Treat these as conservative defaults, check the
+> model's current docs for hard limits (clip length, resolution, prompt length), and send a
+> PR when something here goes stale.
+
+## Generic adapter (use when the model is unknown)
+
+One paragraph, present tense, concrete, in this order:
+
+1. Shot size, lens, camera move
+2. Subject (verbatim from the continuity bible)
+3. The one action
+4. Location (verbatim)
+5. Lighting
+6. Look / film stock
+7. Audio (only if the model generates audio)
+
+~40–90 words. Longer is fine for open-weights models; shorter for models with prompt
+rewriting ("prompt enhancement") turned on.
+
+## Open-weights models (Wan, HunyuanVideo, LTX-Video, Mochi, CogVideoX…)
+
+- **Be literal and long.** These models generally reward detailed, chronological,
+  paragraph-style descriptions (roughly 60–150 words): what's in frame, what moves, in
+  what order.
+- **Describe motion in sequence:** "…lifts the cup, pauses, then sets it down."
+- **Use the negative prompt** if your workflow exposes one:
+  `blurry, warped hands, extra fingers, morphing, flicker, text, watermark, logo, static frame, oversaturated`
+- **Seed discipline:** when rerolling to test a single change, keep the seed fixed so you
+  isolate the effect of the change.
+- Clip length is bounded by frame count and VRAM. Plan short shots and cut them together.
+
+## Kling
+
+- Structure: subject → movement → scene → camera → lighting → atmosphere.
+- Keep it tighter than open-weights prompts; one clear action.
+- Clip length is chosen from presets (commonly 5 s or 10 s). Plan with the editor's
+  fixed-length rule.
+- Negative prompt: use it where your version/interface exposes the field.
+- Some newer versions can generate audio. If yours does and the user wants in-model
+  sound, apply the audio rules from the Veo section; otherwise keep sound out of the prompt.
+- Image-to-video: describe only the motion and the camera; the image already carries the
+  look.
+
+## Veo (and other models that generate audio)
+
+- Write sound explicitly, as its own sentence(s):
+  - Dialogue: `The barista says, "Sorry — my fault."`
+  - SFX: `SFX: paper cup hits tile, liquid splash.`
+  - Ambience: `Ambient café murmur, espresso machine hiss.`
+- Keep dialogue short (one line per shot). Long lines drift out of sync.
+- Camera and lens terminology is followed well; use it.
+
+## Seedance and other multi-shot-capable models
+
+- If your version supports multiple shots in one generation, you can write the sequence
+  explicitly: `Shot 1: … Cut to Shot 2: …`. Keep each shot to one action and restate the
+  character descriptors in each.
+- If you need tight control, still generate shot by shot and cut in the edit.
+
+## Hailuo / MiniMax
+
+- Camera moves can be stated plainly in the prompt ("slow push-in", "pan left"). Some
+  versions and front-ends accept bracketed camera commands such as `[Push in]` or
+  `[Pan left]`; use them if your interface documents them.
+- Keep one move per shot even when the syntax allows chaining several.
+
+## Runway / Luma / Pika / Sora-style prompt-enhanced models
+
+- These often rewrite your prompt. Put the non-negotiables first (subject descriptors,
+  the action, the camera move) and keep the prompt short enough that the rewrite doesn't
+  bury them.
+- For image-to-video: motion + camera only.
+
+## Image-to-video (every model)
+
+The most reliable way to keep a character consistent across shots:
+1. Generate or pick **one** reference still per character/location.
+2. Use it as the first frame for every shot where they appear.
+3. In the prompt, describe **only** what moves and how the camera moves.
+
+## Clip length cheat sheet
+
+Check your model's current limit. Common ranges in practice: 4–10 s per generation.
+The editor role should never plan a shot longer than the limit minus ~1 s of handles.

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.