メインコンテンツへスキップ
このページは、エージェントが読む skill「stage-lead」の本文です。
いまは招待制βの準備中です。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.
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.