visual-review
Skill426 starsChanged 6 months agoMITView on GitHub
Take screenshots of web pages and UI using Playwright for visual review and iteration
- Installs packages
14 other projects use a version of this.
Adopted by
Most recently taken up by
- usecompai/compound-operations-modeltheir own version, first seen Nov 8, 2026
- colinhacks/frizztheir own version, first seen Nov 5, 2026
- davojta/skillstheir own version, first seen Nov 1, 2026
- markneonin/panelinetheir own version, first seen Nov 1, 2026
- robritacca-dotcom/rift-dstheir own version, first seen Nov 1, 2026
- robritacca-dotcom/design-systemtheir own version, first seen Oct 28, 2026
Other versions14 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 14
- ai-dynamo/dynamo★ 8.5ksame name
- nubjs/nub★ 4.4ksame name
- ethanplusai/astro-conversion-kit★ 114same name
- usecompai/compound-operations-model★ 31same name
- colinhacks/frizz★ 29same name
- helderberto/agent-skills★ 19same name
- markneonin/paneline★ 9same name
- robritacca-dotcom/rift-ds★ 9same name
- malinskibeniamin/skills★ 4same name
- Naoray/skills★ 2same name
4 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository19 other files it gives its agents.
- AGENTS.mdAGENTS.md
- skills/setup/templates/AGENTS.mdAGENTS.md
- templates/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- skills/setup/templates/CLAUDE.mdCLAUDE.md
- templates/CLAUDE.mdCLAUDE.md
- brainstorming-extensionSkill
- create-issueSkill
- design-review-gateSkill
- external-toolsSkill
- handling-pr-commentsSkill
- handoffSkill
- migrateSkill
- orchestrated-executionSkill
- plan-review-gateSkill
- pr-shepherdSkill
- setupSkill
- startSkill
- statusSkill
The file
We split this skill into the rules it gives an agent
10 rules. 0 are common, 4 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 13 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 39
Important: Only the chromium browser is needed.
- Very specific: line 41
If npx playwright fails entirely, the user may need to install it:
- Very specific: line 72
Use file:///absolute/path/to/file.html for local files
- Distinctive: line 73
Use full URLs for deployed sites
- Distinctive: line 108
Use the Read tool to analyze each screenshot:
- Distinctive: line 152
Use whichever approach fits the environment.
- Distinctive: line 164
Create a findings summary:
- Very specific: line 195
Vertical slides: Use #/horizontal/vertical format (e.g., #/2/1)
- Very specific: line 197
Speaker notes: Not visible in screenshots (they appear in a separate window with S key)
- Very specific: line 198
Theme loading: Use --wait-for-timeout 3000 to ensure CDN-loaded themes and fonts are ready
“Common” is measured: kept by at least 6 in 10 of the 13 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Visual Review
Purpose
Agents cannot see rendered web pages, presentations, or UI. This skill bridges that gap by using Playwright to capture screenshots of web pages (local files, localhost servers, or deployed URLs) so agents can visually inspect their work, identify layout issues, and iterate.
This is especially useful for:
- Reveal.js presentations — capture each slide individually
- Web UIs — verify layout, styling, and responsiveness
- Landing pages — check visual design matches intent
- Email templates — verify rendering
Prerequisites
This skill requires Playwright to be available. Before first use, check and install if needed:
# Check if Playwright is available
npx playwright --version 2>/dev/null
# If not available, install it (one-time setup)
npx playwright install chromiumImportant: Only the chromium browser is needed. Do not install all browsers — it wastes disk space and time.
If npx playwright fails entirely, the user may need to install it:
npm install -g playwright
npx playwright install chromiumWorkflow
Phase 1: Setup
- Verify Playwright is available — run
npx playwright --version - If not installed — run
npx playwright install chromiumand inform the user - Create output directory —
mkdir -p /tmp/visual-review - Determine the target — local file path, localhost URL, or deployed URL
Phase 2: Capture Screenshots
For a single page:
npx playwright screenshot \
--browser chromium \
--viewport-size "1456,816" \
--wait-for-timeout 3000 \
"<URL_OR_FILE_PATH>" \
/tmp/visual-review/page.pngParameters:
--viewport-size "1456,816"— 16:9 aspect ratio, good for presentations--wait-for-timeout 3000— wait 3 seconds for fonts, images, and animations to settle- Use
file:///absolute/path/to/file.htmlfor local files - Use full URLs for deployed sites
For Reveal.js presentations (multiple slides):
Capture each slide by appending the slide hash to the URL:
# Capture all slides (adjust count as needed)
for i in $(seq 0 15); do
npx playwright screenshot \
--browser chromium \
--viewport-size "1456,816" \
--wait-for-timeout 2000 \
"<BASE_URL>#/$i" \
"/tmp/visual-review/slide-$i.png"
doneTip: To capture slides with all fragments visible, add ?fragments=true or use JavaScript injection via a Playwright script. The simpler approach is to accept that fragment-heavy slides will appear in their initial (pre-click) state.
For responsive testing:
# Mobile
npx playwright screenshot --viewport-size "390,844" "<URL>" /tmp/visual-review/mobile.png
# Tablet
npx playwright screenshot --viewport-size "768,1024" "<URL>" /tmp/visual-review/tablet.png
# Desktop wide
npx playwright screenshot --viewport-size "1920,1080" "<URL>" /tmp/visual-review/desktop.pngPhase 3: Show and Review Screenshots
Use the Read tool to analyze each screenshot:
Read /tmp/visual-review/slide-0.png
Read /tmp/visual-review/slide-1.png
...Showing screenshots to the user: The agent can see screenshots via Read, but the user cannot. When the user wants to see what you see — or when you want to discuss a visual issue together — there are two approaches depending on the environment:
Local machine (has a display):
# Open a specific screenshot
open /tmp/visual-review/slide-2.png
# Open all screenshots at once
open /tmp/visual-review/slide-*.pngRemote/headless machine (SSH, tmux, etc.):
Serve the screenshots directory over HTTP so the user can view them in their local browser:
# Start a simple file server (runs in background)
# Use a high port (>10000) to avoid conflicts with dev tools
python3 -m http.server 18080 --directory /tmp/visual-review &
# User can now browse to:
# http://<hostname>:18080/
# http://<hostname>:18080/slide-2.png
# etc.Pick any open high-numbered port (18080, 19090, etc.) — low ports like 8080 are often taken by dev tools. This serves the entire /tmp/visual-review/ directory with an auto-generated file listing. The user can click through all screenshots in their browser. Stop the server when done:
# Stop the background server
kill %1
# Or find and kill by port
lsof -ti:18080 | xargs killUse whichever approach fits the environment. This is useful when collaborating on visual issues, when the user asks what something looks like, or when you want confirmation on a subjective design choice.
For each screenshot, evaluate:
- Layout — Is content centered/aligned as intended?
- Typography — Are headings, body text, and code readable?
- Colors — Do accent colors, backgrounds, and contrasts look right?
- Spacing — Is there enough whitespace? Any cramped areas?
- Content — Is all expected content visible? (Note: fragment content may be hidden)
- Responsiveness — Does it work at the target viewport size?
Phase 4: Document Findings
Create a findings summary:
## Visual Review — [Project Name]
### Reviewed: [date]
| Slide/Page | Status | Notes |
|-----------|--------|-------|
| slide-0 | Good | Title centered, accent color correct |
| slide-1 | Issue | Text overflows right edge on mobile |
| ... | ... | ... |
### Issues to Fix
1. [Description of issue + which slide/page]
2. [...]
### Looks Good
- [Things that are working well]Phase 5: Fix and Re-capture
After making fixes:
- Re-capture only the affected slides/pages
- Review the new screenshots
- Repeat until satisfied
Reveal.js-Specific Tips
- Slide numbering: Reveal.js uses
#/0for the first slide,#/1for the second, etc. - Vertical slides: Use
#/horizontal/verticalformat (e.g.,#/2/1) - Fragments: Content with
class="fragment"is hidden until clicked. Screenshots show the initial state. This is expected behavior, not a bug. - Speaker notes: Not visible in screenshots (they appear in a separate window with
Skey) - Theme loading: Use
--wait-for-timeout 3000to ensure CDN-loaded themes and fonts are ready
Common Mistakes
| Mistake | Why It's Wrong | Do This Instead |
| Not waiting for page load | Fonts/images may not render | Use --wait-for-timeout 3000 |
Using http:// for local files | File URLs need file:/// protocol | Use file:///absolute/path |
| Installing all Playwright browsers | Wastes time and disk | Only install chromium |
| Treating fragment-hidden content as a bug | Fragments are designed to reveal on click | Note it as expected |
| Forgetting to create output directory | Screenshots fail silently | Always mkdir -p /tmp/visual-review first |
| Taking too many screenshots at once | Floods context window | Review in batches of 4-6 |
Not offering to open when discussing visuals | User can't see what you're describing | Use open when collaborating on visual issues |
Integration Points
Upstream: Any skill that produces visual output (presentations, web UIs, email templates)
Downstream: Fixes feed back into the source files, then re-capture to verify
Verification Checklist
- Playwright is installed and working
- Screenshots captured at correct viewport size
- All pages/slides reviewed
- Issues documented with specific descriptions
- Fixes verified with re-captured screenshots
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
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.

