seedance-prompt, a four file skill whose flagship example shows four of its seven sections

Four markdown files, three names, and no version

The repository root has four entries. A readme, a skill file, a licence, and a directory of three reference documents. The readme's own structure diagram names exactly those four things, so the documentation and the repository agree.

There is no code, no manifest, no test, no continuous integration configuration, and no way to detect a primary language for the project, which is the correct answer for a folder of prose. The deliverable is a set of instructions that another program reads and follows.

The three names are worth noting. The repository is named after one video model. The skill you invoke has a different name describing what it does. And the readme's top-level heading is a filename with a file extension, which reads as an export artefact rather than a title.

There is also no version. No releases, no tags, no version in any file, and the last push to the default branch is 4 August 2026. For a project whose entire content is prose, that means there is no way to tell which revision of the methodology you have, and no changelog describing what changed between them. The reference files are the part most open to editing, and nothing records when.

The first install path gives a directory and the second gives nothing

The first installation method is a single command:

git clone https://github.com/zhouwei713/seedance-prompt.git \
  ~/.hermes/skills/creative/realistic-video-prompting

It clones the repository into a nested path inside a hidden directory in your home folder, three levels deep, ending in a directory named after the skill's function rather than the repository. The readme then says to restart the host application or open a new session, and gives the name to invoke.

The second method covers everything else. If you do not use that particular host, you can put the skill file into any of four named agent environments, or any other environment that supports skills or long prompts. What it does not give is a directory, a filename convention, a restart instruction, or a statement of what the host expects the file to be called. Method one has all four.

The third method is not an installation at all. It is a reading list: the skill file and the three reference documents, named, for people who want the methodology without running it.

The asymmetry matters because method one is a specific host and method two is the general case, and the general case is the one most readers will use. The one-line instruction is also the only one that tells you where the thing goes.

The flagship example demonstrates four of the seven sections the method requires

The method section says the skill breaks a video idea into seven parts, and it lists all seven: the main character, the location, the visual style, the camera work, the timeline, the audio, and the goal.

The worked example at the top of the readme is the thing a reader copies. It has four blocks. The main character, the location, the camera work, and the timeline.

So three of the seven required sections are missing from the example. The visual style section is absent, which is notable because it is the section the method's own vocabulary lives in. The audio section is absent, which is one of the seven problems the readme says it solves. And the goal section is absent, which is the one that states what the footage should end up looking like, and that is the section that would have told a reader which of the five camera profiles was chosen and why.

The second example is thinner still. It shows a device-defect block and three timeline beats, with no character, no location section, and no audio.

The gap is not fatal, because the method section is a complete specification and a reader who follows it will produce all seven. It matters because the examples set expectations, and the most-copied artefact in the file omits the three sections that are hardest to write.

Two of the seven named problems never appear in either example

The readme lists seven reasons a generated video looks fake. Camera movement too steady. Frames too clean. Characters posed. Scenes turning into coffee shops and shopping streets. Audio not matching the picture. Shots that do not advance in time. And characters changing face, clothes, or hairstyle between shots.

The last two are the ones this kind of method is uniquely positioned to fix, and the one after that, audio, is the one most video models handle worst.

None of the three appears in either worked example. The character block in the first example does include an explicit consistency instruction, telling the model to keep the same identity, clothing, hairstyle, and appearance throughout, so consistency is at least gestured at. Ambient sound is not mentioned anywhere in either example, and the timeline beats in both examples are visual only: steam crossing a leg, a shirt on a washing line, a cat walking past, the camera dropping to the ground and cutting to black.

Those beats are good. The cat is exactly the kind of small unplanned event the method says creates realism. But every one of them is something to see, and none of them is something to hear, in a file whose seventh section is about audio.

The realism vocabulary is five cameras and every entry is a list of defects

The device library is the core of the method and it is worth reading closely, because the entries are constructed the same way. Each one is a list of things that are wrong with a camera.

A consumer digital video camera from the 2000s contributes compression artefacts, faded colour, handheld shake, and autofocus hunting. A tape camera contributes scanlines, colour bleed, a burned-in timestamp, and low resolution. Super 8 film contributes grain, vignetting, scratches, and stuttering at eighteen frames a second. A phone contributes a vertical frame, high dynamic range processing, electronic stabilisation, and a finger crossing the edge of the lens. A surveillance camera contributes a high angle, a low frame rate, a timestamp, and no sound.

