| name | lazyweb-propose-ui-changes |
| route | Propose reviewable UI/flow changes on a diagram (Accept/Decline) |
| router-terms | propose changes, suggest UI changes for review, review my suggestions, let me review your suggestions, annotate this flow, annotate this diagram, create a proposal, review and approve these changes, approve or reject changes, hosted proposal, explain this architecture visually |
| router-exclude | true |
| description | Propose UI/flow changes (or explain context) on a STRUCTURED DIAGRAM that the
user reviews and Accepts/Declines on a hosted lazyweb.com page, then apply the
accepted ones. Use when the user wants a reviewable set of proposed changes to
a product's UI, architecture, or flow — anything where you'd otherwise list
suggestions in chat and want the user to approve/reject each before you act.
Trigger on: "propose changes", "suggest UI changes for review", "let me
review your suggestions", "annotate this flow/diagram", "create a proposal",
"review and approve these changes", "explain this architecture/flow visually".
|
| allowed-tools | ["Bash","Read","Write","Glob","Grep","AskUserQuestion","Agent"] |
Lazyweb — Propose UI Changes
Propose changes against a structured diagram you build from the real code:
you supply the current diagram, annotate its elements, and supply a proposed
version; the user opens a lazyweb.com/proposal/<id>/ page, toggles Current ↔
Proposed to see before/after, and Accepts / Declines each suggestion; then
you apply the accepted ones.
This skill drives these Lazyweb MCP tools:
lazyweb_health — verify MCP connectivity when the surface is uncertain.lazyweb_propose_ui_changes — store a proposal (current + proposed + annotations), get a review URL.lazyweb_get_proposal_decision — poll the user's accept/decline verdicts.
Prerequisite: the Lazyweb MCP must be connected and current. If
lazyweb_propose_ui_changes isn't in the tool list, the skill pack/MCP is out
of date — tell the user to update (curl -fsSL https://www.lazyweb.com/install.sh | sh)
and restart their client.
MCP plan responses
Inspect every data-bearing tool result before applying its normal schema:
MCP_PRO_REQUIRED: relay the server message and returned intent-bound
upgrade_url to the user, then stop. Do not retry another data tool or fall
back to web/manual output.FREE_REPORT_DAILY_LIMIT: relay the server message and returned intent-bound
upgrade_url to the user, then stop. Do not retry another data tool or fall
back to web/manual output.- Successful
status: "locked_preview": relay display_to_user verbatim (or
the returned MCP text if that is all the client exposes), including the
preview and upgrade links. It is terminal: do not poll, retry another data
tool, reconstruct output, or fall back.
When to use
- The user wants to see and approve/reject a batch of changes before you make them.
- You want to explain how a system/flow works by annotating a diagram they can click.
- Changes span several places and a chat list would be hard to review.
When NOT to use
- A single trivial edit you can just make — don't ceremony it into a proposal.
- Pure design-from-screenshots work — use
lazyweb_generate_report / the design skills.
The data you build
A proposal = (the current state, nodes + edges each with a stable
, built from the REAL code) + (a full copy of that diagram
with your changes applied) + (one per suggestion, targeting
node/edge s). The viewer shows Current from and Proposed from
, and lists the annotations to Accept/Decline.
