lavish

name	lavish
description	Use when work requires a browser review surface because terminal output cannot clearly preserve interactive exploration, structured browser feedback, visual fidelity, or spatial relationships.

Lavish Editor

Lavish turns an HTML artifact into a collaborative browser review surface. The coding agent creates and revises the artifact, and the user reviews it through annotations, queued prompts, and browser interaction. Use Lavish only when the browser preserves meaning or interaction that a terminal-native response would lose.

Use this authority order for artifact decisions:

1. Follow the user's requested content, interaction, and visual direction.
2. Follow verified evidence from the target project.
3. Apply guidance from each matching Lavish playbook only when it is material to the review question or supported by current evidence.
4. Use Lavish design defaults only when the higher authorities do not decide the question.

Request

$ARGUMENTS

If the request above is non-empty, the user invoked /lavish explicitly. Treat that invocation as confirmation and follow the workflow below.

Select the review surface

If the request is empty, first evaluate whether prose, Markdown structure, a table, a code block, or a terminal-native diagram preserves the required meaning. Use the terminal-native representation and stop the Lavish path when it is sufficient.

Propose Lavish only when at least one of these conditions applies:

• The user must explore behavior through a running artifact.
• The user must annotate specific visual elements or selected text and send structured feedback through the artifact.
• The user must review visual fidelity, rendered UI, screenshots, layout, or other appearance that terminal output cannot preserve.
• The material has dense spatial relationships that would lose necessary meaning in a terminal-width representation.
• The workflow requires Lavish interaction such as editable Mermaid whiteboards or queued browser feedback.

Keep the work in Pi when a plan, comparison, table, diagram, code diff, report, or substantial detail remains clear in the terminal. When the browser is necessary, explain briefly what meaning or interaction the terminal would lose and ask the user to confirm Lavish. Create no artifact and call no Lavish review tool until the user confirms.

Selection is complete when either the terminal-native path is selected or the user has authorized Lavish for a named browser-only need.

Prepare the artifact

1. State the question that the artifact must help the user answer and identify its audience. When the user asks for a prototype or the question requires interactive exploration of proposed behavior or design, read Lavish prototypes before selecting the artifact structure. Preparation scope is complete when the artifact has one explicit review question, an identified audience, and an applicable artifact branch.

2. Before writing HTML, call lavish_reference(action: "design") to load the content router and design guidance. Open every playbook whose returned use_when condition matches the artifact. Do not add alternatives, failure modes, migration, or compatibility scope only to satisfy a playbook checklist. If required reference output is truncated, read the reported full-output file before continuing. If required guidance cannot be loaded, report the dependency failure and stop before writing the artifact. Reference loading is complete when the design guidance and every matching playbook are available.

3. Select the design source through the authority order above. Inspect the target project's design system when the artifact represents that product. If required project evidence is unavailable, ask the user rather than claiming project fidelity. Design selection is complete when the chosen source and its supporting evidence are explicit.

4. Create the HTML artifact at a unique path, normally .lavish/reviews/<task-id>.html in the working directory. Place required local images, CSS, fonts, and scripts beside the artifact and reference them with relative paths. Before depending on a remote CDN or screenshot, confirm that the review environment provides it. When it does not, use verified project-local assets or a simpler self-contained representation. If neither preserves the required meaning, report the unavailable dependency and stop before review. Artifact preparation is complete when the file opens directly, required assets resolve, and the review question is inspectable at desktop and narrow widths.

Run the review

Use the Pi Lavish tools instead of raw shell Lavish commands when the tools are available.

1. Call lavish_review(file: "<html-file>", initialReply: "<one-line summary of what to review first>"). The review is open when the tool reports the session URL and begins waiting for browser feedback.

2. Wait for user feedback, a user-ended signal, or artifact_failures. Do not final-answer while the tool is waiting. This step is complete when the tool returns one of those states.

3. Resolve returned feedback against the artifact and review question. Apply requested artifact changes to the authoritative source. Respond to questions, acknowledgments, and decisions without editing the artifact unless they require a content change. Treat a queued layout-warnings prompt as an explicit repair request and apply every listed fix in one pass. Leave passive layout findings unchanged until the user queues them. After saving layout fixes, let Lavish load the newer artifact revision and treat the warning as unresolved until newer browser evidence clears it. For whiteboard feedback, read the bounded summary first and inspect scenePath or previewPath only when the summary is insufficient. Apply requested diagram changes to the authoritative Mermaid source and leave generated scene files unchanged. Repair artifact_failures before continuing because they make the review surface unusable. Feedback resolution is complete when each requested change is saved for browser re-check, each reply-only item has a prepared response, and every unresolved conflict is explicit.

4. Call lavish_review(file: "<html-file>", agentReply: "<message>") to reply in the browser and wait again. Repeat the feedback loop until the user is satisfied or asks to stop. Use reopen: true only when the user asks for further review or important new content requires renewed attention. The loop is complete when the browser reviewer is satisfied, asks to stop, or ends the session.

5. Call lavish_end(file: "<html-file>") when the review finishes without a browser-ended signal. If the user ends the session in the browser, stop polling and continue in Pi without reopening it. The review is complete when no poll is active and the session has ended through the browser or lavish_end.

The active lavish_review call is the bridge between the browser conversation and Pi. Do not respond with only the session URL and then stop.

Artifact guidance

• Make the question, primary decisions, material risks, and next actions visually prominent.
• Use structure that preserves the content's meaning, such as sections, tables, diagrams, annotated code, or side-by-side comparisons.
• Prevent horizontal overflow at every nesting level.
• Give nested grid and flex children shrinkable tracks and min-width: 0 where wide labels, paths, or monospace content can force overflow.
• Wrap, truncate, or contain long unbreakable text deliberately.
• Show verified existing UI or current visual state instead of describing it when a supported read-only capture interface is available.
• When capture is unavailable, state that limitation and use verified project assets or prose rather than fabricating a screenshot.
• Use prose for rationale and details that cannot be shown.
• Treat remote CDN and font references as network dependencies.
• Treat browser publishing through third-party services as public and obtain explicit user intent before publishing.

Deliver the result

Use lavish_export only when the user asks for a portable or standalone copy. Inspect unresolved_local_assets and notices before presenting an export as complete. A portable export may retain remote network dependencies, and its ordinary artifact interaction may outlive Lavish-specific feedback behavior.

In the final Pi response, report:

• the artifact path;
• the design source and why it applied;
• the review outcome;
• unresolved failures or uncertainty;
• the export path and remaining dependencies when export was requested.

Delivery is complete when the user can locate the authoritative artifact, understand the review result, and identify every unresolved dependency or limitation.