live-preview
Skill927 starsChanged 16 days agoMITView on GitHub
Mid-build visual verification loop. Takes screenshots of components during construction, not just after. Catches visual regressions and invisible features before they compound. Requires Playwright or similar screenshot tool.
- Installs packages
We split this skill into the rules it gives an agent
17 rules. 0 are common, 15 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
15
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
If no screenshot tool is available, this skill will tell you what to install and exit.
- Distinctive: line 32
After component creation or replacement
- Distinctive: line 34
When Archon or Marshal delegate UI work
- Distinctive: line 42
Check which files were modified in the current session/phase
- Distinctive: line 48
If the project has a route manifest or sitemap, use it
- Distinctive: line 49
If the project has a dev server, identify which routes render the modified components
- Distinctive: line 50
If you can't determine the route, ask the user
- Distinctive: line 56
Ensure the dev server is running (start it if not)
- Distinctive: line 61
If Playwright isn't available, try:
- Distinctive: line 73
Read the screenshot (vision).
- Distinctive: line 106
Write a verification summary:
- Distinctive: line 119
When Archon delegates a build phase that modifies view files:
- Distinctive: line 121
After the sub-agent completes, Archon invokes /live-preview on the modified routes
- Distinctive: line 122
If any route is BLANK or FAIL, the phase is NOT marked complete
- Very specific: line 136
Port is not 3000: Check common alternatives (3001, 5173, 4173, 8080) before asking.
- Very specific: line 138
.planning/screenshots/does not exist: Create the directory before writing artifacts. - Distinctive: line 150
Every modified view file must have a corresponding screenshot
“Common” is measured: kept by at least 6 in 10 of the 4 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
/live-preview — Build-Verify-Fix Loop
Prerequisites
This skill requires a screenshot tool. Supported:
- Playwright (recommended):
npx playwright screenshot [url] [output.png] - Puppeteer: via a small script
- Any tool that takes a URL and produces a screenshot
If no screenshot tool is available, this skill will tell you what to install and exit.
When to Use
- Any time .tsx, .jsx, .vue, .svelte, or .html files are modified
- After component creation or replacement
- During visual redesign campaigns
- When Archon or Marshal delegate UI work
Protocol
Step 1: DETECT
Determine what needs visual verification:
- Check which files were modified in the current session/phase
- Filter to view-layer files (.tsx, .jsx, .vue, .svelte, .html, .css)
- If no view-layer files found: exit early with message "No view-layer files modified. Nothing to preview." Skip Steps 2-5. This is expected for non-UI repos (CLI tools, libraries, agent harnesses).
- Map each modified file to a route or URL where it renders:
- If the project has a route manifest or sitemap, use it
- If the project has a dev server, identify which routes render the modified components
- If you can't determine the route, ask the user
Step 2: CAPTURE
For each route/URL that needs verification:
- Ensure the dev server is running (start it if not)
- Take a screenshot:
npx playwright screenshot http://localhost:{port}/{route} .planning/screenshots/{route-slug}.png --full-page - If Playwright isn't available, try:
# Check for playwright npx playwright --version 2>/dev/null # If not found, inform the user: # "live-preview needs Playwright for screenshots. Install with: npm i -D playwright"
Step 3: VERIFY
For each screenshot:
- Read the screenshot (vision). Check:
- Does the component render? (not blank, not invisible)
- Does it show real data or placeholder/empty states?
- Are there obvious layout breaks (overlapping elements, overflow, missing sections)?
- Does it match the intended design direction?
- Record the result:
- PASS: renders correctly, matches expectations
- FAIL: describe what's wrong
- BLANK: nothing rendered (critical failure)
Step 4: FIX (if failures found)
For each FAIL or BLANK:
- Diagnose: is it a data issue, a rendering issue, or a missing import?
- Fix the root cause (not a band-aid)
- Re-capture and re-verify
- Maximum 2 fix attempts per component. If still failing, log it and move on.
Step 5: ARTIFACT
Save verification artifacts:
- Screenshots go to
.planning/screenshots/{campaign-slug}/(if in a campaign) or.planning/screenshots/(if standalone) - In Codex, also register screenshots for the app artifact/browser workflow:
node scripts/codex-app-artifacts.js record --workflow live-preview --kind screenshot --path ".planning/screenshots/{route-slug}.png" --status pass - Verify registered artifacts:
node scripts/codex-app-artifacts.js verify --require-artifacts - Write a verification summary:
## Visual Verification: {date} | Route | File Modified | Result | Notes | |-------|--------------|--------|-------| | /dashboard | Dashboard.tsx | PASS | Renders correctly | | /settings | SettingsPanel.tsx | FAIL → PASS | Fixed missing import, re-verified | | /profile | ProfileCard.tsx | BLANK → PASS | Component wasn't mounted, fixed export |
Integration with Archon
When Archon delegates a build phase that modifies view files:
- After the sub-agent completes, Archon invokes /live-preview on the modified routes
- If any route is BLANK or FAIL, the phase is NOT marked complete
- The fix cycle runs before proceeding to the next phase
- This is part of Archon's Step 4 (Self-Correction) quality spot-check
What This Prevents
- Invisible features (postmortem #17) — compiles but renders nothing
- Layout regressions — change in one component breaks another's layout
- Empty states shipped as features — data not connected, UI renders skeleton
- "Works on my machine" — screenshots are artifacts anyone can review
Fringe Cases
- Dev server is not running: Offer to start it. Output: "Dev server not detected on localhost:{port}. Start it with
npm run devor equivalent, then re-run /live-preview." Do not attempt screenshots against a dead server. - Port is not 3000: Check common alternatives (3001, 5173, 4173, 8080) before asking. Read
package.jsonscripts for a--portflag orPORTenv variable. - Screenshot tool unavailable (Playwright not installed): Output what to check manually — list the modified routes, describe what each should render, and suggest installing Playwright:
npm i -D playwright. Exit gracefully without crashing. .planning/screenshots/does not exist: Create the directory before writing artifacts. Never error on a missing output directory.- No view-layer files modified: Exit immediately with "No view-layer files modified. Nothing to preview." This is expected and correct for non-UI repos.
Contextual Gates
Disclosure: "Taking screenshots for visual verification. Images saved to .planning/screenshots/."
Reversibility: green — screenshots only; saves to .planning/screenshots/. No source files modified.
Trust gates:
- Any: full screenshot capture, verify, and fix workflow.
Quality Gates
- Every modified view file must have a corresponding screenshot
- BLANK results are critical failures (never acceptable)
- Screenshots must be saved as artifacts (not just checked and discarded)
- Fix attempts capped at 2 per component (prevent infinite loops)
Exit Protocol
---HANDOFF---
- Live Preview: {N} routes verified
- Results: {pass}/{total} passed
- Failures: {list of routes that failed and what was wrong}
- Screenshots: .planning/screenshots/{path}
- Reversibility: green — delete .planning/screenshots/ to remove artifacts; no source files modified
---Other versions5 projects use a version of this.
Word for word · 1
- mayankjain1815-commits/CITADEL★ 4100% same
Edited · 2
- SethGammon/Armory★ 1991% same
- allysgrandiose674/Armory★ 191% same
Wrote their own version · 2
- vicoa-ai/vicoa★ 523same name
- vicoa-ai/agent-skills★ 2same name
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.
Used alongsideProjects with it also use research-fleet.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
SethGammonSkillresearch-fleet
Parallel research using Fleet wave mechanics. Spawns multiple scout agents, each investigating a different angle of the same question. Findings are compressed between waves. Produces a unified research brief from multiple independent perspectives.
Also in 3 projects that use this
In this repository49 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- architectSkill
- archonSkill
- ascii-diagramSkill
- autopilotSkill
- costSkill
- create-appSkill
- create-skillSkill
- daemonSkill
- dashboardSkill
- decision-mapSkill
- deploy-stewardSkill
- designSkill
- doc-genSkill
- doSkill
- evolveSkill
- experimentSkill
- fleetSkill
- grillSkill
- housecleanSkill
- improveSkill
- infra-auditSkill
- learnSkill
- loopSkill
- mapSkill
- marshalSkill
- merge-reviewSkill
- organizeSkill
- postmortemSkill
- prdSkill
- pr-watchSkill
- qaSkill
- refactorSkill
- researchSkill
- reviewSkill
- scaffoldSkill
- scheduleSkill
- session-handoffSkill
- setupSkill
- systematic-debuggingSkill
- telemetrySkill
- test-genSkill
- triageSkill
- unharnessSkill
- verifySkill
- watchSkill
- wikiSkill
- workspaceSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

