> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livlive.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> This is livlive's documentation. An agent reaches livlive from outside through the `livlive` CLI or the livlive MCP server (see /developers/install, /developers/cli and /developers/mcp). The person links it to livlive once, in the browser: `livlive login`, the local MCP's `livlive_login` tool, or the remote MCP at https://backstage.livlive.ai/api/mcp signing in by OAuth; a personal token made in livlive's settings is for CI. Pages marked 準備中 describe parts not decided yet: do not guess their behaviour.

# livlive

> Entry point. Read this first for any livlive content work (writing a 構成表, researching, briefing assets, checking a draft). Routes the ask to the right staff member's skills and to the livlive ops.

> [!NOTE]
>
> このページは、エージェントが読む skill「livlive」の本文です。

> [!WARNING]
>
> いまは招待制βの準備中です。CLI と MCP は npm から入れられますが、使うには livlive のアカウント(招待制)が要ります。スキル(`npx skills add`)は、livlive-kit の公開とともに使えるようになります。

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`.

| The work | Staff | Skill to open | Saved by |
| - | - | - | - |
| 構成表を組む | ツヅリ(脚本家) | `tsuzuri-plan` | `script.save` |
| 調べる問いを立てる | ポポ(リサーチャー) | `popo-room-research-ask` | (written in the room through `write_research_questions`; livlive keeps the result) |
| 取材する | スジ(取材担当) | `suji-research-search` | (livlive keeps the result) |
| 調べた事をまとめる | ポポ(リサーチャー) | `popo-research-synth` | (livlive keeps the result) |
| 素材の中身を決める | イロハ(アートディレクター) | `iroha-room-asset-ask` | (started by `asset.ask`; livlive keeps the result) |
| 文章を書く | ピリ(コピーライター) | `piri-asset-text` | (livlive keeps the result) |
| 章を書く | トジ(編集者) | `toji-asset-markdown` | (livlive keeps the result) |
| 資料を作る | ニジ(イラストレーター) | `niji-asset-slide` | (livlive keeps the result) |
| 画像を作る | ニジ(イラストレーター) | `niji-asset-image` | (livlive keeps the result) |
| 曲を作る | ポチ(作曲家) | `pochi-asset-audio` | (livlive keeps the result) |
| 映像を作る | コマ(映像クリエイター) | `koma-asset-video` | (livlive keeps the result) |
| 企画書を書く | ドン(プロデューサー) | `don-room-pitch` | (written in the room through `open_pitch` → `write_pitch`; livlive keeps the result) |

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.