Four of the five entries are entirely negative. The phone entry is the interesting exception, because it mixes a format decision with a processing artefact and a physical imperfection, and those three are different in kind: you cannot undelete a finger, you cannot unshoot vertical, and you cannot remove the processing.

The surveillance entry is the only one with a behavioural absence rather than a visual defect, and it is the only one that would produce a genuinely different kind of clip rather than a different-looking version of the same clip.

The atmosphere table is called a translation table and has four rows

The second library takes abstract words and turns them into things a camera can see. It is described as a translation table, which sets an expectation of coverage.

It has four rows. Warmth becomes light through leaves, fabric moving slightly, steam from a cup, a person brushing hair back. Loneliness becomes a large amount of empty space, an empty street, cold fluorescent light, the echo of footsteps. Tension becomes a flickering tube, corridor shadows, a person looking back repeatedly, distant metal colliding. The smell of everyday life becomes a vendor's movements, exhaust vapour, several people talking at once, a bicycle bell.

Sixteen cells in total, and each cell is four concrete phenomena. That is a good list. It is also a lookup table with four rows, and a prompt about grief, or about comfort, or about the specific quality of a late afternoon in autumn, has no entry to hit.

The method does not say what happens then. Whether the skill falls back to the model's own judgement, whether it improvises phenomena in the same style, or whether it simply produces nothing for that row is not stated. For a skill whose value is a fixed procedure, that is a branch worth knowing about.

The self-check runs on the prompt, not on the video

The third library is a checklist applied before output. Six questions: is the character consistent, is the location specific, does the camera section contain a physical defect, does the timeline contain an imperfect event, does the audio match the picture, and has any advertising-style camera movement or commercial colour grading crept in.

Five of the six are checks on the text of the prompt, which is what you would expect. The sixth is also a check on the text. The audio question is the only one that could in principle be verified against a result, and the checklist is explicitly applied before output rather than after.

That is a coherent choice, because you cannot check a video you have not generated yet. But it means the whole file is a set of beliefs about what produces realism, verified against nothing. The readme's evidence is two worked examples and a claim that prompts written this way stop looking generated. There is no before-and-after, no third-party comparison, and no note of which models the author actually tested against.

The last checklist item is the sharpest one, and it is the only check that catches the specific failure the readme complains about most: a scene that turns into a coffee shop. That is a check on your own prompt, and it will pass on a prompt that reads correctly and still generates an advert.

Five model families are named and none is checked for timeline support

The skill is described as working for five named text-to-video and image-to-video models, plus others. The repository is named after the first of them.

The timeline format is the part that will not transfer. Both worked examples break a clip into two-second segments with explicit start and end times, and the method's target length is ten to fifteen seconds. So the template assumes you can address a model at sub-shot granularity inside a short clip, with a beat every two seconds.

Video models differ enormously on whether they accept a timeline at all, whether they accept timestamps, and whether they honour a beat structure or treat it as flavour text. The readme does not say which of the five accept a timeline, which treat it as prose, or what to do when a model has a fixed clip length that does not match the ten-to-fifteen-second target.

The same question applies to the audio section. Ambient sound described in a prompt is a request, not a control, and the models named have very different audio capabilities.

None of this makes the method wrong. It makes the claim model-agnostic in a way that cannot hold, and the readme does not qualify it. A user with a model that ignores timelines will get a good character description, a good location, a good camera-defect list, and no temporal structure at all.

Editorial conclusion

Read this if you write video prompts and your output keeps coming back looking like an advert. Do not expect a tool. Four things to take from it. That the realism vocabulary is entirely negative, five cameras described by what is wrong with them, which is the actual insight in the file. That the seven part template is the reusable artefact and the examples are illustrations of two of its sections, so the method section matters more than the examples. That character consistency and ambient sound are two thirds of what the method promises and neither is demonstrated. And that the self-check runs on your prompt before you send it, not on the video after it comes back, so the failure mode the whole file is about is unverified by the file.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. zhouwei713/seedance-prompt on GitHub