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

# stage-lead

> How an agent leads a person from a wish to a livlive stage a character has lived in — what to find out, when to answer with the limits, when to show it, where the work stands. Read this first when a person wants a stage or a game made, however little they know; the build itself is `stage-package`.

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

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

A person wants a place for a character, or a game to play in one. They know nothing: not how to build, not the engine's limits, not how the
work goes. You lead them from that wish to a stage a character has lived in. This skill is the conversation: what to find out, what to answer, when to show, where to
stop. How the stage is built and handed in is `stage-package`; what the engine can do is the engine reference. Neither is repeated here.

Speak to the person in their own language and in their own words. A word of ours — the names on the road, the reference's terms, a problem
code — is yours to put into theirs.

A stage is made on the person's own PC, by you and them, with the kit and whatever tools they have. The browser only registers and checks:
livlive's pages show what a folder holds and what was handed in, and have no place for building. Tell the person so if they go looking for one.

## Find what the person wants

**The purpose:** to know what this person is after and which kind of creator they are, before anything is decided.

There are two kinds of creator: those who come with a full request, and those who shape the stage by talking. Notice from how this person
speaks which kind they are, never by asking them to name one, and lead accordingly:

* Someone who came with a full request is not asked again what they already said. Ask only what a proposal cannot be made without, and give
  them the proposal.
* Someone shaping the stage by talking gets small steps and something to react to: one decision at a time, and at each step something made
  from what they have said so far for them to answer. What the stage can offer is yours to tell them; what they should want is not.

For either, begin from what they said and never work through a fixed list of questions. Ask one question at a time and hear its answer;
open questions (what it is for, what would make them glad) come before a choice between options, which you offer once you know enough
to make the options good ones. Both reach a proposal before anything is built. What you are finding out:

* What they want a character to do and to be in this place, and why: what would make them glad when they see it. A look alone is not
  enough, because a stage is where a character lives.
* Which character they have in mind, if any, and whether there is a game, and if so what about it matters to them.
* What they bring (tools, files, things they have made), what they want to decide and what they would leave to you. It sets how much of the
  work you show and which tools you use.

Three things are settled before anything is made, however full the request; what they already said settles its part (say it back), and
what is left is asked, each in its turn:

* **The look.** Stages are made in an anime style as a rule: say so, and ask what atmosphere they want the anime look to have, in substance
  「アニメ調に関しては、どのような雰囲気にしたいですか？」, in their own language. Ask it with no example of your own: an example in the
  question comes back as the answer, and the atmosphere is then yours, not theirs.
* **The tools.** For quality, two services can make parts of the stage with the person's own keys: gpt-image (OpenAI) draws reference
  pictures — first one picture of the whole stage, for the person to agree the look on, then the pictures the models are made from — and
  Tripo makes a model from a picture. Recommend them for the quality they give, and say what each is for and that each is paid by their own
  account with that service, at the service's prices (never a price of yours). If they want them, ask them to add `OPENAI_API_KEY` and
  `TRIPO_API_KEY` to the stage folder's `.env` themselves once `livlive stage new` has made it (its `.env.example` names both; `stage new`
  takes only a new or empty folder, so nothing goes there before it). You never read, print or ask for a key: the kit's commands read it
  there (`stage-art`). Without keys the stage is built with Blender alone; say so, and what that changes in what they will see.
* **A game.** A stage can have a game of its own, with rules a character plays by. Someone who has not spoken of one is told a game can be
  made too: offered once, never pressed.

The person may give detailed instructions: colours, sizes, positions, materials, a picture of their own. They are their decisions, and they
come ahead of your proposal and your taste. Each is held against the limits as any wish is (below): what fits, and where it does not, the
nearest shape that does.

**It is met when** you can say back, in their words, what they want and what a character will do there, with each thing you guessed rather
than heard marked as a guess, they agree that is what they meant, and the way you led fits the kind they are: the one who came with
everything has not been asked for what they already said, and the one shaping by talk has had something to react to at every step. The
look, the tools and the game were settled before anything was made.

## Hold it against the limits

**The purpose:** before anything is built, the person knows what they will get: what fits, what does not, and the nearest shape that does.

Open `stage-package` first: it says what a stage offers a character and what each part of the reference is for. Then read the limits from
the engine reference, fresh each time, never from memory: `livlive reference` prints the one livlive serves now (the MCP resource
`livlive://reference/engine` is the same; `reference/engine.json` is the copy in a checkout of the kit). It is long, so save it to a file and
read the parts the request touches: `limits` and `package` for sizes and counts, `kinds`, `can` and `acts` for what a character can do with
what is there, `keeper` for a game's rules.

Hold all of the request against it, not only its sizes: what a character has to do there, what a game's rules have to be able to say. What
the reference does not offer does not fit: never invent a way, and never promise what you have not found there. When reading cannot settle
it, say it is not yet known and find out with a small trial on the PC before you answer.

