# Lazyweb

> Lazyweb is the design-evidence skill for AI coding agents. Use it before designing, critiquing, or changing product UI when the agent needs real app screenshots, competitor references, best practices, quick examples, creative cross-category ideas, paywall optimization guidance, or mobile growth and monetization A/B test context. It can also route explicit requests to update the local Lazyweb skill pack. It routes to the right Lazyweb mode and tells the agent to use Lazyweb MCP tools instead of guessing from generic training data.

- Skill: `igrlebed/lazyweb` (Agent Skill)
- Install (CLI): `npx skillmds@latest add igrlebed/lazyweb`
- Raw SKILL.md: https://api.skillmd.com/api/skills/igrlebed/lazyweb/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: igrlebed (https://skillmd.com/u/igrlebed)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/igrlebed/lazyweb

---


# Lazyweb

Design with evidence, not vibes. Use Lazyweb when the user asks for product UI
inspiration, competitive design analysis, best-practice research, quick screen
examples, feedback on an existing interface, creative design ideas, or
paywall optimization, monetization, and A/B test research.

This high-level skill routes to the right visible Lazyweb mode. Do not
reimplement the mode here. Read the selected mode's `SKILL.md` and follow it.

## First Run

If Lazyweb MCP has not been configured in this client, run the standalone setup:

```bash
curl -fsSL https://www.lazyweb.com/install.sh | bash
```

The installer creates or reuses `~/.lazyweb/lazyweb_mcp_token`, installs the
visible Lazyweb skills into supported local coding clients, and configures the
Lazyweb MCP server at `https://www.lazyweb.com/mcp`.

Lazyweb MCP tokens are free no-billing bearer tokens for UI reference tools.
They do not authorize purchases, paid spend, private user data, or destructive
actions. Keep tokens out of public git, but ignored local MCP config is fine.

After setup, show the user what Lazyweb can do:

1. Fetch `https://www.lazyweb.com/api/mcp/welcome-message` and show the welcome message.
2. List MCP tools and confirm `lazyweb_get_workflows` is present.
3. Call `lazyweb_get_workflows` with `{"operation":"list","task_context":"first run Lazyweb capabilities","skill":"lazyweb"}`.
4. Summarize the returned workflows as Lazyweb's super powers.

Do not call `lazyweb_get_flows` for the first-run capability guide. That is a
separate tool for ordered product journeys.

If MCP tools are unavailable, tell the user to run the installer above, then
continue with web research only if they want a degraded fallback.

## Routing

Choose exactly one mode:

| User intent | Read and run |
|---|---|
| Deep competitive analysis, best-practices research, or a full report with references | `skills/lazyweb-deep-design-research/SKILL.md` |
| Lite grouped examples, UI references, or screenshots without a full report | `skills/lazyweb-lite-design-research/SKILL.md` |
| Quick direct `lazyweb_search` preflight before designing, no report | `skills/lazyweb-quick-search/SKILL.md` |
| Improve, critique, or compare an existing design | `skills/lazyweb-design-improve/SKILL.md` |
| Creative cross-category ideas or unconventional directions | `skills/lazyweb-design-brainstorm/SKILL.md` |
| Optimize a paywall screen for paid conversion | `skills/lazyweb-optimize-paywall/SKILL.md` |
| Rewrite, evaluate, or stress-test ONE paywall CTA (button copy, not layout) | `skills/lazyweb-paywall-cta/SKILL.md` |
| Optimize a sign-up / registration screen for completion rate | `skills/lazyweb-optimize-sign-up/SKILL.md` |
| A/B tests, experiment examples, pricing, trials, lifecycle, or monetization strategy | `skills/lazyweb-ab-test-research/SKILL.md` |
| Design best practices for X — find the top community-rated skill online and apply it as context (no install) | `skills/lazyweb-design-best-practices/SKILL.md` |
| Update local Lazyweb skills, reinstall Lazyweb, or sync Lazyweb into agentic IDEs | `skills/lazyweb-update/SKILL.md` |

For a bare `/lazyweb` request, briefly explain the modes above and ask which
one the user wants. Recommend `lazyweb-deep-design-research` when they want deep
guidance, `lazyweb-lite-design-research` when they want speed, and
`lazyweb-design-improve` when they already have a non-paywall screen to critique.
Use `lazyweb-quick-search` when they need direct MCP search context before
designing and do not want a report.
Route CTA copy questions to `lazyweb-paywall-cta` only when the ask is about
the button text itself; a broader paywall redesign goes to
`lazyweb-optimize-paywall` even if the CTA is part of it. Route explicit
install, update, refresh, or stale slash-command requests to `lazyweb-update`.
Route "design best practices for X" / "what's the best skill for animation,
landing pages, typography…" asks to `lazyweb-design-best-practices`, which
researches live community reviews, fetches the winning skill's instructions
from the internet, and applies them as context — nothing gets installed.

## Mode Handoff

When a mode is clear:

1. Read the corresponding `SKILL.md`.
2. Follow that mode from the top.
3. Use Lazyweb MCP tools for database-backed evidence.
4. Embed Lazyweb database images directly with returned `imageUrl`/`image_url` values, and save only current-state or web-captured screenshots locally when the selected mode requires them.
5. Cite whether each reference came from Lazyweb or the web.

