agentleFS
bestdeejay-designbestdeejay-design/agent-skills/skills/web-replication/SKILL.md

web-replication

Skill6 starsChanged 3 months agoMITView on GitHub

Frontend visual replication skill. Explores a target website's publicly visible pages via Playwright MCP, captures screenshots and layout information, then generates a static or client-side frontend replica that approximates the original's visual appearance and page structure. Replicates FRONTEND PRESENTATION ONLY — no backend, databases, or non-public content.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    No external dependencies needed.

    line 31
  2. Distinctive:

    Before proceeding, MUST ask the user:

    line 35
  3. Distinctive:

    If cannot confirm → STOP. Suggest building an original design instead.

    line 40
  4. Distinctive:

    Never scrape behind a login wall

    line 54
  5. Distinctive:

    Never collect credentials, API keys, or PII

    line 55
  6. Distinctive:

    Never reproduce copyrighted content verbatim unless user holds rights

    line 56
  7. Distinctive:

    After all pages collected:

    line 200
  8. Distinctive:

    Start the replica locally

    line 235
  9. Distinctive:

    Do not use to copy proprietary content or bypass access controls.

    line 261

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Website Frontend Visual Replication

Origin: Adapted from zai-org/GLM-skills/glmv-web-replication (Apache 2.0). Agent-browser replaced with Playwright MCP (built into OpenCode).

Prerequisites

This workflow uses Playwright MCP (built into OpenCode via playwright_browser_* tools). No external dependencies needed.

Authorization Gate (MUST execute first)

Before proceeding, MUST ask the user:

"Do you own this website, or do you have explicit written permission from the owner to replicate it? Unauthorized replication may violate copyright, terms of service, or applicable law."

  • If confirmed → proceed
  • If cannot confirm → STOP. Suggest building an original design instead.

Scope & Limitations

IncludedNOT Included
Page layout & visual stylingBackend / server-side logic
Navigation structureDatabases & data stores
Publicly visible text & imagesAuthentication systems
CSS/design tokensAPI business logic
Client-side interaction patternsNon-public content
Static asset files (images, fonts)Credentials, secrets

Data handling rules:

  1. Never scrape behind a login wall
  2. Never collect credentials, API keys, or PII
  3. Never reproduce copyrighted content verbatim unless user holds rights
  4. Respect robots.txt and rate limits

Core Idea

  1. Recursively explore every public page, record visual content, interactions, and assets into a structured "blueprint" with nested folders representing navigation relationships.
  2. Build a frontend visual replica based on that blueprint.
  3. Visually compare and revise.

Blueprint Structure

blueprint/
├── _meta.md                      # Site metadata
├── _sitemap.md                   # Sitemap
├── _assets/                      # Global assets (fonts, favicon)
├── _navigation_graph.md          # Navigation graph (Mermaid)
├── home/                         # Homepage
│   ├── _page.md                  # Page blueprint
│   ├── _full.png                 # Full-page screenshot
│   ├── _scroll_00.png ~ N.png    # Scroll sequence
│   ├── _interactions.md          # Interaction records
│   ├── _interactions/            # Interaction state screenshots
│   ├── _assets/                  # Page-specific assets
│   ├── products/                 # Child pages (reachable from here)
│   │   ├── _page.md
│   │   ├── _full.png
│   │   └── ...
│   └── about/
│       └── ...

Replication Workflow

Step 1: Initialize

mkdir -p blueprint/_assets

Open the target site with Playwright:

playwright_browser_navigate url="<target URL>"
playwright_browser_resize width=1920 height=1080
playwright_browser_wait_for time=3

Write blueprint/_meta.md:

# Website Replication Blueprint
- Target website: <URL>
- Exploration date: <date>
- Viewport size: 1920×1080

Step 2: Recursively collect pages

For every page, execute this procedure:

2.1: Capture and analyze

playwright_browser_take_screenshot fullPage=true filename="blueprint/<page>/_full.png"
playwright_browser_snapshot    ← get interactive elements

2.2: Download assets

Collect all image/video/font URLs from the page snapshot, download with curl:

