zy-cinematic-realism (DREAM DIRECTOR): a Scene Master workflow for cinematic AIGC prompts

What zy-cinematic-realism solves, and who is meant to use it

Most prompt collections hand you adjectives. DREAM DIRECTOR's README states the project is not a new image model and not a bag of universal cinematic words. It is a workflow for ChatGPT and Codex that first fixes who is in the frame, which story moment is being shown, what the action is, where the scene sits, where the camera is, how the frame is composed, how light falls, what props are present, the time of day, the weather and the constraints. Only then does it translate that plan into a prompt for a specific target model.

The intended user is someone who can describe a scene in a sentence but cannot predict how four different image models will interpret it. The README's minimal input is stated plainly: who, where, what just happened, the small action happening now, and what you least want. That is a low floor. The ceiling is a continuity workflow for multi-shot sequences, which is a different kind of user entirely.

The project keeps two names on purpose. The public brand is 造梦师 / DREAM DIRECTOR, while the technical name stays zy-cinematic-realism and the invocation stays $zy-cinematic-realism, so that install paths and explicit calls keep working. If you go looking for a folder called dream-director, you will not find one.

Scene Master, Creative Grammar and the Model Compiler pipeline

The architecture is a four-stage chain: Scene Master, Creative Grammar, Model Compiler, Result Repair. Scene Master is described as the single source of truth. It locks the picture design first. Creative Grammar then decides style, cinematography and staging. Model Compiler translates the result into the native language of one target model. Result Repair handles failures after the fact.

The v2.0.0 release changed this from a two-step flow (idea, then skill, then final prompt) into the compiler chain, with adapters for GPT Image 2, Midjourney, Seedream 5.0 Pro and Nano Banana. The rule the README puts in capitals is that model syntax may change but scene logic may not. Transcoding is allowed to alter sentence structure, information density, parameter placement and editing wording. It is not allowed to quietly change the character, the action, the location, the light or the narrative relationship.

That constraint is the whole design. A compiler that silently reinterprets your scene is worse than no compiler, because the drift is invisible until you compare outputs. The README also draws a line around what the Router is: a task heuristic, not a permanent ranking, and it explicitly does not claim any model is best. Model capabilities and interfaces change, and the README says so.

Creative Grammar is where the project is most opinionated. It keeps 38 directors' four-axis visual fingerprints and adds 16 style cards and 8 cinematography cards. When a supported director is named, the final prompt generates four consecutive lines after the scene facts and before detailed camera design: lighting and contrast signature, color and exposure signature, lens and camera signature, composition and spatial signature. The README requires that at least three of those axes change structurally against a no-director baseline, and that at least three of these be reselected: the moment, the visual center, the camera position, the figure's scale, and whether environment, figure or object dominates. The test it sets is that the four axes should still be recognizable after you delete the director's name and film titles. That is a real, checkable standard, and it is stricter than most style systems bother to define.

Installing zy-cinematic-realism and running a first prompt

The README does not give a package install command, a pip line or a Docker image. It points to the latest GitHub release as the download, and the repository layout shows the skill living in the zy-cinematic-realism/ directory alongside docs/, scripts/ and the top-level markdown files. Practically, you obtain the repository from the release page and use it as a skill inside ChatGPT or Codex, invoking it by name.

The first real use is a single sentence with an explicit model target. This block is the README's own example, kept in its original Chinese:

请使用 $zy-cinematic-realism：
雨夜便利店里，一个刚下班的女人双手握着热咖啡，不看镜头。
先告诉我适合的模型路径，再为 Midjourney 编译原生 Prompt。
不要广告摆拍、直视镜头和没有来源的轮廓光。

What you should see is a Scene Master first, then a Midjourney-native expression of it. The README says you do not need to know photography parameters in advance, and that the minimum input is who, where, what just happened, the small current action, and what you least want.

Once a scene exists, three follow-up moves are documented. Transcoding keeps the scene facts and swaps the model language:

Transcode：保持女人、便利店、雨夜、热咖啡和不看镜头不变，转成 GPT Image 2.5。

A multi-model pack produces several native versions at once:

Multi-model Pack：同一个 Scene Master，同时输出四个模型的原生版本。

And repair is scoped rather than wholesale. The README's repair instruction uses two capitalized directives:

CHANGE ONLY: camera position, posing, and light hierarchy.
PRESERVE EXACTLY: identity, wardrobe, car, and location.

That last pair is the most reusable artifact in the repository. It works even if you never touch the rest of the skill.

Continuity across shots: Base Lock plus Shot Delta

For an eight-shot sequence, the README describes locking character face, silver commuter armor, an old canvas bag, a folding spear, a station, and warm and cool light sources through the Continuity Bible. Each shot is then generated from the same Base Lock plus one limited Shot Delta that describes only what is new in that shot: an action, a camera position, a change in time.

The stated benefit is reduced drift in face, wardrobe, props, location and light across shots. The stated limit is equally clear: it does not promise identical model output. It makes the changes traceable instead. That distinction matters. If you need pixel-identical characters across a sequence, this workflow is not the tool, and the README does not pretend otherwise.