Then tell the person, in their words and not the reference's: what fits; what does not, and why; and for each thing that does not, the
nearest shape that does — nearest to what they wanted it for, not to what they named. Nothing is dropped or swapped quietly.

Say what they will see as well as what fits. Some choices change the picture itself, and the reference says which: how many rows a
game's board has decides how it is drawn and whether the room is seen at all (`keeper`'s `view`), and a character is seen only
from where a camera may stand (`camera.volume` in the world's schema). When a choice would take the place out of the picture, or
show a character from behind while doing what the person asked for, say so in the proposal, before the yes, with the nearest
choice that keeps the picture they wanted.

The words on the broadcast screen, a programme's title, its subtitles (each stretch's title, shown as the stretch begins), its captions and the
viewers' comments, are the programme's: the broadcast screen draws them in the show, whatever its stage, and the show's content sets them (its
title and its stretches' titles, `livlive-core`), never a stage.
A stage overlays words on the picture in two ways only, an event's telop (`rules.happenings` in world.json's schema) and a game's board
(`keeper`'s `view`), and the reference says what each can hold. Words painted on a sign or a wall are part of the room, seen as the room
is seen in every show on the stage: a nearest shape a person who asks for a programme's title may want. When the person wants words on the screen, tell them they
will have those on the broadcast screen and where they are set, and offer what a stage can give as the nearest shape.

**It is met when** the person has said yes to a proposal that says what they will get, what they will not and what they will see,
and you can point to the reference for every part of it. The stage is not started before that yes. A later wish is held against
the limits again before it is built.

## Show it early

**The purpose:** the person sees the stage and is inside it early, because a wish in words changes when it is seen, and a surprise is
cheapest while little is built.

Once the proposal is agreed, run `livlive stage new <folder> --name <name>` with the stage's name, the person's (ask it with the proposal when
they have not given one). On a PC linked to livlive it makes the stage there at once, free, and the folder remembers it (`livlive.json`): from
this yes the stage is on the person's stages (`/stages`) as being made, and every push of the folder goes to it. On a PC not linked yet, offer
linking first (`livlive-cli` says how), so the stage shows there from this yes; the folder alone comes second: `stage new` then makes the
folder only and says so, and the stage is made at the first push. If they chose the two services, the new folder's `.env` is where their keys go
now. With the keys, the first thing the person sees is one picture of the whole stage, drawn in seconds (`stage-art`): show it as itself, and
agree the look on it before the stand-ins are laid out. It is drawn again, on their yes, until they agree the look, and it comes first again
whenever the look changes. The stand-ins follow at once, laid out from that picture: build only what it takes to be seen and stood in
(`stage-package`), the room's shape with plain stand-ins where the things still to be made will stand, and open it with
`livlive stage dev <folder>`, so the person walks the place before any model is paid for. Without keys the stand-ins come first. Say what is
still unfinished and what you want them to judge.

The dev page lives only while `livlive stage dev` runs: it reads the folder from that command, and once the command stops the page
is cut off (「手元のフォルダとのつながりが切れました。」) and a page opened after it has nothing to draw. A run of yours that ends when your turn does
leaves the person such a page: ask them to run the command in a terminal of their own and leave it open, and give them the line to
paste. Opening the page costs the person a wait before anything else — the stage plays only once the body of every character in
the cast is loaded — so say that, and who will be in the cast, before you ask (`stage-package` says how the page casts a game).

Let the person possess the character: on the dev page they take a character's place (乗り移り), go about the stage as that character and see
what it may do there. That is how they find out whether it is a place to live in. What you need back is what they noticed, what they wanted
to do and could not, and what felt wrong. The changes come from here.

A made piece replaces a stand-in once the person agrees to it. Show each piece as it is made: a reference picture as itself, a file they
open; a model as the pictures `render_views` draws of it, then on the dev page once it is placed. With each, ask what you are unsure of
before going on. Before you show a model, look at its front view yourself, since a generated model often comes turned (`stage-art`). The
anime look is drawn by the stage itself, by its `look.ink`, which you declare in its world for the atmosphere agreed (a new stage declares
none): outlines and light in steps over the whole room, within the ranges the reference gives, with every model fitted `flat`. A model's own
pictures therefore show no lines, and the dev page shows them once `look.ink` is declared: say so when you show one.

With the whole stage's picture agreed, the room itself is made to it — its walls, floor and fixtures, and its lights standing and coloured as
the picture shows them, their strength set for the characters (below) — and never left as stand-ins once the things are modelled. Before you
call the room finished, ask the person to open that picture beside the dev page and look at both (look yourself only where you can see the
page).

The light is for the characters first. On the dev page every character of the cast keeps their natural colour, neither blown out white nor
left dark, and a pale one blows out first: ask the person to choose each character in the page's 「キャラクター」 and look (look yourself only
where you can see the page). A dark look comes from the room's own colours, never from dim light: dim light raised again to see by is what
turns the characters white. A room is brightened by its colours or by what its surfaces light from themselves, never by stronger lights on the
people.

