Skip to content

Reuse libraries and workspace lore

Library objects have different roles. Discover the intended item before applying an ID; names in an example are not account-owned IDs.

Discovery Reuse
list_my_elements → describe_element Apply the selected Element to an Element node, then connect it to the authoring or generation node.
list_skills Filter by node type and, where relevant, target model; apply a compatible skill.
list_generators Apply the returned configuration to a node of its declared kind.
list_my_prompts Put the selected complete prompt into the appropriate editable text field.
list_my_designs Use the graphic rules in a Design system connected to Decoration.

An Element input on a writer does not mean a library Element can be applied directly to that writer. The catalog explicitly marks the node that accepts library Elements. Skills return public metadata, not protected instruction bodies. A generator supplies settings; applying it does not create its media.

See skills and generators for how to choose among these tools.

With write permission, save_element puts an Element into the library of the key owner, the same library the studio’s ★ save writes. Without element_id it creates a new Element and a name is required. With element_id it updates your saved one: only the fields you pass are replaced. Pictures must be your own studio files, such as a url from upload_artifact or a generation result. An outside address, someone else’s file or a file that is not a picture is refused, and nothing is written.

For a character, put the character sheet first, not a single portrait. The source photo the sheet was drawn from may follow it with the kind null. Give each picture its kind in view_kinds, one per picture in the same order: sheet for the character sheet, figure and face for the clean frames, object for an object frame, null for a picture without a kind. The studio does not guess kinds: without them every picture counts as a sheet or photo and the Element has no frames. The texts have different readers: description and character go to the scriptwriter, while look tells the frame generator what to take from the attached picture. Write look from the picture itself. If you cannot see it, leave the field empty and let the person fill it with ✨ Describe the picture. Check the result with list_my_elements and describe_element, then apply it to an Element node with apply_library_element in apply_graph_ops. There is no deletion through the API.

{
"name": "save_element",
"arguments": {
"name": "Sonya",
"role": "персонаж",
"images": ["<url of the character sheet>", "<url of the figure frame>", "<url of the face frame>"],
"view_kinds": ["sheet", "figure", "face"],
"description": "The postwoman of a small seaside town, 28.",
"character": "Stubborn, jokes a lot.",
"look": "Red hair, blue postal jacket."
}
}

Use list_workspaces to discover the intended space and get_workspace_lore to inspect its documents. Workspace lore is shared by projects in that space. A project’s local lore remains a separate layer.

{
"name": "get_workspace_lore",
"arguments": { "workspace_id": "<workspace id returned by list_workspaces>" }
}

With write permission, put_workspace_lore creates a document or updates the supplied doc_id. Read the existing complete text before editing, and read it back afterwards. Use the returned active-state field to check whether the document is enabled. Disabling a document is not deletion.

Choose workspace_id when creating a project, or use move_project deliberately. A move changes the shared workspace context available to that project. Already visible authoring results may then become stale.

Do not insert a document’s filename or download link as if it were its text. Uploading stores a document; it does not extract lore from it automatically. If the lore exceeds the permitted size or model context, resolve the visible refusal without silently dropping content.

The lore wizard has a fixed standard: one World document, zero or more Format documents (one per kind of video) and an optional Episode log. lore_standard returns its documents, steps and questions, the five kinds of video, what the workspace already holds and the next empty required step (next). Ask the person that question, one step at a time, and keep the answers word for word. Do not describe characters’ looks here; the Element and its character sheet hold them. In the studio, people follow the same standard in the Lore wizard.

write_lore takes the answers by step key. The studio composes the documents itself, puts them first and enabled, replaces its own documents on a repeated write and leaves other documents as they were. While a required step is empty, the call refuses with that step’s question and writes nothing. The answers are the full set: start from filled of lore_standard and change what is needed. A wizard document missing from the answers, such as a Format or the Episode log, is switched off, not deleted.

{
"name": "write_lore",
"arguments": {
"workspace_id": "<workspace id returned by list_workspaces>",
"answers": {
"world": {
"premise": "A small seaside town where cats run the post office.",
"audience": "Parents aged 30-45 watching on the phone in the evening.",
"cast": "Sonya is the postwoman; Boris is her brother.",
"laws": "Cats only talk to each other.",
"tone": "Warm irony, lines in English."
},
"formats": [{ "kind": "story", "length": "About a minute, six scenes." }]
}
}
}

To sort a ready text of the person, read it with get_workspace_lore, place every line into a step (or world.unplaced) and pass its document ID as source_doc_id. If any line of the source is missing from the answers, the call refuses with the list of lost lines and writes nothing. With full coverage the source document is switched off, not deleted. Call lore_standard again afterwards: gaps is empty and filled shows what was written.

Last checked: 17 October 2026. Read and mutation scopes are listed separately in the tool reference.