Live Site Design

Overview

Redesign the live page in the browser first, not in source code. Use this skill to turn a user request into a polished browser-side implementation, then hand off a clear output directory that another coding agent can use to reproduce the change in real code.

This skill assumes playwright-cli is available. Treat it as the default browser control surface for opening a page, inspecting state, taking screenshots, and applying temporary DOM/CSS changes.

If this skill is active for a task, do not stack any other design-related or browser-use-related skill on top of it. Use one controlling skill to avoid conflicting prompts, duplicate review loops, or mismatched output expectations.

If this skill is active for a task, explicitly do not invoke superpowers:brainstorming.

If playwright-cli actions start timing out, try increasing the timeout temporarily with:

export PLAYWRIGHT_MCP_TIMEOUT_ACTION=30000

Default to headless. Switch to headed only when the task clearly requires user takeover, such as login, MFA, CAPTCHA, or another manual checkpoint that the agent cannot complete alone.

This skill uses two roles:

• designer: explores, patches, and refines the live page
• visual-reviewer: a fresh subagent or otherwise isolated context that judges frozen evidence only

Quick Start

1. Decide the entry mode:
   • If the user gave a URL, open the browser session and navigate there.
   • If the user wants the current logged-in page preserved, attach to the current page first and avoid reloading unless necessary.
2. Establish the output workspace before doing anything else:
   • Choose one final output directory for the task up front.
   • Create <output>/tmp/ immediately and treat it as the default location for all temporary screenshots, draft scripts, reviewer scratch files, and intermediate artifacts.
   • Do not scatter temporary files across unrelated folders if they belong to this task.
3. Explore before changing anything:
   • Identify the exact target area, page language, brand styling, and blocking popups.
   • Use targeted browser-side inspection before you design: inspect computed styles, spacing, bounds, and stable selectors.
   • Take a clean before screenshot once the viewport is in the right state.
4. Propose three design directions:
   • Write 3 clearly different high-level directions based on what you found.
   • Keep them strategic, not micro-tweaks.
   • Ask the user to confirm one direction unless they explicitly asked for autonomous selection.
5. Implement only the chosen direction live:
   • Prefer one strong direction over multiple half-finished variants.
   • Keep changes static and reversible: DOM structure, copy, spacing, color, typography, hierarchy.