smixs/visual-skills: Claude Skills That Write Film Prompts Instead of Adjective Lists
AI film director skills for agents: cinematic dramaturgy (Murch, blocking, montage) + exact prompt syntax for Seedance 2.5, Kling 3.0 Turbo/Omni, Veo 3.1, Nano Banana 2, GPT Image 2.5.
At a glance
- What is it?
- Two Claude Skills, video and image, that push an agent through dramaturgy rules and model-specific prompt syntax for Seedance, Kling, Veo, Nano Banana and GPT Image. The interesting part is the ban list and the shot card, not the model coverage.
- Who is it for?
- Adopt it if you already storyboard by hand and want an agent to hold the same constraints across Seedance, Kling, Veo, Nano Banana and GPT Image prompts, and if you accept that the output is a starting draft a human still edits. Skip it if you want a one-shot generator for a single pretty clip, or if your work is a real production with continuity across many shots, because the skill governs prompt text rather than the footage those prompts produce.
- Can I use it commercially?
- Yes, with credit. CC-BY-4.0 allows commercial use as long as you credit the authors and indicate what you changed. It is written for creative content, so check how it applies to any code.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure mode visual-skills is aimed at: prompts that describe a mood instead of a shot
The README opens with a side-by-side. On the left is the prompt most people write: a man in a kitchen at night, epic lighting, moody atmosphere, 4k. On the right is what the skill produces: an emotion, a named object, a final image, and three timed shots with focal lengths and a stated reason for the camera move. The project's own framing is that model syntax is worth nothing until the dramaturgy is there, and it treats the left-hand prompt as four adjectives and zero facts. That is the problem being solved, and it is a writing problem rather than an API problem.
The audience is narrow. This is for people who already know they want a cut at 1.6 seconds and a push-in at 3.4 seconds, and who want an agent to keep that level of specification consistent while swapping between video models. It is not for someone who wants a tool that decides what the film is about. The skill supplies rules for staging, cutting and detail; the desire, the obstacle and the final image still have to come from whoever is directing.
Two skills, one dramaturgy reference, and a hard ban list
The repository ships two Claude Skills. The video skill writes video prompts, the image skill writes image prompts, and both are described as picking the right model for the task and applying that model's exact syntax. The centre of gravity is video/references/dramaturgy.md, which the README calls the heart of the video skill: how films are built, compressed into rules an agent can execute on a clip of 5 to 30 seconds. The model names in the description (Seedance 2.5, Kling 3.0 Turbo and Omni, Veo 3.1, Nano Banana 2, GPT Image 2.5) sit downstream of that file.
The mechanism that does the most work is a prohibition. The README lists banned terms: cinematic, epic, stunning, masterpiece, beautiful lighting, dynamic camera, and the phrase he is sad. The stated reason is that each one is a placeholder for a detail the writer failed to invent, and that none of them renders. Whether or not you accept the claim about rendering, the list functions as a lint pass. An agent that cannot write cinematic has to write a focal length, a light source and a body part instead. That is a much more testable instruction than write a good prompt.
The seven laws: scene formula, details, Murch, selection, staging, rhythm, spec
The README lays out seven numbered laws, described as non-optional. Law 01 is the scene formula: desire plus obstacle plus geometry plus gaze plus rhythm, each named in a single sentence before any prompt text is written. Law 02 requires three physical facts per shot, one environmental pressure, one micro-action of the body, and one sound anchor or visual motif, with the line that he is sad does not render but a jaw does.
Law 03 imports Walter Murch's Rule of Six as a priority order for cuts, with emotion at 51 percent and 3D space at 4 percent, and the note that each item outweighs everything below it combined. The README's own reading of this is pointed: cutting for pace is item three, and serving item three ahead of emotion and story is described as the default behaviour of every model you will ever prompt. Law 04 is the three-jobs rule, where a shot must change emotion, advance action or increase pressure, and a shot that does none is deleted however pretty it came out, with beautiful establishing shot explicitly rejected as a job.
Law 05 bundles staging heuristics attributed to Fincher (every camera move answers what changed, otherwise the camera is static), Spielberg (the viewer always knows where the hero, the threat and the exit are) and Kurosawa (one weather, one pressure, carrying the scene). Law 06 gives montage as long, shorter, shorter, pause, impact, with beat maps for 15, 30, 60 and 90 seconds labelled Hook, Pressure, Crack, Impact, Aftermath, and the instruction never to skip the Crack. Law 07 defines the shot card: fourteen fields per storyboard row, including framing, composition, camera, movement reason, eye-trace, duration, cut type, sound and light, where an empty field counts as missing direction. Per piece there are exactly five anchors: one emotion, one motif, one object, one break, one final image.
Two things are worth flagging. First, the laws are heuristics borrowed from editing theory and from named directors, not measured results, and the README presents them as rules rather than as findings. Second, the numeric weights in the Murch table are Murch's, reproduced in the README, not anything this project measured.
Getting it installed: a Claude Skill, not a Python package
There are no build steps, no dependency manifest and no CLI in the material. A Claude Skill is a folder of instructions and reference files that an agent loads, and this repository is structured that way: a video directory with references/dramaturgy.md, an image directory, a LICENSE, README.md and README.ru.md, and an assets directory holding hero.webp and dramaturgy-banner.svg. The practical install is to place the skill folders where your agent looks for skills and let it read them. The README carries a Claude Skill badge linking to the agent skills documentation, and a skills.sh badge, but it does not print an install command in the portion available here, so treat the exact placement path as something to confirm against the repository rather than something stated.
The configuration surface is the skill content itself. The keys you would actually edit are the ban list (the terms the agent is forbidden to write), the fourteen shot-card fields, and the five anchors per piece. If your house style forbids a particular camera move or requires a specific aspect ratio, that is where it goes. There is no settings file, no environment variable and no runtime flag described in the material, which means every change is a text change to a reference document, and version control is your only rollback.
What the skill cannot do: it governs prompt text, not footage
The most honest limitation is structural. This project produces prompts. It does not call Seedance, Kling, Veo, Nano Banana or GPT Image, it does not render, and it cannot see the result. Every rule about eye-trace, screen plane and 3D space is an instruction to a model that may or may not honour it. The README's example shot list is a specification of intent; whether the generated clip shows the fridge light dying on his face is a question the skill has no way to answer.
There is a second limitation in the rules themselves. The ban on cinematic, epic and beautiful lighting removes a class of words that some models do respond to, and the project's position is that they do not render. That is a design bet, and it is stated as a rule rather than as a result of testing. If your own experience with a given model is that a broad style word reliably shifts output, the ban list will feel like it is costing you a lever. The fix is to edit the list, which is allowed and is the point of keeping rules in a text file.
A third boundary: the dramaturgy reference is explicitly compressed for clips of 5 to 30 seconds, with beat maps up to 90 seconds. Longer work, or work needing continuity of wardrobe, set and character across many shots, is outside what the material describes. The skill will happily write you a shot card for each scene, but nothing here tracks whether the same jacket appears in shot 4 and shot 40.
Compared with plain prompt-engineering note collections
The obvious alternative is a personal notes file or a prompt library: a document of tips, model quirks and example prompts that you paste into a chat when you need it. The difference in approach is enforcement. A notes file is advice the model may skip. A Claude Skill is loaded as operating instructions with a reference document the agent is meant to consult, and the ban list plus the fourteen required fields are the closest thing to a checklist that a text-based tool can have. The notes file also tends to be organised by model, so its structure follows vendor syntax. This project is organised by film craft first, with model syntax applied afterwards, which is the distinction its README keeps returning to.
The trade-off runs the other way too. A notes file can hold anything, including the one weird trick that works on a single model for a single shot type. A rule set with seven laws and a ban list is a filter, and filters discard. If your workflow depends on a banned word or on a shot that fails the three-jobs test but earns its place for another reason, you are arguing with the skill rather than using it.
Licence, maintenance and what a fork actually costs
The licence is CC-BY-4.0, which is a content licence rather than a software licence. It permits sharing and adaptation with attribution. For a folder of markdown instructions that is a reasonable fit, and it is more permissive than a copyleft code licence would be for something people will copy into their own agent setups. The practical consequence is that if you redistribute the skill files, in a fork, in an internal template, or inside a product, you carry an attribution obligation. How that obligation is satisfied in your specific case is a question for your own counsel; the material here only states the licence identifier.
Maintenance cost is mostly editorial. The repository's topics list names Seedance, Kling, Veo, Nano Banana and GPT Image, and the description pins versions: Seedance 2.5, Kling 3.0 Turbo and Omni, Veo 3.1, Nano Banana 2, GPT Image 2.5. Model syntax moves faster than film craft, so the dramaturgy file should age slowly while the model-specific prompt sections need revisiting whenever a vendor changes its parameter names or adds a control. There are no releases retrieved for this repository, so there is no changelog to diff against and no versioned artefact to pin. If you fork it, the maintenance burden you are taking on is tracking those five model families yourself.
Editorial conclusion
Adopt it if you already storyboard by hand and want an agent to hold the same constraints across Seedance, Kling, Veo, Nano Banana and GPT Image prompts, and if you accept that the output is a starting draft a human still edits. Skip it if you want a one-shot generator for a single pretty clip, or if your work is a real production with continuity across many shots, because the skill governs prompt text rather than the footage those prompts produce. Before installing, read video/references/dramaturgy.md and check whether the ban list and the fourteen-field shot card match how you already work, then confirm the CC-BY-4.0 attribution requirement against how you plan to redistribute the skill files.
Community notes