lazyweb-design-create

Files (5)

• SKILL.md
• fetch-evidence.py
• fill-report.py
• generate-prototypes.py
• report-template.html

SKILL.md (first lines)

# Lazyweb Deep Design Research

Evidence-backed design research that reads the user's current screen, names its
frictions, forms 2-4 genuinely divergent redesign bets, and renders a visual-first
HTML report where the recommended prototype sits side by side with the control.

People learn by seeing. Every claim in the report is carried by a large, legible
visual; nothing important hides behind a click. Chrome stays quiet: no chip
clutter, no legend tables, no explanatory paragraphs next to the proof.

## MCP plan responses — check before the normal workflow

Inspect every data-bearing tool result before applying its normal search,
render, or report 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 and contains no generated research;
  do not poll, render or assemble a report, retry another data tool, or fall
  back.

## CRITICAL: Output Behavior

**This skill produces FILES, not a plan.** Regardless of whether you are in plan mode
or not, ALWAYS:

1. Author the report content as `.lazyweb/deep-design-research/{topic}-{date}/work/report-data.json` (structured content, NOT HTML)
2. Embed Lazyweb references directly with their returned `imageUrl`/`image_url`; save only current-state and web-captured screenshots under `.lazyweb/deep-design-research/{topic}-{date}/references/`
3. Do NOT create `report.md`, `report.html`, or any other report artifact by hand — the server renders the report
4. Do NOT write research content into a plan file
5. Render and host the report with `lazyweb_render_report` (see "Render and host the report" below) — this single call IS the deliverable; producing the report and hosting it are the same action, so there is nothing to skip
6. After the render call returns, show the user a concise summary, the recommended bet, and the shareable link (the report lives only at that URL)
7. Ask the user if the research looks good
8. If in plan mode, exit plan mode after the user confirms - the research is done
9. Suggest next steps: "You can now use this research to inform your implementation,
   ask `/lazyweb` to improve your current design, or start building."

The visible report is: **Agent Instructions**, **Goal**, **Recommendation**,
and optional **Inspo** — in that order. Do not produce
the older busy structure with key examples, findings, sources, broad
recommendation lists, or long prose analysis sections.

The Recommendation is built like `lazyweb-design`'s hypothesis
engine, with screenshot evidence taking the role experiment evidence plays
there: read the control, name its specific frictions, form 2-4 falsifiable and
structurally divergent bets (Safe bet / Bold bet / Wild card — a thinking
discipline, not visible chips), prototype each as a generated image, and carry
the decision. When a current page or screenshot exists, render `Control` and
the recommended prototype **side by side in equal, height-locked frames** with
a ◀ ▶ variant switcher on the right frame so the user can flip through the
other bets in place; runner-up bets also appear in a snap carousel of
same-size cards. Prefer generated bitmap prototype images over hand-coded HTML
mockups when image generation is available; use HTML/CSS only as a fallback or
when the user asks for implementation-ready code. Generate prototype images in
parallel at medium effort by default, or low effort when the user asks for
speed/exploration.

## Render and host the report (the single deliverable)

The report is rendered and hosted **server-side**. You author the report
content as `work/report-data.json`, then call `lazyweb_render_report` ONCE.
That call fills the canonical template on the server, validates it, hosts it at
`https://www.lazyweb.com/report/lazyweb/{id}/`, and returns the shareable link.
There is no local `report.html` to write, no separate publish step, and no
token to read — producing the report and hosting it are the same action, so a
finished report is always a shared report.

Call it once `work/report-data.json` and every `references/` image exist. The
report dir is `$REPORT_DIR = .lazyweb/deep-design-research/{topic-slug}-{YYYY-MM-DD}`.

Arguments:
- `report_data`: the parsed `work/report-data.json` object (see "Author report-data.json" below).
- `assets`: every file in `$REPORT_DIR/references/` as `{ "name": <filename>, "b64": <base64 of the bytes> }` — the control screenshot and each generated prototype image the report points at via `references/{name}`. Lazyweb references embedded by absolute `imageUrl` are NOT assets; only locally saved files. (Note: migrating these render assets off inline base64 to the presigned upload flow is Phase 2 — out of scope here; keep `assets:[{b64}]` as-is.)
- `report_skill`: `"deep-design-research"`.
- `idempotency_key`: the report dir slug, e.g. `deep-design-research/{topic-slug}-{YYYY-MM-DD}`. Send the SAME value on every call for this report so a retry returns the same link instead of a duplicate.
- `version`: the value you read from `~/.lazyweb/VERSION` at skill start.

Handle the result:
- `{ ok: true, url }` — the report is live. Show "Shareable link: {url} (unlisted - anyone with the link can view)", then `open "{url}"` in the user's browser (skip `open` in a headless/CI/no-GUI environment and just print the link).
- `{ ok: false, code: "REPORT_RENDER_ERROR", detail }` — `detail` names the missing or invalid `report_data` field (e.g. `missing data.topic`, `bets must have 2-4 entries`). Fix that field in `work/report-data.json` and call ONCE more.
- `{ ok: false, code: "REPORT_TOO_LARGE" }` — the embedded screenshots are too large. Reduce their number/size and retry once.
- any other `{ ok: false }` — tell the user hosting failed and why (the `error` field). There is no local copy, so they need the link or the reason.

The server fills a fixed, render-tested template and rejects an incomplete
`report_data` (missing fields → `REPORT_RENDER_ERROR`), so a partial or skeleton
report can never be hosted — that replaces the old client-side contract gate.
Never hand-render HTML or fall back to a local file.

### Image references in report-data.json

You never write HTML — you only choose image `src` values in `report-data.json`:
- Lazyweb references: the absolute `imageUrl`/`image_url` URL Lazyweb returns.
- Locally saved screenshots (current-state, web captures, generated prototypes): a relative `references/{filename}` path, with that file uploaded as an `asset` in the render call.
- Never use `file://` URLs or absolute local paths (`/Users/...`, `C:\...`).

## When to Use This

- User wants to understand a design space before building
- User needs competitive analysis for a feature
- User asks "what are best practices for X"
- User wants to see how the best apps solve a specific problem

## When NOT to Use This

- User just wants to see a few screenshots quickly -> route to `lazyweb-quick-search`
- User has an existing design and wants to optimize or improve it -> route to `lazyweb-design` (objective `optimize` or `improve`)

## Lazyweb MCP Setup

Use the hosted Lazyweb MCP tools at `https://www.lazyweb.com/mcp` for all Lazyweb database access.

Downloading or updating the skill pack, installing or configuring a client,
and creating or reusing a bearer token are available to everyone without

From LazywebHQ/lazyweb-skill, MIT.

More from LazywebHQ/lazyweb-skill