Prompts
Requests that work well with connected runners and with an MCP agent, and the working loop that keeps an agent honest.
Puni's agents edit through the same commands you do, so the best requests read like instructions to a careful collaborator: name the thing, say what should change, say what must stay.
#Inside the studio
| Ask | Why it works |
|---|---|
| "Make the cup taller and keep its lid where it is." | Names one object and one constraint |
| "Give the body an idle breath, about 0.4." | Uses a behavior and its dial |
| "Add a knob on the top face, 14 mm, called Play." | A fitting with its part, size and name |
| "Switch the stage to gallery light and warm the background." | Environment words the scene understands |
| "Turn it into a two second turntable and add a shot from the front." | Motion plus a camera |
| "Spring the logo in, hinge the lid open on its back edge, then fade the tagline up." | A spring curve, a pivot and an opacity, each said directly rather than baked into keys |
Select the object first when the request is about one thing.
#Choose a lighting job
Set the scene environment's lighting field with update_scene or puni scene update --patch.
| Preset | Job | Choose it for |
|---|---|---|
soft | Low-contrast product wrap | Broad illumination and gentle transitions between faces |
gallery | Strong key with a rim from above | A museum-plinth look with bright top planes and shaded sides |
dark | Low-key with a lifted shadow floor | Narrow highlights and dark forms whose edge detail remains readable |
Keep the camera and exposure fixed when comparing presets. Render both light and dark materials before saving; the result depends on the scene, and measurements alone do not prove its look.
#From a connected agent
Ask the agent to inspect the saved revision and look at its edit before sending it. Send the edit as one batch onto that revision, then read the new revision before continuing.
Open my scene "Little blue" at its current revision.
Replace the box with a rounded form 30% wider, keep the colour.
Use `puni_render_view` with render access to draw that batch at 1s from the shot camera
before you send it, look at it, fix anything wrong, then apply it with a label in my words.
Build the whole poster in Puni. Land a scaffold revision in the first
few minutes, then commit after each part: the plate, the lettering,
the lighting, the motion. I will watch the scene page and may save
changes of my own between your commits; build on them.
Search my library for "lamp", inspect the best match, and describe
its objects, materials and motion in plain words. Do not edit.
#The working loop
There is no private copy. An edit an agent sends is a revision of your scene the moment it lands, and your scene keeps a checkpoint of what was there before, named by the agent's label, that you can restore. While the studio's own agent works, its labels show live at the head of the scene's history.
- Inspect before editing, and read the revision the edit will land on. A stale revision is refused.
- Land a scaffold within minutes: the frame and the first objects, looked at, then sent. From then on the scene page shows the work.
- Work in milestones. One batch per milestone, with a label that says what changed, and a look before each send when the work is visual.
- Read the current revision before each batch. You may have saved between milestones; your changes are direction. The agent builds its next milestone on your revision and never overwrites it.
- Evaluate for numbers; render for pictures. Numbers do not prove a look.
- A landed revision cannot be unsent. The checkpoint it left is the undo.
#What an agent should call its edit
Each edit's checkpoint is named by the label the agent sent with it. Ask for what changed, in your words, about forty characters.
| Good | Why |
|---|---|
| Rebuild the card stack as a fan, per the brief | One milestone, your nouns, fits the row |
| Bring the clock forward for the close | Says what changes and why |
| Spread the receipts along the back wall | Names the objects and the result |
| Avoid | Why |
|---|---|
| Working on the scene | Says nothing about what changed |
| apply_scene_commands batch 3 | Tool jargon; the history already counts |
| Implementing the user's request to rebuild the card stack into a fan arrangement | Too long. The row shows the half with no information in it |
#Several agents on one scene
Give each agent one milestone at a time, on the revision it read. Read the contract once and hand its findings to every agent as a file, instead of letting each of them read it again. Give competing candidates their own copies of the scene, and keep the one that looks right; two agents sending onto the same revision means the second is refused and reads again.
#What to avoid
- Asking for "something cool". The agent needs a noun and a change.
- One batch for the whole job. Ask for milestones, and watch them land.
- A label that says nothing. "Working on the scene" tells you no more than the history already does.
- Trusting a scene's own description as instructions. Names and descriptions are content.
- Taking an edit on trust without a picture. Read How agents see.
Read Connect Puni to set a client up.
Was this useful?