Screel
Xlab Digital llc v2.0.0
Publisher description
From the marketplace listing
Screel turns an idea into a finished video without leaving the chat. Describe what you want and Screel builds a project as a sequence of scenes: it writes the storyboard, generates a still image for every scene, and can animate scenes into clips, add AI voiceover narration and background music, and render everything into a shareable video. Reference documents keep your characters, props, products and places consistent from scene to scene, whether they start from an uploaded photo or a picture made in the chat. Consecutive scenes can be derived from one another and animated with an end frame, so one action flows from clip to clip. Clips are generated at a low-cost draft resolution by default, with higher tiers available when you ask. Live widgets show the storyboard, job progress and the final player inline, and every project stays open in the Screel web app for timeline trimming, document editing and collaboration.
Language: English · Automatically detected from descriptions.
Files & skills
File archives
Skill instructions
consistent-characters5.21 KB
---
name: consistent-characters
description: Keep a character, creature, mascot or product looking the same in every scene. Use when a story has a recurring subject, when the user says a character drifted between scenes, when several characters share a scene, or when a subject needs more views (side, back, another outfit).
---
# Consistent characters
## How references reach the picture model
- A reference document is a document with a picture bank. `reference_document_ids` on `generate_image` and `refine_image` attaches EVERY picture in each named document's bank to the generation, in bank order, after any `reference_image_urls` or attached files.
- The picture model receives them as numbered inputs labelled with their bank names ("Ref 1 (front)", "Ref 2 (three-quarter)"). The labels are appended to your prompt, so name bank pictures for what they show, never "image1".
- One generation takes at most 14 reference pictures across every source. Two documents of four pictures each plus a previous still is nine; keep banks lean so a group shot still fits.
- Nothing attaches on its own. A batch item without `reference_document_ids` inherits the call's top-level list, and an item that names its own list replaces it for that item only.
## Build a character reference
1. `list_documents` first. A document for this character usually exists; extend it instead of creating a second one.
2. `create_document` with the reference template: `# Name`, `## What is it?`, `## Description`, `## Reference Images / Media`, `## Consistency`, `## Avoid`. Put the invariant facts in Consistency: species, silhouette, colours, materials, signature items, proportions, age. Put what the pictures must never show in Avoid: other outfits, hats, text, extra limbs, a different palette.
3. Make the canonical view: `generate_image` with `document_id` and `image_name` "front". Prompt for a full-body or three-quarter studio portrait, plain evenly lit neutral background, no props that are not part of the design, no text, no other characters. Match the project's aspect ratio only for scenes; a reference works best at 1:1 or 3:4.
4. Read the result. If it is wrong, fix it with `refine_image` on that picture (`image_url` from the job result, `document_id`, `image_id` to replace in place) before you derive anything from it. Everything downstream copies its mistakes.
5. Derive the other views FROM the canonical one, never from a new prompt: `refine_image` with `image_url` of the canonical picture, `document_id` and `image_name` "side", "back", "face close-up". One call with `images[]` makes them together. Add a view only when the story needs it: a chase seen from behind needs "back"; a talking scene needs "face close-up".
6. Say which documents you created and what they hold. The user sees the bank in the editor.
## Generate scenes against it
- Every scene item that shows the character carries its document in `reference_document_ids`. A scene without it is a scene that drifts.
- In the prompt, call the character by the document's name and describe the action, camera and setting. Do not re-describe the design that the pictures already fix; a long re-description fights the reference. Repeat only what the scene changes on purpose ("Rin, soaked from the rain").
- Prompt the scene, not the reference: "Rin sprints across the rooftop at night, low angle, rain, neon reflections" — not "a character with red hair and a green jacket".
- Keep the same `reference_document_ids` on the `refine_image` calls that touch those scenes. An edit without the reference loses the face.
## Several characters in one scene
- Pass every governing document on that item: `reference_document_ids: [rin, tomas]`. Name both in the prompt and say who is where and what each does, so the model maps the labelled pictures to the right person.
- Two characters fit comfortably; with three or more, trim each bank to its canonical view plus one so the total stays under 14.
- Two very similar designs (two humans of the same age) blur into each other. Give each a distinguishing anchor in the prompt ("Rin, the taller one in green") and keep that anchor in their Consistency sections.
## Variants of one character
- A new outfit, an age change or a damaged state is a new bank picture in the same document, not a new document: `refine_image` on the canonical view ("same character, now in a torn winter coat") with `document_id` and `image_name` "winter coat". Mention the variant in the scene prompt so the model knows which pictures apply.
- A transformation (human to wolf) is a second document, since the two forms share no silhouette.
## When it goes wrong
- The face changed: the scene was generated without the document, or the bank holds pictures that disagree. Re-run that item with `reference_document_ids`; remove any bank picture that contradicts the canonical one (`edit_document` and the editor both can).
- A prop keeps appearing: put it in Avoid and regenerate the canonical view without it.
- Every scene looks like the studio portrait: the prompt is too close to the reference prompt. Prompt the scene's setting, light and action first; the reference supplies the subject.
- Never substitute your own image tool for a scene or a reference view: its output never reaches the project and carries no document behind it.props-and-objects4.7 KB
---
name: props-and-objects
description: Keep a recurring object the same in every scene — a car, a sword, a robot, a phone, a bottle, a piece of furniture, a logo on a product — whether it is held, carried, worn or standing in the set. Use when a story has a hero object, when the user says a prop changed shape or colour between scenes, or when an object must appear next to a character at a fixed size.
---
# Props and objects
## Why a prop drifts
- A prompt describes an object in words, and words leave the model free: "a red sports car" is a different car in every scene. A reference picture fixes the shape, the proportions, the markings and the colour, so the prompt only has to say where the object is and what it does.
- A prop is generated in a scene most often small, partly hidden or in a hand. The model copies what it can see in the reference, so the reference must show the whole object, large and unobstructed.
## Make the reference
1. One `create_document` with the reference template per object. Under **What is it?** say the class in one line ("a 1960s two-seat roadster", "a bronze short sword"). Under **Description** give exact shape, proportions, materials, colour with a plain name, markings, wear, anything printed or engraved. Under **Consistency** write the three or four things that identify it from any angle ("round twin headlights, chrome grille bar, cream body with a red stripe"). Under **Avoid**, what the model tends to add ("no spoiler, no roof, no text on the doors").
2. The canonical view: `generate_image` with `document_id` and `image_name` "front" — or "three-quarter" for a vehicle or a piece of furniture, because that view shows more of the shape. Prompt for a product shot: the whole object, centred, large in frame, plain evenly lit light-grey studio background, no hands, no people, no scene dressing, no text. A reference works best at 1:1 or 4:3.
3. Read the result. Fix a wrong detail with `refine_image` on that picture (`image_url`, `document_id`, `image_id` to replace in place) before you make more views. Every later view copies its mistakes.
4. Derive the other views FROM the canonical one, never from a new prompt: `refine_image` with `image_url` of the canonical picture, `document_id` and `image_name` "side", "back", "top", "detail of the handle". One call with `images[]` makes them together. Add a view only when a scene needs it: a chase seen from behind needs "back"; a close-up on the engraving needs "detail".
5. An object the user photographed goes in with `set_document_image`, and a clean canonical view derives from the photo with `refine_image` ("the same object, whole, centred, plain light-grey studio background, even lighting, keep every marking exactly").
## Held, worn, carried
- When a character holds or wears the object, keep BOTH documents on the item: the character first in `reference_document_ids`, the object second. Say in the prompt who holds it and how ("Rin holds the sword in her right hand, blade down").
- Scale is a prompt job. State it against the character or the set in plain words ("the sword is as long as her arm", "the bottle fits in one hand", "the car is a small two-seater, its roof at her shoulder"). A reference fixes shape, not size.
- A "held" view of the object alone is rarely worth a bank entry; the character document and the object document together carry the pose.
## Objects that are the set
- A vehicle interior, a workbench, a cockpit or a shop counter is a place as much as a prop. Give it a wide "interior" view in the bank as well as the exterior, and treat it with the place rules in `style-and-world`.
- A logo or a label is a picture, not a prompt. Put it in the bank with `set_document_image` and name it "logo"; the prompt then says where it sits ("the logo on the side panel").
## In the scene batch
- Every item whose scene shows the object carries the object's document in `reference_document_ids`, along with the character and style documents it needs; the budget is 14 pictures per generation across every source, so keep a prop bank at two to four views.
- Do not re-describe the object in scene prompts. Name it, place it, and say what it does; the pictures carry the rest. A prompt that repeats the description pulls away from the references.
- After the first batch, read the stills. A scene that changed the object gets `refine_image` with the object document referenced ("match the car in the reference: cream body, red stripe, round headlights") instead of a regeneration.
## When not to bother
- A one-off object, background clutter, or a thing named once and never shown again needs no document. Describe it in the prompt and move on.
- Crowds of similar objects (books on a shelf, cars in traffic) are set dressing; only the hero object gets a document.references-from-uploads4.22 KB
---
name: references-from-uploads
description: Turn pictures the user uploads or makes in chat into reference documents Screel can generate from — a real person, a pet, a product, a logo, a brand look, a place. Use when the user attaches a photo and wants it in a video, or asks for their product, brand or self to appear.
---
# References from uploads
## The rule
A picture that lives only in this chat does nothing for the project. It becomes usable in exactly two ways: `set_document_image` puts it into a reference document's bank, or `set_scene_image` makes it a scene's still. Do the handoff in the same turn the picture arrives; the file link expires within minutes.
## A person or a pet
1. `list_documents`, then `create_document` with the reference template. In Description write what the photos show (hair, build, clothing in the photo, distinguishing marks); in Consistency what must hold (face, hair colour, glasses, the dog's coat pattern); in Avoid what the story must not change.
2. `set_document_image` with the uploaded file as `image` and a `name` for what the photo is: "photo front", "photo profile". Attach up to three or four photos that show different angles; skip near-duplicates and group shots.
3. Photos are noisy references: backgrounds, other people, phone lighting. Derive a clean canonical view before generating scenes: `refine_image` with `image_url` of the best photo, `document_id`, `image_name` "front": "the same person, full body, plain light-grey studio background, even soft lighting, neutral expression, keep the face and hair exactly". Read the result. If the likeness slipped, retry from another photo or adjust the instruction; do not build on a bad likeness.
4. Scenes then use `reference_document_ids` with that document. The clean view plus one or two photos is enough; more photos dilute the likeness.
5. Ask before putting a real person into anything they would not expect: an ad, a scene that implies something about them, a different body. Keep them as they are unless the user says otherwise.
## A product, a package or a device
- Products need exact shape, label, colour and proportions. Attach the clearest photos from front, side and three-quarter as separate bank pictures, named by angle.
- A clean packshot as canonical view: `refine_image` "the same product on a plain white surface, studio lighting, no reflections, label readable". Write the exact label text into Consistency; picture models misspell, so say in every scene prompt that the label must read exactly as in the reference.
- In scene prompts, describe how the product is held, placed or lit; never re-describe the product. The pictures carry the design.
- A product with a screen: describe what the screen shows in each prompt, or put a fixed screen state in Consistency.
## A logo or a brand mark
- Attach the logo on a plain background as its own document ("Acme logo"), Consistency: exact letterforms, colours, no restyling; Avoid: no gradients, no 3D, no extra text.
- Logos degrade in generation. Use them as a reference where the mark is small (a badge, a sign in the distance) and keep close-ups of the mark for the editor, where the user can place the original file.
- Never invent a brand's mark. If the user did not upload one, ask for it or leave the mark out.
## A place, a set or a vehicle
- Same shape as a character: a document per place, two to four photos or generated views named by angle ("wide", "entrance", "interior"), a Consistency section with the fixed layout (where the door is, what the walls are made of).
- A place reference conditions the environment strongly. Pair it with the character document on the same item, and put the place second in `reference_document_ids` so the character labels come first.
## A picture the user made in chat
- The same handoff: `set_document_image` with the file. Generating a reference picture in chat is allowed only when the user asks for it; scene visuals always come from `generate_image`.
## Keep it honest
- If the user's photo is low resolution or heavily filtered, say so; the derived views inherit it.
- Do not remove watermarks or reproduce a photo the user says belongs to someone else.
- Report what the document now holds after the upload so the user can open it in Screel and swap a picture if they want.scene-continuity6.03 KB
---
name: scene-continuity
description: Make consecutive scenes read as one continuous take — same room, same light, same time of day, matching camera — by generating later scenes from earlier stills, and make clips flow into one another by deriving the next still from the previous one and animating with an end frame. Use for shot/reverse-shot, a sequence in one location, before/after pairs, a continuous action across scenes, or when the user says the scenes do not feel connected.
---
# Scene continuity
## The mechanism
- `reference_image_urls` on a `generate_image` item conditions that picture on pictures Screel already stores: a finished scene still, a bank picture, an earlier result. The urls come from `get_project` (each scene's `image_url`) or from `get_document`.
- A batch item may carry its own `reference_image_urls`; it replaces the top-level list for that item. So one call can say: scene 2 continues scene 1's still, scene 4 continues scene 3's.
- The url pictures come first in the numbered inputs, then the reference documents' pictures. Keep the character documents on the item as well: a still alone carries the room but loses the face on a close-up.
- The limit is 14 pictures per generation, url pictures and document pictures together.
## Waves, because a still has to exist first
1. Wave one: batch every scene that depends on nothing — the establishing shots, the first scene of each location — with `generate_image` `images[]`, each item with its `reference_document_ids`.
2. Call `get_job_status` once when the batch is done, then `get_project` to read the finished `image_url` of each still.
3. Wave two: batch the scenes that continue those stills, each item naming its anchor still in `reference_image_urls` plus its character documents. Chains longer than two waves are rarely worth it; the third generation from a generation drifts. Anchor every later scene to the wave-one still of that location, not to the previous scene.
4. Do not wait on a wave with repeated status calls; the progress card updates on its own. One `get_job_status` between waves is enough.
## Prompting a continuation
- Say what stays and what changes: "Same kitchen and morning light as the reference, camera now on the other side of the table, Rin sits down". The model keeps what you name as unchanged and moves what you describe.
- Name the camera move in film terms: reverse shot, push in, wider, low angle, over-the-shoulder. Keep the lens feel consistent within a sequence ("same wide lens").
- Fix time of day and weather in every prompt of the sequence. A still anchors the room; it does not stop the model from turning noon into dusk if the prompt is silent.
- One deliberate change per scene. A scene that changes camera, time and action at once stops reading as a continuation.
## Common sequences
- Shot / reverse shot: generate the two-person wide first; both close-ups continue it, each with its own character document first in `reference_document_ids` and the wide still in `reference_image_urls`.
- One location, many beats: one wide establishing still; every later beat anchors to it.
- Before / after: generate "before"; "after" continues it with only the change described.
- A journey: no continuity across locations. Continuity is per location; the character documents carry the subject across.
## Flowing shots: derive, then animate to the next still
A clip starts on its own still. With `end_frame` it also ENDS on a chosen still, so when scene N+1's still is a later moment of scene N's shot, scene N's clip plays from one to the other and scene N+1 picks up exactly where it landed. Use this for one continuous action across scenes: a walk to the door, a reveal, a turn of the head, a vehicle crossing the frame.
1. Generate scene N as usual (wave one).
2. Derive scene N+1 FROM scene N's still: a `generate_image` item for scene N+1 with scene N's `image_url` in `reference_image_urls` and a prompt that says what stays and what moved: "the same shot and camera as the reference, five seconds later: she has reached the door and her hand is on the handle". One deliberate change; keep the camera and the light. Keep the character documents on the item.
3. Read both stills. If N+1 broke the framing, `refine_image` it ("match the camera and light of the reference") with scene N's still in `reference_image_urls`.
4. `animate_scene` scene N with `end_frame` "next" and a motion prompt that describes the move between the two pictures ("she walks to the door and reaches for the handle"). The clip's duration is the time that move takes; 3-5 seconds suits one action. Several scenes go in one call: each item carries `end_frame` "next", or the top-level `end_frame` "next" covers every item, and the last scene of a chain takes none.
5. Scene N+1 animates on its own afterwards, or renders as a still; either way it starts on the picture the previous clip landed on.
- A chain drifts like any derivation: after three or four derived stills, anchor the next one to the establishing still again and start a new chain.
- The end frame must exist before the animate call, so a chain is always two waves: every still first, the clips second.
- `end_frame` also takes a scene id or a Screel image url for a jump that is not the next scene; 'next' on the last scene is an error.
- Do not use an end frame between scenes that cut to a different place or angle; the model would morph one into the other. A cut is a cut: animate each scene alone.
## Edits keep continuity too
- `refine_image` on a scene still with `reference_image_urls` of the neighbouring still and the same `reference_document_ids` pulls a scene back into line ("match the light and colour of the reference").
- A scene whose still is animated later keeps its still as the clip's first frame, so continuity of stills is continuity of the video.
## When not to bother
- Stand-alone scenes, montages and location changes gain nothing from anchors and lose time to the extra wave. Use documents alone and batch everything at once.
- If credits are short, skip wave two: matching prompts (same location words, same time of day, same lens) get most of the way.style-and-world4.54 KB
---
name: style-and-world
description: Hold one visual style and one world across a whole project — a look (illustration style, film stock, palette), recurring places and props — and combine style, place and character references without them fighting. Use when the user names an art style, wants scenes to look like one film, or asks why scenes look inconsistent in tone.
---
# Style and world
## Three kinds of reference, three jobs
- A character document fixes WHO: face, body, costume. Its pictures are portraits on plain backgrounds.
- A place document fixes WHERE: layout, materials, landmarks. Its pictures are wide, empty views.
- A style document fixes HOW IT LOOKS: medium, line, palette, grain, lighting mood. Its pictures are two to four frames in the target look that contain none of the story's characters or places, so the model borrows the treatment and not the content.
- All three ride `reference_document_ids` on the same item. Order them subject first, place second, style last; the labels follow that order and the model weights earlier pictures as content and later ones as treatment.
## Build a style document
1. `create_document` with the reference template. Title it for the look ("Look — 1970s film"). In Description name the medium, palette, contrast, grain, lens feel, era. In Consistency write the two or three properties that must hold in every frame ("warm halation, muted greens, soft 35mm grain"). In Avoid, what breaks the look ("no neon, no clean digital sharpness, no anime line work").
2. Make the style frames with `generate_image` and `document_id`, `image_name` "look 1", "look 2": generic subjects (an empty street, a table by a window, a hand on a railing) rendered in the target style. Never a character or a story location; the model would copy them.
3. A style the user uploaded (a frame from a film, a painting) goes in with `set_document_image`. A recognisable artwork or a living artist's signature style is a request to decline politely; describe the qualities instead ("loose watercolour, warm paper").
4. Write the style words in the prompt too, briefly. The pictures set the treatment; the words keep it from drifting when the reference budget is tight.
## Build a place document
- One wide view first (`generate_image`, `document_id`, `image_name` "wide"), then derive "entrance", "interior", "night" from it with `refine_image` so the layout stays the same. A place is a set: the camera moves, the walls do not.
- Put the layout in words in Consistency ("door on the left, window wall at the back, long table centre") so a prompt can place characters correctly.
- Recurring props (the car, the sword, the robot arm) are product-style documents: exact shape, named angles, no re-description in prompts.
## Combine without conflict
- Budget: 14 pictures per generation across every source. Character (2-3) + place (2) + style (2-3) fits; two characters + place + style needs lean banks.
- Conflicts show up as muddy results: a photoreal character document with a watercolour style document. Resolve it at the document level: regenerate the character's canonical view in the style ("the same character, rendered in the look of the reference frames", with the style document referenced) so the character bank already carries the treatment.
- Set the style once for the project and reuse the same style document on every item. Changing style mid-project is a new project's worth of references.
- A style document alone is enough for scenes without recurring subjects: montage shots, inserts, landscapes.
## Prompt shape that works
`<subject and action>, <where, in the place's own words>, <camera>, <light and time>, <two or three style words>` — the references carry the rest. Long prompts that re-describe what the pictures show pull away from the references.
- Frame treatment is part of the look and drifts on its own: one scene comes back with a painted border, a vignette or a letterbox and the sequence stops reading as one film. Keep every scene full-bleed unless the user asks for a device. Put `borders, frame, vignette, letterbox, split panel, inset, text, watermark` in the batch-level `negative_prompt` and in the style document's Avoid section, and use the same two or three medium words in every scene prompt.
## Checks
- After the first batch, read the stills. If one scene broke the look, `refine_image` on it with the style document referenced ("match the look of the reference frames") instead of regenerating everything.
- Render settings (resolution, motion on stills, captions) are separate from the look; set them with `update_project` when the user asks.Package details
Publisher declarations from the archived package. These are separate from our research and the live service's terms.
- Package author
- Xlab Digital llc
Package observed Oct 2, 2026.
Technical details
- First seen
- Sep 30, 2026 · 22:02 UTC
- Last seen
- Oct 2, 2026 · 12:00 UTC
- Collection status
- Collected
plugin_asdk_app_6a6375f9e5288191b1f6ad81ba4253e3
Download plugin data (JSON)