There is a second constraint buried in the architecture. Because Scene Master is the single source of truth, a Shot Delta that contradicts it is a bug, not a creative choice. The README's framing is that changes must have a documented basis. In practice that means you maintain one canonical description and a list of deltas, rather than eight independent prompts that slowly diverge.

Where DREAM DIRECTOR is the wrong tool

The README states that the skill generates visual plans and prompts inside ChatGPT or Codex, does not lock a specific underlying model, and does not call APIs automatically. If you want a script that takes a scene description and posts it to an image endpoint, this is not that. The Router only considers Flare or Sunburst when the user explicitly asks for API use, and the README notes that this is not a permanent ranking.

Second, the whole system assumes you can describe a scene in natural language and evaluate the result yourself. The documentation's own example of a weak instruction is telling two boxers are fighting fiercely. If you cannot say which round it is, which side of the punch landing you want, what the camera is looking through, and how much motion blur to keep, the compiler has nothing solid to compile. The skill will not invent your story.

Third, the model adapters move with model releases. v2.1.0 migrated Midjourney compilation to the V8.2 baseline and updated prompt compilation, edit model routing, reference image strategy, parameter handling and transcode behavior. v2.1.1 moved the OpenAI baseline to GPT Image 2.5. If you are pinned to an older model version, the current adapters may not match what you have. The README's own migration advice is conservative: test an already-working GPT Image 2 prompt as-is on 2.5 first, keep prompt, reference images, scene facts, aspect intent and constraints consistent, and only repair the specific variable that fails. It explicitly warns against rewriting because the version number changed.

Finally, the README reports that OpenAI's release notes describe latency reductions of up to 50 percent relative to Images 2.0. The README immediately qualifies this: the figure describes latency, not a quality improvement ratio. Do not read it as a quality claim, and do not read it as a measurement of this project.

Alternatives: prompt packs, direct prompting, and ComfyUI graphs

The most direct alternative is a curated prompt pack, a static list of cinematic phrases you paste and edit. The difference in approach is structural. A prompt pack gives you vocabulary with no scene model behind it, so the same phrase means something different in every prompt and nothing prevents you from describing physically impossible light. DREAM DIRECTOR builds a scene description first and treats vocabulary as a later decision. The cost is ceremony: you answer questions about camera, light and constraints before you get a prompt.

The second alternative is prompting the model directly with no intermediate layer. That is faster and keeps full control, and for a single image it is usually the right choice. The workflow earns its overhead when the same scene has to survive a model switch or a multi-shot sequence, which is exactly the case where ad-hoc prompting drifts.

A node-graph tool such as ComfyUI is the third comparison, and the difference is where the logic lives. A graph encodes the pipeline as executable nodes with deterministic wiring; DREAM DIRECTOR encodes it as instructions a language model follows, which is more flexible about phrasing and less reproducible run to run. If you need the same input to produce the same output every time, a graph is the stronger structure. If you need the same scene to be re-expressed in four different model dialects, the compiler approach is the one that scales.

Licence, maintenance and upgrade cost

GitHub reports the licence as NOASSERTION, which means the repository's LICENSE file could not be matched to a standard SPDX identifier. The repository ships both LICENSE and NOTICE.md at the top level. Read both before you build anything commercial on top of it. Nothing here is legal advice, and a file that fails automated detection is not automatically restrictive, but it also is not automatically permissive, and the NOTICE.md file suggests there are attribution terms worth reading.

On maintenance, the last push was on 2026-09-09, and the repository is not archived. The recent release history is dense: v2.0.0 on 2026-08-30 introduced the Model Compiler, v2.1.0 on 2026-09-03 migrated the Midjourney adapter to V8.2, and v2.1.1 on 2026-09-09 updated the GPT Image 2.5 baseline. That cadence is driven by model releases rather than by the project's own roadmap, and that is the upgrade cost you should plan for. Each time a target model ships a new version, expect an adapter migration and a re-test of your existing prompts. The README's own guidance to test working prompts unchanged before repairing anything is the cheapest way to absorb those migrations. The repository also carries CHANGELOG.md and RELEASE_NOTES.md, so the change history is documented rather than implied.

Editorial conclusion

Adopt it if you already work inside ChatGPT or Codex and your problem is drift between shots or between models rather than raw image quality. Skip it if you need an automated API pipeline, since the README states the skill does not call APIs on its own, or if you want a single-model prompt pack. Before committing, verify three things: whether the LICENSE file grants the rights you need, since GitHub reports NOASSERTION and the repository ships a NOTICE.md; whether the v2.1.1 GPT Image 2.5 baseline matches the model version you actually have access to; and whether the Continuity Bible's Base Lock plus Shot Delta approach holds identity across your own eight-shot sequence.

Frequently asked questions

Official sources

1. Issues
2. popopo-99/zy-cinematic-realism on GitHub
3. README
4. Releases