Short-Drama Creation Router
This skill handles project initialization, cross-stage routing, production form, and the Dashboard. The content for each stage is completed by the corresponding owner.
Quick Start
All projects uniformly use the
creator-first workflow: each episode maintains as needed
,
,
,
,
, and does not establish parallel structured creative truths.
For specific writing conventions, see
Five Creation Documents.
Routing
| What the user wants to do | owner / action |
|---|
| Develop ideas, series commitments, adaptations, and episode maps | , only when the user needs it |
| Identify episodes from existing full scripts/drafts | builds a temporary index based on actual boundaries |
| Analyze long-form source material | $short-drama-novel-analyze
|
| Write or revise a single episode script | → |
| Break down characters, models, locations, props | → |
| Write asset image prompts | $short-drama-image-prompts
|
| Create shots and frozen keyframes | → |
| Write video/timeline music prompts | $short-drama-video-prompts
|
| Actually generate media | , preview first, then explicit confirm, then run |
| Cut produced material into a finished film | → and |
| Review or validate | , only when the user names it |
| Initialize, Dashboard, archive named documents | This skill |
Long-form material analysis and episode indexing in
are an optional analysis workspace and do not participate in single-episode layout determination; writing any episode still maintains only the five creator-first Markdown files for that episode.
An existing script can be directly broken down into assets; existing visual facts can be directly written into image prompts or storyboards; existing storyboards can be directly written into video prompts.
Do not fabricate upstream steps to complete a nominal pipeline.
The five creation documents record script, visuals, and prompts; the editing list records choices and post-processing after material production.
When modifying story, shot responsibilities, or upstream duration declarations, return to the document responsible for that content.
Executing Requests
- Locate the project or materials given by the user; only read the direct input for the current task.
- Hand the full scope named by the user to the corresponding owner; batches only control context and automatically continue.
- Ask only when there is a real creative fork; do not ask creators about schema, directories, transactions, or checkers.
- When the scope is complete, report in one go the completed content, key decisions, real pending items, and optional next steps.
- Do not automatically start review, archive, or production that the user did not name.
- When a request spans visual design, image prompts, storyboard, or video prompts, perform a visual dependency reconciliation based on the current five documents before ending; do not leave the later-completed branch outside the old references of the other just because image prompts and storyboard can run in parallel.
- When a video prompt request encounters "input reference image: none" or still carries "reference image pending", first route the storyboard owner to check existing images in the project and refresh the binding. If there is a matching image, continue with the same request; if a necessary image is missing, stop and list it. When stopping, present all three paths together: put existing images into the project bound as ; have the creator generate images in their own tool and this round first write a per-shot image attachment plan using , then produce video prompts as usual; or explicitly switch to text-to-video. Producing reference images with this kit requires adapters and credentials outside the project, and is only one implementation of the first path—do not present it as the only entry point, and do not give only the two options "generate reference image / text-to-video". Do not treat "no manual specification" as an explicit choice of text-to-video. If shots still lack "visual basis" this round, also backfill from the frozen keyframes that have been written; the two bases describe the same frame, so don't fill in only one.
- When the user names a target video model in the session ("write according to MiniMax H3", "use Seedance 2.5") and 's is still , first write this choice along with its native duration, reference method, and content language into the archive, then continue with downstream stages. A one-line mention in the session that is not recorded in the archive will fall back to the generic path next round, and the dialect and duration will need to be re-guessed.
Initialization and Dashboard
Run when project configuration is needed:
bash
python3 {skill-directory}/scripts/project_tool.py init ./my-drama --title "示例短剧"
When the direct input has confirmed the creator's description language, prompt language, aspect ratio, episode count, or single-episode target duration, pass the corresponding
,
,
,
,
on the first
; omit only unconfirmed items, and do not leave confirmed facts in the Brief as
in the configuration. When writing an accepted production profile, the status is always
;
only means not yet decided, without creating an intermediate state.
only creates configuration and empty directories; documents are written into
at the first creation, without pre-creating empty files.
When the project has already been created and the user later decides on a target video model, write the choice into the archive and simultaneously show its impact on duration range, reference method, and content language. The archive only accepts published and accepted creator decisions, so it is three steps, not one. First write a decision record line (
is the object itself that will land into
, do not wrap it in another
):
jsonl
{"decision_id":"CD-H3","status":"accepted","target_locators":[{"src":"short-drama","field":"/creator_authority/production_profile/choices"}],"accepted_value":{"target_video_model":"minimax-h3","video_prompt_dialect":"minimax-h3","video_prompt_language":"en","native_duration_seconds":{"min":4,"max":15},"supported_generation_modes":["text","first_frame","first_last_frame","reference"],"audio_generation":"same_pass"}}
Then publish, accept, and write:
bash
python3 {skill-directory}/scripts/project_tool.py publish <project> --owner short-drama \
--artifact-id AR-PROFILE --output "创作者决策/production-profile.jsonl=输入/profile.jsonl"
python3 {skill-directory}/scripts/project_tool.py accept <project> --artifact-id AR-PROFILE --decision accepted
python3 {skill-directory}/scripts/project_tool.py set-authority <project> \
--field /creator_authority/production_profile/choices \
--decision-ref "创作者决策/production-profile.jsonl#CD-H3"
The values for each field are given by the matched model dialect: the MiniMax H3 / Seedance dialect files of
$short-drama-video-prompts
both write recommended profiles. After writing, use
to verify that
has appeared.
For project location and safe writes, see Runtime Preflight. When the user explicitly requests Dashboard, run:
bash
python3 {skill-directory}/scripts/dashboard_server.py --workspace <workspace> --port 0 --detach --open
makes the service process run independently from the current shell; session end, terminal close, or agent exit will not take it away, so the link remains valid throughout the creation period. The running address, port, and pid are recorded in
<workspace>/.short-drama/dashboard.json
(readable only by the owner), with logs in
in the same directory:
bash
python3 {skill-directory}/scripts/dashboard_server.py --workspace <workspace> --status # print the current link
python3 {skill-directory}/scripts/dashboard_server.py --workspace <workspace> --stop # stop
When the same workspace already has a running Dashboard, starting again will only print the same link and will not open a second port; add
if you really need to change the port or token. Without
, behavior is unchanged: it runs in the foreground and Ctrl-C ends it.
Dashboard displays and edits creation files; it is not responsible for workflow orchestration or media production.
Project-Level Creative Decisions
When production form, visual direction, playback surface, and episode-length goals genuinely constrain multiple stages, show the choices and impacts, then let the user decide.
Look Development is an optional branch, not a fixed threshold for entering image prompts or storyboards.
Read only one piece of relevant knowledge per question:
- Rule hierarchy and owner routing: Rules & Routing Index
- Output language, stable IDs, ownership, and security boundaries: Contract & Ownership
- Form differences of live-action, 2D, 3D, ink-wash, Q-version, and Chinese animation: Production Form Profiles
- When representative frames need comparison: Look Development
- What reference images can control: Reference Roles
- Occlusion, delayed reveal, and audience-knowledge timing: Audience Reveal
- Responsibilities of master, pickup, and alternate versions: Pickup & Alternate
Production and Delivery Boundaries
External production always keeps
preview -> explicit confirm -> run
. Archiving only copies the current documents and finished products named by the user, excluding private inputs, credentials, absolute paths, and hidden runtime state; it does not fabricate approvals, hashes, or a second set of content for the archive.
When the user asks "how do I export/deliver after it's done", use
to package the current state:
bash
python3 {skill-directory}/scripts/project_tool.py export <project> --out <outside-project-directory>
It copies the existing five creation documents for each episode and
to
, with
and
, and excludes
,
, and
. To include only part, add
(repeatable); to include only text, add
; to overwrite an existing directory, add
.
must be outside the project.
is a
snapshot of the current state, and
in the manifest is always
: it does not claim any review or creator acceptance. For a formal delivery package with approval evidence, only the
/
path exists.
Installation and Maintenance
Run
python3 scripts/selftest.py
only during installation, upgrade, or troubleshooting.