design-verify

Design Verify

Verify what design-render produced before anyone relies on it. The renderer already refuses a page or deck that fails its own fidelity checks; this skill checks the delivered file again, independently, against the frozen inputs, and adds what a render-time check cannot hold: per-family content preservation, object-level editability, declared accessibility, the critical visual classes, a persisted visual review, and a repair loop with a finite budget. The scripts decide what can be decided deterministically. A model or a person judges the rest, and only through a review record that names what was checked.

Inputs

• The frozen inputs of the render: the normalized brief and the semantic composition it was rendered from, and the theme directory it was rendered with.
• The delivered artifact: index.html or deck.pptx; editability is inventoried from the deck package.
• Optionally: a visual review record, a design-render measurement report (browser-report.json), and for a proof its manifest and specimen index.

Workflow

1. Run verify on each delivered output. It directly extracts facts from index.html or deck.pptx using verification-owned readers and predicates, deriving expectations from the normalized brief, composition and pattern library; it grades preservation, editability (pptx), accessibility and geometry independently of renderer checks. Read data.findings; an empty list is the only passing state.
2. Capture every unit at full resolution for the review: a full-page capture of the page at 1280 CSS px cut on each unit's border rows (each unit section is drawn with a 1 px border, so find its top and bottom border rows in the capture and crop between them with a host image tool), and each slide of the deck at its 1280 × 720 px canvas. Record the capture tool, version, resolution and image digest with each entry. Capture with host tools, never a plugin script: a headless browser screenshot for a page and a LibreOffice PDF export rasterized per slide for a deck, with the commands in ${CLAUDE_PLUGIN_ROOT}/docs/design-verify-proof.md §Reproduce it.
3. Review each capture and the deck as a whole under the rules below, recording each observation as a finding with a criterion, a severity (critical, major, minor or note), a code and a description. A critical finding names one of the critical classes. The entry shape check-review and verify --review expect is in ${CLAUDE_PLUGIN_ROOT}/references/design-verify.md §Review record. The committed ${CLAUDE_PLUGIN_ROOT}/docs/design-verify-proof/codex-openai/boardroom/pptx/review-record.json is a worked record that passes check-review; copy its entry shape, and never add a bare verdict key such as overall, quality or score, which the check rejects at any depth.
4. Run verify --review <review-record.json> so the review's critical and major findings join the report. For a platform proof, run check-proof --manifest <proof-manifest.json>: it checks each artifact's review coverage and digests against its own frozen inputs.
5. When verification fails, run render-verified instead of hand-editing anything: it tries the other variants of the failing unit's pattern within the budget and returns either a passing render or a bounded failure with the repair history.
6. For a proof, run check-specimens and check-proof; check-proof recomputes every recorded hash and re-reads each report, the review and the specimen index.