curl -o blueprint/<page>/_assets/image.jpg "<image_url>"

2.3: Traverse interactions

For each interactive element found in the snapshot:

# Hover
playwright_browser_hover target="<element>"
playwright_browser_take_screenshot filename="blueprint/<page>/_interactions/hover.png"

# Click (may trigger navigation)
playwright_browser_click target="<element>"
playwright_browser_wait_for time=2
playwright_browser_take_screenshot filename="blueprint/<page>/_interactions/click.png"

# If navigation happened, capture the new page as a child
playwright_browser_snapshot   ← check if URL changed

# Go back
playwright_browser_navigate_back

2.4: Scroll and repeat

playwright_browser_press_key key="PageDown"
playwright_browser_wait_for time=1
playwright_browser_take_screenshot filename="blueprint/<page>/_scroll_N.png"

Continue until bottom of page.

2.5: Document the page

Write blueprint/<page>/_page.md:

# <Page Name>
- URL: <path>
- Source: <how we got here>

## Section Structure
| No. | Section Name | Layout Pattern | Content Type |
|------|--------------|----------------|--------------|
| 1 | ... | ... | ... |

## Screenshots
- Full: !_full.png
- Scrolls: !_scroll_00.png ... !_scroll_N.png

## Outbound Navigation
| Trigger | Method | Target | Child Folder |
|---------|--------|--------|--------------|
| ... | click | /path | ./child/ |

## Assets
| File | Purpose |
|------|---------|
| _assets/img.jpg | ... |

Write blueprint/<page>/_interactions.md:

# Interactions

| Element | Trigger | Behavior | Navigation | Screenshot |
|---------|---------|----------|------------|------------|
| ... | click | ... | Yes → ./child/ | ![](_interactions/click.png) |

Step 3: Generate summaries

After all pages collected:

blueprint/_sitemap.md

# Sitemap
home/                          # /
├── products/                  # /products
│   ├── product-detail/        # /products/:id
│   └── category/              # /products/category/:slug
├── about/                     # /about
└── blog/                      # /blog
    └── blog-post/             # /blog/:slug

blueprint/_navigation_graph.md

# Navigation Graph
graph LR
    Home["home /"] -->|Nav - Products| Products["products /products"]
    Home -->|Nav - About| About["about /about"]
    Products -->|Card click| Detail["product-detail /products/:id"]

Step 4: Frontend Visual Replication

Based on the blueprint, build a frontend replica:

  • Match layout, colors, typography, spacing from screenshots
  • Implement navigation between pages
  • Use downloaded assets
  • Match interaction patterns (hover states, filters, etc.)

Recommended stack: HTML + CSS + vanilla JS, or React/Tailwind if complex.

Step 5: Visual Comparison & Revision

  1. Start the replica locally
  2. Open both original and replica side by side (two browser tabs)
  3. Compare page by page: layout, colors, typography, navigation
  4. Fix discrepancies
  5. Repeat until satisfied

Key Rules

  1. Authorization first — never start without user confirmation
  2. Public pages only — no login-protected areas
  3. No credential handling — redact any found credentials
  4. Frontend only — no backend replication
  5. Folders = navigation — if page A links to page B, B is a subfolder of A
  6. Every folder needs: _page.md, _full.png, _interactions.md, _interactions/, _assets/
  7. Screenshots from real site — never describe from memory
  8. Interactions genuinely triggered — hover, click, focus, one by one
  9. Download assets — curl for images, Playwright eval for SVGs
  10. Record only — document results without quality judgments
  11. Keep files updated — real-time updates after each page exploration
  12. Visible elements — scroll into view before interacting
  13. One action per Playwright call — no combining multiple commands
  14. External links — record URL + trigger element, don't deep-explore
  15. Both full and scroll screenshots — overall + detail reference

Boundaries

  • Do not use to copy proprietary content or bypass access controls; use it only for authorized references.

Evidence and completion gate

Ground recommendations in the supplied repository or brief. State assumptions, missing inputs, and unresolved risks. Return a concrete artifact or checklist with an owner/action for each open item, then verify that the result answers the requested goal rather than merely repeating the framework.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.