agentleFS
PicsArtPicsArt/gen-ai-skills/skills/large-scene-assembly/SKILL.md

large-scene-assembly

Skill6 starsChanged 19 days agoMITView on GitHub

Build large editable scenes by decomposing a timeline into bounded scenes and reusable components, defining timing and asset contracts, then assembling and safely consolidating them. Use when authoring long videos, many scenes or layers, scene-by-scene designs, oversized JSON, fragile whole-document edits, reusable modules, or an editable handoff.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 5 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep one editable source of truth and a thin assembly.

    line 15
  2. Very specific:

    Ask picsart_scene_capabilities (schema:<Name> sections) for the exact relevant content/asset/parameter shapes.

    line 40
  3. Very specific:

    Check just before, at and after joins.

    line 50
  4. Very specific:

    Read the source subtree or named layer before bounded picsart_scene_patch edits.

    line 55
  5. Distinctive:

    Keep stable semantic ids and distinguish definitions from instances.

    line 56
  6. Distinctive:

    Prefer a root with resolvable saved children when the consumer supports those handles/URLs.

    line 74
  7. Very specific:

    If a self-contained document is required, inline scene assets with their scoped dependencies using the current schema, or use …

    line 75
  8. Distinctive:

    Check for unresolved/local-only handles, unavailable assets, namespace collisions, duration changes, changed parameter defaults and missing …

    line 79
  9. Distinctive:

    Run the relevant relationship lint again and watch the assembled video before claiming equivalence.

    line 82

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Large scenes, small editing units

Served checks: picsart_scene_check_contracts runs contract records and reusable templates, picsart_scene_check_motion runs frame-complete motion records, and picsart_scene_inspect pages large sources; the one remaining limit is that pixel records have no automated checker, so inspect full-resolution rendered frames for them.

Keep one editable source of truth and a thin assembly. Decompose by meaning and ownership, not an arbitrary layer count. A card that travels across three beats is one persistent object, not three separate scenes just because the storyboard has three frames.

Establish a manifest before growing the document

Record canvas/fps, ordered beats and durations, shared style tokens, component ids, assets, entry/exit states, and the carrier (if any) across each seam. Use the compact scene manifest when the timeline needs a durable handoff. The manifest is authoring documentation, not an extra field injected into the scene schema. Record checkable intent in a separate versioned contract sidecar (linked-element-motion), with stable contract ids, query target scopes and root-time phase windows. The same element may have different relationships in different phases; document independent travel rather than forcing one parent relationship for its whole lifetime. Preserve these contracts alongside component revisions.

Choose boundaries deliberately:

UnitRepresentation and ownership
Local semantic unit: card, label, iconInline composition or a supported parent rig; animate its common placement once.
Reusable independent sceneScene asset/reference with explicit inputs, duration, dimensions and assets.
Sequential beatstrack clips; record how clip windows map into source time.
Persistent foreground across beatsParent-level layer spanning the interval, outside the replaced clips.
Shared stylingConsistent authoring tokens/parameters; do not assume implicit inheritance between documents.

Ask picsart_scene_capabilities (schema:<Name> sections) for the exact relevant content/asset/parameter shapes. An inline composition uses its owning document's assets; a separately referenced scene owns its own asset scope. Do not rely on an undeclared parent asset, copied font id, or temporary URL being available in a child.

Author → verify → assemble, incrementally

  1. Build each semantic component with editable shapes, text, assets, keyframes and stable ids. Validate it with picsart_scene_validate and query entry, event and exit geometry with picsart_scene_query_layout.
  2. Inspect full-resolution stills with picsart_scene_contact_sheet, setting resolution to the scene dimensions; watch continuous video for motion claims.
  3. Preserve the accepted source revision and record its returned source or handle. A held handle is local to its tool surface, not a portable published URL.
  4. Assemble a thin root that owns order, clip windows, seams and persistent carriers. Children own their internal layout and motion.
  5. Check just before, at and after joins. Rerun supported picsart_scene_lint_layout relationships against independently recorded intent. Rerun contract records with picsart_scene_check_contracts; record uncovered assertions as unchecked.
  6. Continue component by component; recheck affected joins and overall playback. Show meaningful milestones during authorized autonomous iteration.

Keep edits bounded

  • Read the source subtree or named layer before bounded picsart_scene_patch edits. Page the structure with picsart_scene_inspect (outline, then read by patch address).
  • Keep stable semantic ids and distinguish definitions from instances. Query ids/scopes are for evaluated geometry, not guessed edit addresses.
  • Save revisions and explicitly update parent references when a child changes. An old parent does not silently follow a new child.
  • Recheck every affected instance's parameters, assets, duration and seams. Keep unrelated components unchanged.
  • Split work by component ownership only when parallel work is already authorized; one integration pass assembles accepted revisions.

Inspect authored structure before evaluating it

Page authored structure with picsart_scene_inspect: outline (20 rows by default, up to 100, continue with nextOffset), then read an exact layer or field path by patch address. Keep the source document and its manifest, and read the intended component before editing. Distinguish authored layer addresses from evaluated query ids and composition scopes; never infer edit addresses from a geometric result. Use bounded picsart_scene_patch edits against known ids and field paths. If the source is not available, retrieve it through its saved source URL before editing; a layout query is not a complete source inventory.

Outline rows also carry container pointers, cameraExempt and references, and the outline names the scope's authored camera fields. Only the root scene argument is loaded, through the guarded loader: follow an external scene deliberately, as its own scene argument, since the parent is not its editable body. sceneSha256 is a canonical-JSON hash for paging, not a remote asset fingerprint; edit against immutable handles.

Inspect shared definitions in their own asset scope. Editing a shared definition affects all its instances; create an instance-specific definition and retarget only the intended consumer for a local variation. Keep the original revision and explicitly update parent references after a child changes. Revalidate and query every affected instance and seam. Source inspection cannot certify layout, media availability or motion.

Consolidate without losing the sources

Consolidation means a coherent, resolvable deliverable—not indiscriminate flattening.

  1. Save a named source revision and its manifest before replacing references.
  2. Prefer a root with resolvable saved children when the consumer supports those handles/URLs. If a self-contained document is required, inline scene assets with their scoped dependencies using the current schema, or use picsart_scene_expand_ref for a supported local detachment.
  3. Expansion is not a universal recursive bundler. Read its diagnostics and stillReferenced; process only the intended instance, preserve track timing, and do not delete assets still used.
  4. Check for unresolved/local-only handles, unavailable assets, namespace collisions, duration changes, changed parameter defaults and missing fonts. A flat layer list is not proof of portability.
  5. Revalidate and compare pre/post geometry at component events and seams; preview those moments. Run the relevant relationship lint again and watch the assembled video before claiming equivalence.

Deliver the editable root, component revisions, manifest and rendered evidence. Say what is external and what was not verified; an MP4 alone is not an editable scene handoff.

For group vs. layout behavior use linked-element-motion (fetch with picsart_scene_recipe, name linked-element-motion); for seam intent use motion-scene-continuity (fetch with picsart_scene_recipe, name motion-scene-continuity).

Research note: independently authored for scene. General motion-design research informed the workflow; no Hyperframes implementation, wording, examples or numerical presets were adopted.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.