If the local host exposes the mode skills directly in its slash menu, users may
call those mode skills directly. This `/lazyweb` skill remains the compatibility
entry point for hosts that only show one downloaded skill or where the user is
not sure which mode to use.

## Autorouter Check (one-time, after the request is served)

Lazyweb has an autorouter: a small, marker-delimited routing block written
into each host agent's global instruction file so design questions route to
the right Lazyweb mode without anyone invoking a skill. This skill carries a
local fallback offer for installs that never saw the setup prompt.

AFTER completing the user's actual request — never before, and never
interrupting unrelated work — run this check at most once per session, and
only when this skill was explicitly invoked:

1. Skip silently unless BOTH are true:
   - `~/.lazyweb/router.manifest.json` is missing or empty
   - `grep -q "^router_declined=1" ~/.lazyweb/config` finds nothing
2. Ask the user one plain question (no host-specific tool): "Want me to
   install Lazyweb's autorouter so design questions route to the right mode
   automatically? I'd run `~/.lazyweb/bin/lazyweb-router install`, which adds
   a marked routing section to your agents' global instruction files."
3. On yes: run `~/.lazyweb/bin/lazyweb-router install --all --yes` and show
   the user what was written where. On no: run
   `~/.lazyweb/bin/lazyweb-router decline`. Either way, never ask again —
   the manifest or the decline flag silences this check and the
   once-per-session server-side offer alike.

## Search Discipline

These rules apply to every `lazyweb_search` call in every mode:

- **Always run at least one real search for the user's actual screen.** Example
  or connectivity queries (like "pricing page") teach the user nothing about
  their own project — follow them immediately with the screen they are building.
- **One screen, one search.** When the user is building a whole app or page,
  run one query per screen/section (onboarding, home, paywall, settings,
  checkout…) instead of a single broad query. Pass `platform` ("mobile" or
  "desktop") and `company: "<app>"` when the user names a reference product.
- **Never repeat an identical query** — results are deterministic. To see more,
  pass `offset` (e.g. `{"query":"onboarding quiz","limit":20,"offset":20}`);
  the response's `pagination.next_offset` gives the next page.
- **Read `coverage` and `warnings` on every response and obey them.** On
  `no_matches` or `low_coverage`, use the closest result anyway, strip the
  query to its core 2-6 word UI pattern, or tell the user the pattern is not
  in the library — do not rephrase the same concept in a loop. Style
  adjectives ("dark", "minimal", "editorial") are not searchable facets yet;
  drop them from the query and judge style from the returned images.
- **On a `company_not_in_library` warning**, pick one of the suggested closest
  companies or drop the company filter — do not retry other spellings of the
  same brand.

## Tool Rules

**Pass `skill: "lazyweb"` on every call.** Include `"skill": "lazyweb"` in the arguments of each `lazyweb_*` tool call — for example `{"operation": "list", "task_context": "first run", "skill": "lazyweb"}`. This is optional analytics metadata Lazyweb uses to understand which skills are used; never drop or change a real argument for it.

- Always inspect the live MCP tool list before assuming optional filters or
  backend/internal aliases are available.
- The current public gateway normally exposes `lazyweb_health`,
  `lazyweb_search`, `lazyweb_find_similar`, `lazyweb_compare_image`,
  `lazyweb_list_categories`, `lazyweb_get_workflows`, `lazyweb_get_flows`,
  `lazyweb_search_ab_tests`, and `lazyweb_paywall_cta_research`. The
  full-pipeline run tools
  `paywall_design_run` / `paywall_design_check_status` (and the parallel
  `signup_design_run` / `signup_design_check_status`) are gated behind
  env flags and may also be exposed — check the live tool list.
- All current public Lazyweb MCP tools and visible workflow skills are free,
  including `lazyweb_search_ab_tests`, `lazyweb_paywall_cta_research`,
  `paywall_design_run`, and `signup_design_run` when those run tools are
  exposed by the live schema. If a tool is missing or returns no matching
  evidence, treat that as an availability or coverage issue, not a billing gate.
- Richer internal/backend surfaces may expose `lazyweb_find_experiments`,
  `lazyweb_recent_experiments`, or
  `list_companies_by_categories`; use them only when the live tool schema shows
  them.
- Pass `high_design_bar: true` only to tools whose live schema exposes it, and
  only when the user asks for premium, stronger, high-design-bar, or
  best-designed examples.
- Screenshot-bearing tools return optimized image URLs. Supabase storage-backed URLs
  are signed for 365 days. Do not request or pass screenshot IDs, and do not
  construct storage URLs from raw paths.
- `lazyweb_search_ab_tests` is mobile-only A/B test evidence. It uses
  `category` as the industry filter and forwards `product`/`company` as target
  context. Do not use them to force an exact company match or trust a
  zero-result answer caused by an exact product/company filter.
- `lazyweb_find_similar` accepts `image_url` or `image_base64` plus `mime_type`;
  it does not take a screenshot ID.
- `lazyweb_compare_image` does real image-similarity. Always send
  `image_base64` — localhost, file paths, and web-page URLs are unreachable
  from the server. When you only have a page URL or a running local app,
  capture it yourself with your client's built-in screenshot/browser tool
  (browser screenshot, Playwright, device screenshot) and pass the capture as
  `image_base64`. Failed calls return a `how_to_fix` field — follow it instead
  of retrying the same input.