livlive

livlive keeps characters living: a creator makes contents (コンテンツ), and livlive holds the one copy, checks its shape, and performs it. Read livlive-core first for the contract (the 構成表 shape, the words, the boundary).

​

Which work, which skill

Find the work, then open its skill (skills/<name>/SKILL.md). Each work skill says what to read (the craft skills it uses), the instruction, the procedure, the shape to return and the checks. The staff and their titles are listed in livlive-core. Talking with the person and running the room (mone) is not published as a work skill: this entry skill carries its procedure. Designing the character’s body (katachi) is out of scope. The stage (hako): the stage page’s documents; stages and games are made on your own PC (the CLI / MCP) and the browser only registers and checks them — a stage is checked against the engine reference (reference/engine.json, also the MCP resource livlive://reference/engine) and handed in with livlive stage push. A person who wants a stage or a game made: read stage-lead first — it leads them and hands the build to stage-package. To build or change a stage package: read stage-package first. A craft skill names its staff in its frontmatter (staff: [ids]). Skills with reading: always are read at the start of the work; reading: needed skills are opened when their description fits.

​

The preparation road (from outside)

How the creator’s own agent prepares a first content in a new room. You think and write; livlive keeps and checks. Nothing on this road is paid (each op leaves a work record with runner outside and 0 credits). Run the ops with livlive-cli; each step names the op and its input.

1. room.open with {"title":"<the room's name>"} — answers data.project. (When the person gives a project id, start at step 2.)
2. room.read (--project <id>) — read data.choices (the ids you may pick: cast [{id,name}], forms [{id,label}], channels [{id,label}]), data.carries, data.current and data.structure (both null while the room has no content).
3. desk.pick with {"cast":["<choices.cast id>", …], "channels":["<choices.channels id>"]} (the lead first, at most 4). Then room.read again: choices.forms now lists the forms that fit that cast and channel. desk.pick with {"form":"<choices.forms id>"}, or "planned" when no form fits (you then decide the form yourself in step 7).
4. request.write with {"memo":"<the 要望, in Markdown>", "proposals":[]} — the 要望 comes first: what the person wants, in their words, under ## headings of your choosing (概要 ・ 対象 ・ 目的 ・ 雰囲気 ・ 要件 as a guide, not a form). script.first waits for it (request). With no person to answer, write it with no proposals: it is answered at once. A proposal ({"heading":"<a ## heading of the memo>", "others":["…"]}, up to three other words) waits for the person’s answer in the room before the first version is kept. Write it again to add to it; a section the person settled stays as it is — room.read’s data.request shows the 要望 as it stands (settled, open). request.edit changes one thing when the person asks — {"take":"<heading>"}, {"section":"<heading>","words":"…"}, {"memo":"…"}, {"bring":"<asset id>"} (a 参考資料) or {"drop":"<asset id>"}.
5. Bring what you found and wrote:
   • research.bring with {"title", "purpose", "claims":[{"text", "source":"https://…", "confidence":"true"|"unverified"}]} — at most 12 facts, each with an http(s) source; "true" only for a fact you checked at its source. Answers made.research.
   • asset.bring with {"kind":"text"|"markdown", "title", "text", "use":"intro"|"setting"|"memo"|"quote"} — answers made.asset. When you wrote it from the room’s own material, add "from":["<id>", …] (at most 6): a made.research above, a 構成表 version, or a 素材 of the room. The room keeps what it was made from; an id it does not hold refuses the bring, naming it.
6. pitch.put with {"title", "doc":"<the 企画書, in Markdown>", "answers":[{"to":"<a 要望 heading or a 参考資料 id>","section":"<the doc's heading that answers it>","how":"<a few words>"}], "research":["<made.research>", …]} — the 企画書 comes after the 要望 and before the first version (script.first waits for it: pitch). Write it as don-room-pitch says (why the show, what it is, what is worth watching, for whom, roughly how it runs, what to watch for; facts only from what you brought); each ## heading once. It is free; nothing is written for you. room.read’s data.pitch shows it as it stands — current false while it waits to be rewritten (stale, changes: the 要望 or the 形 moved); put it again after such a change.
7. Write the 構成表 with your own model: open tsuzuri-plan (its 指示 says what to decide; its 検査 what is checked) and the 構成表 section of livlive-core (the shape). On this road:
   • meta.title and meta.cast come from script.first’s title and cast (step 9): leave them out or write the same — a different one is refused (meta). meta.topic short.
   • Each stretch’s goal says what is done when it is met (200 characters at most, 30 for a title, 20 stretches at most).
   • refs take the full ids from step 5 (made.research, made.asset) — the stretch’s performer reads them; the short [key]s in tsuzuri-plan’s 指示 are the inside writer’s.
   • Put a brought document on shelf.docs as {"id":"<made.asset>","label":"<its title>"}; set length as {"minutes":N}.
   • Facts only from what you brought (step 5) — the same rule as tsuzuri-plan’s 事実の出どころ.
8. script.check with {"structure": <the 構成表>} — ok when it would be kept; else each left[] says what to fix (why = the check: shape, camera, limits, dropped) and data.problems lists every finding. Fix and check again. dropped names a field written in a shape the sheet does not read (「length は { minutes: 数 } の形で書きます(いま 5)」) — keep to the shape in livlive-core.
9. script.first with {"title", "structure", "cast":[…the ids from step 3], "form":"<the form id from step 3, if any>", "research":["<made.research>", …], "requestId":"<a uuid you make>"} — answers made.version. research (optional, at most 8) = the room’s research the version was written from; an id the room does not hold is refused (research). A retry with the same requestId answers the same version; any other call on a room that has a content is refused (already). From here on each next version is script.save with {"base":"<room.read current>", "requestId":"<a new uuid>", "structure"} — start it from room.read’s structure.
10. room.read — versions (each with the research it holds), current and structure show the saved version; recent shows one record per op you ran.
11. For a content performed on one of the person’s stages: after script.first, script.stage with {"stage":"<id>"}, the id from stage.list (livlive stage list). The next version then says the stage and the content gets its episode there; the answer’s made.episode is the id the studio takes. Never before script.first: a stage set before the first version is not carried onto one written here, and no episode is made. A content on no stage has no episode and cannot be rehearsed. In step 3 choose a channel other than meet for it: a meet content is performed in the app delivery room, not the studio.
12. Tell the person, in their words, how to rehearse. Performing, rehearsal and 本番 are livlive’s; this road ends at the saved 構成表. Every run uses their credits, so say that first (with none, the start is refused in words). On a PC (a phone only says 「スタジオはパソコンで開いてください。」) they open <livlive's address>/studio/<made.episode>, the address being the one livlive login used; from コンテンツ, the content’s page leads there too, by 「リハで見る」 or 「スタジオへ」. There:

• They press 「リハを準備する →」. When it cannot be pressed, the line beside it says what holds the cast back (a character with no voice, soul or body, or not yet debuted) and where to fix it.
• They keep 「動く」 ticked, or the character does not move on the stage (it starts ticked when the sheet says this stage and the stage’s space is measured), and press 「▶ リハを開始」. The tab that started the run draws the stage, so it stays open.
• When 「リハ本編を開始 ▶」 can be pressed (the cast has arrived and the picture is going out), they press it.
• The run ends by itself or with 「完了 ✓」; 「中断(長押し) ■」 stops it. 「↻ もう一度(準備へ)」 runs it again.

​

The ops

Use livlive-cli for the ops (livlive <op> --json ..., or the MCP tools). Think, write and revise on your side; hand the draft to livlive to check and keep. Nothing in the CLI/MCP is written by hand per op: the list comes from the app.