ss-verify

The VISUAL gate — render a UI or visual artifact through its surface adapter, inspect the actual pixels, then fix and re-render until it passes the composed StyleSeed rule set.

By bitjaru · 663 installs

npx skills add bitjaru/styleseed --skill ss-verify

Source repository · Upstream listing

Verify (look at it, don't just read it) Registry first artifact boundary When .styleseed/project.json and .styleseed/artifacts/index.json exist, resolve the requested artifact ID first, then read only .styleseed/bundles/<artifact id .md and .styleseed/manifests/<artifact id .json . Never fall back to the global legacy bundle for a registry project. Legacy projects may use .styleseed/effective rules.md only when no registry exists. If either registry file exists, require a complete, valid registry. Read the selected artifact's bundle and manifest above and check with ss resolve artifact <artifact id check . An incomplete or invalid registry is an error, not permission to read a legacy bundle or restart setup. Verify each affected artifact against its own required renders and validation contract. Only projects without either registry file use .styleseed/effective rules.md and .styleseed/manifest.json , checked with ss resolve from lock STYLESEED.md check . Invoke /ss resolve or $ss resolve from the corresponding project owned configuration when that selected bundle is missing or stale. With no registry or lock, establish scope before a compliance claim. Judge pixels against that compiled method. A lock value cannot excuse a core failure, and a recipe/profile cannot replace the output grammar. /ss score reads the code and scores it. But some of the worst "AI made" tells never appear in source — they only exist in pixels : a hero that doesn't actually dominate, a lower third of dead whitespace, cramped cards, a web font that silently failed to load and fell back to Times, two colors that look like two accents once rendered, text that's unreadable on its real background. A human sees these in half a second; a code reading gate misses all of them. /ss verify closes that gap: it renders the UI, screenshots it, and you look at the image — then score the same StyleSeed gate against what you see, fix, and re render. This is the gate that most predicts whether a real user will say "this looks designed." Run it as the final gate after /ss score passes — code clean is necessary but not sufficient; pixel clean is the real bar. When NOT to use Nothing renderable yet (pure logic/config, or a component with no host page) → use /ss score . No way to render at all (no browser, no Playwright, headless blocked) → say so, fall back to /ss score , and tell the user the visual gate was skipped. Never claim you verified visually if you didn't actually see a screenshot. A quick pre commit pass → /ss lint . /ss verify is heavier (it boots a renderer). Step 1 — Render it through the active adapter For social carousel , slide deck , document report , or single frame , use the companion renderer and open every required exported frame/page at readable resolution. Verify dimensions, crop/safe zones, font availability, asset placement, and the export manifest. Do not force a browser workflow onto a PIL, slide, PDF, or image renderer. For product ui , get a real screenshot in priority order: A. Running project (Next / Vite / etc.) — the normal case. 1. Start the dev server in the background ( npm run dev / pnpm dev / framework command); wait for the ready line and capture the port. 2. Screenshot the route with headless Chromium via Playwright. If the project has playwright in node modules , use it; else use a globally cached Chromium. Minimal script: Surface viewports: mobile {width:390,height:844} · desktop {width:1440,height:900} . Pick from the lock's Surface , or surface . 3. If a browser MCP (claude in chrome) is available instead, navigate + screenshot with that. B. Static HTML file → open it directly with file://… and screenshot (same script). C. Isolated component (no host page) → render it into a minimal throwaway page that imports the component with realistic props, then screenshot that. Then actually READ the screenshot back (Read the PNG). You must see it. Shoot at deviceScaleFactor: 2 so text is crisp enough to judge. Step 2 — Score what you SEE (the visual gate) Look at the image and run the StyleSeed gate perceptually . These are the checks that need eyes, not source: Step 3 — Render states or sequence variants too The happy path screenshot hides the most common real world failure: no empty / loading / error state. Where the surface has a data view, render those variants (a query param, a mock, a forced prop, or temporarily emptying the data) and screenshot each. A blank white void for "no data" is a fail you can only catch by looking at the empty state. (Static marketing pages with no data surface → N/A, note it.) For sequential artifacts, inspect the cover/first frame, every content frame, and close/CTA as a set: continuity, progression, one message per frame, repeated template fatigue, source labels, folios, and safe zone survival. For documents/decks, inspect every page/slide plus a representative thumbnail or overview view. Step 4 — Fix, re render, repeat For each visual failure, fix the code, then re render and look again — don't assume the fix worked from the diff (the whole point is that code ≠ pixels). Loop up to ~3×. Present only when the screenshot passes, with the final image, the effective rule set, a one line "fixed: …", and the gate result. Rules You must actually see the rendered artifact. No render, no visual verdict — fall back to /ss score and say the visual gate was skipped. Never fabricate "looks good." Re render after every fix. The reason this skill exists is that source and pixels diverge; verifying a visual fix by reading the diff defeats it. Both gates, in order: /ss score (code) first to catch structural issues cheaply, then /ss verify (pixels) as the final bar. /ss build runs code gate in its loop; finish a renderable screen with /ss verify . Clean up: stop the dev server you started; delete any throwaway harness/mock files. Shoot at 2× and at the locked surface's viewport — judging a desktop app on a 390px shot (or vice versa) invalidates the type scale and balance checks.