Before the hand-in comes the stage's face: what its page and the person's stages show of it, and what its performers read. Its 一枚絵 is the
whole stage's picture the person agreed on when they chose the keys; without them, a render of the room you make in Blender, or a picture the
person puts on the stage's page themselves. If the room as built ends up looking unlike the agreed picture, offer a render of the built room
as its 一枚絵 too, and the person chooses. Then its ひとこと, its 色 from the stage page's own list, and its 世界観 documents. Show each as you
show any made piece, and it goes with the push only on their yes (how: `stage-package`). The face is not required: a stage registers without
it, and its page says what is missing. What the person set on the stage's page is theirs: a push fills only what is empty, and you replace a
field only when they ask you to.

The dev page needs the person's browser signed in to livlive and a character of their own; making the stage at the proposal's yes,
`livlive game check` and the hand-in need the CLI logged in (`livlive-cli` says how). When one of these is missing, say what it is for and
see them through it at that point, not before. What a step costs the person, say before asking them to take it: `stage-package` names what
uses their credits, and `stage-art` what is billed to their own accounts with the two services.

**It is met when** the person has been inside the stage as the character before most of the build is done, and what they said has changed or
confirmed the plan. With the keys, they agreed the whole stage's picture before the stand-ins were laid out. Every made piece was shown to
them, and agreed, before it took a stand-in's place. A stage first shown when it is finished has failed this, however good it looks.

## Say where the work is

**The purpose:** the person always knows where the work stands, what comes next and whether it waits on them.

The road has six places. Each time you report, name the place (in their language), what just happened, what comes next and who it waits on,
and the page to open now and what to look at there:

* on the PC and fix: the dev page, at the address `livlive stage dev` printed — what to try there as the character (乗り移り), and that the
  patrol's findings, when it ran, come back to you as the terminal printed them;
* from the proposal's yes: the stage's own page on livlive (`/stages/<id>`, whose address `livlive stage new --name` and `livlive stage push`
  print) — what it shows of the stage and what it says is missing — and the stage's place on the road (`/stages/new?stage=<id>`);
* the rehearsal: the content's studio, and what to press there.

| Place | What happens there | It is left when |
| - | - | - |
| tell | the person says what they want | you can say it back and they agree |
| proposal | what fits, what does not, the nearest shape | they say yes |
| on the PC | the folder is built and they see it on the dev page | they have been inside it |
| fix | what they saw or a check found is changed | nothing is left they want changed, and `stage-package`'s checks before handing in have passed |
| hand in | `livlive stage push` registers the stage, with its face | livlive has registered it; a refusal names its problems by code and goes back to fix |
| rehearsal | a character lives in it, in the studio | it lived there (below); what falls short goes back to fix |

The road runs back as well as forward: a new wish goes to proposal, and what the person sees or a check finds goes to fix. Say so when it
happens, and say what stays done. Say a failure plainly, in the person's words; never leave them a code or a silence to interpret.

A place a camera may stand or the characters' start (`camera` and `spawn` in the world's schema), moved for one seat, can hide a face at
another: after moving either, run the patrol again (`stage-package`) before the hand-in.

**It is met when** the person, from your last message alone, could say which place the work is at and who moves next.

## Done is a rehearsal

**The purpose:** the end of the road is not a stage that was made but a character that lived in it.

A stage is not done when it looks right, when the checks pass or when livlive registers it. It is done when, in a rehearsal in livlive's studio
with the person's character, the character lived there: went about the place, sat or stood where the place means it, used what it offers, and
played its game if it has one.

The rehearsal is the person's to run, and it needs a content on this stage with their character in its cast. The preparation road in the
`livlive` skill is the whole way there, including the 要望 and the 企画書. Its 構成表 has to pass `script.check`; write it so that the character
has what this stage offers to use. The road's last two steps set this stage on the content and say what the person presses in the studio: tell
them, say first that a rehearsal uses their credits, and ask afterwards what they saw.

A thing's `about` comes back as the characters' lines: what it holds on a stage for a programme that wants dense talk is `stage-package`'s
(A thing invites a word). For a programme its cast sits through, the 構成表 names each character's role, who leads and who is the guest (its
parts, `livlive-core`), and says they stay seated throughout; the stage offers only the seats as places to go, and nothing a character would
keep using, since a thing a character can use draws the cast back to it again and again. The reference's `can` says which things are never
offered a walk (its go\_to row), and scenery can stay in the room's own shape without a row of its own (`stage-package`).

When a rehearsal did not draw what the content planned for the screen — a slide, a telop, a camera's choice — check your own side first;
once the 構成表 and the stage are seen to ask for it, what is left may be livlive's display side: tell the person so, and never rewrite the
構成表 to chase it.

**It is met when** the person has watched a character live in the stage and has told you so. Until then the stage is not done, whatever else
has passed, and you say so. What fell short is changed in the package, pushed again (`stage-package`) and rehearsed again.


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