Verify implemented work meets acceptance criteria — run tests, check PHPCS, validate Blade output, lando phpunit, lando phpcs, lando yarn test, Playwright tests, accessibility check, post-implementation verification, done criteria validation, checklist review, verification phase
Scanned 9/11/2026
Install to Claude Code
npx -y skills add hekivo/superpowers-sage --skill verifying --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Verifying?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/hekivo-verifying)More formats (shields.io, HTML) on the badges page.
---
name: superpowers-sage:verifying
description: >
Verify implemented work meets acceptance criteria — run tests, check PHPCS,
validate Blade output, lando phpunit, lando phpcs, lando yarn test,
Playwright tests, accessibility check, post-implementation verification,
done criteria validation, checklist review, verification phase
user-invocable: true
argument-hint: "[section name or plan path]"
---
# Verifying — Visual Comparison with Design Reference
Compare implemented sections against design reference using visual analysis.
## Inputs
$ARGUMENTS
## Procedure
### 0) Playwright gate
Before any verification work, ToolSearch for `mcp__plugin_playwright_playwright__browser_take_screenshot`.
If NOT found:
```
⛔ Cannot verify without Playwright MCP.
Install: claude mcp add playwright -- npx -y @anthropic/playwright-mcp
Restart session after installing. Stop.
```
Do NOT proceed to reference source detection.
### 1) Determine reference source
Priority order:
0. **Live design MCP (Priority 0 — preferred when MCP is configured):**
- Figma: `get_design_context` + `get_metadata`
- Paper: `get_computed_styles` + `get_node_info`
- Pencil: `batch_get(resolveVariables: true)` + `batch_get(readDepth: 4)`
- Stitch: `get_screen`
Use when the design MCP is active in the session — live reference is always more accurate than cached assets.
1. **Spec file**: `docs/plans/<active-plan>/assets/section-*-spec.md` — read “Verification Inputs” block to get url, selector, and ref path
2. **Plan assets**: `docs/plans/<active-plan>/assets/section-*.png` — reference image for comparison
3. **Last resort**: ask user to provide screenshot or describe expected appearance
### 1b) Node geometry (multi-column / offset components)
When the reference source is a design MCP **and** the component contains a grid with 2+ columns, offset positioning, or nested containers, fetch node geometry before capturing the implementation screenshot:
- **Figma**: call `get_metadata` — returns `x`, `y`, `width`, `height` for each direct child
- **Paper**: call `get_node_info` — returns width + computed sizes for selected node
- **Pencil**: call `batch_get(readDepth: 4)` — returns layout children with dimensions
- **Stitch**: column count and widths visible in the `get_screen` response
Use these values to confirm column widths (e.g., a 60/40 split) before comparing screenshots. Skipping this step on multi-column layouts is a common source of false MATCH verdicts.
### 2) Capture implementation
1. Read `Verification Inputs` block from the spec file — extract `url`, `selector`, `ref`
2. Read canonical viewport width from `plan.md` frontmatter (`viewport-width` field, default `1440` if absent)
3. Set viewport: `mcp__plugin_playwright_playwright__browser_resize` to `{viewport-width} x 900` before navigating
4. Navigate Playwright to `url`: `mcp__plugin_playwright_playwright__browser_navigate`
5. Take screenshot scoped to `selector`:
`mcp__plugin_playwright_playwright__browser_take_screenshot`
6. If `selector` fails (element not found), take full-page screenshot and note the difference
### 3) Compare visually
Read both reference and implementation images. Compare on these axes:
| Axis | Check |
|---|---|
| **Layout** | Grid structure, column count, alignment, flex direction |
| **Content** | Headlines match? Body text match? All items present? |
| **Colors** | Background, text, accent colors match? |
| **Typography** | Font size, weight, family approximately correct? |
| **Spacing** | Padding, margins, gaps reasonable? |
| **Icons** | Correct icon set? Right icon names? |
| **Images** | Placeholder or actual? Right aspect ratio? |
| **Responsive** | Does the layout adapt appropriately? |
### 3b) Style spot-check (paper sources only)
This step is **additive** — it runs only when `assets/section-{name}.styles.json` exists (i.e., the source was paper). For all other sources, skip silently and proceed to step 4.
1. Read `docs/plans/<active-plan>/assets/section-{name}.styles.json`
2. For each key property (typography, colors, spacing, border-radius), find the implemented value:
- **Tailwind class** (`p-6`, `text-lg`, `bg-slate-900`) — resolve to its real value via the project's Tailwind config (`tailwind.config.js` or `@theme` block in `resources/css/app.css`). For example, `p-6` → `padding: 1.5rem` → `24px`.
- **Arbitrary value** (`p-[23px]`) — capture the literal between brackets.
3. Compare design value vs implemented value. Produce a per-section report block:
```
### Style Spot-Check
✓ padding: design=24px, impl=p-6 (24px)
✗ font-size: design=18px, impl=text-base (16px) — DRIFT
✓ color: design=#0F172A, impl=bg-slate-900 (#0F172A)
⚠ gap: design=32px, impl=gap-[31px] — arbitrary value, near-match
```
4. **Non-fatal**: drift here does NOT block verification. The drift items are surfaced as warnings inside the final report (step 4) under a `### Style Drift` subsection. The user decides whether to adjust.
### 4) Report findings
Output a structured report:
```markdown
## Verification: {Section Name}
**Status:** MATCH | DRIFT | MISSING
### Comparison
| Axis | Status | Notes |
|---|---|---|
| Layout | {pass/drift} | {details} |
| Content | {pass/drift} | {details} |
| Colors | {pass/drift} | {details} |
| Typography | {pass/drift} | {details} |
| Spacing | {pass/drift} | {details} |
### Issues Found
- {specific issue with fix suggestion}
### Style Drift
{omit this section if source was not paper, or no drift found.
Otherwise list the ✗ and ⚠ lines from the spot-check.}
### Recommendation
{proceed / fix before continuing}
```
### 5) Act on findings
- **MATCH**: Mark component as verified, proceed
- **DRIFT**: List specific fixes needed, implement if in `/building` flow
- **MISSING**: Elements from design not implemented — flag for implementation
## Key Principles
- **Read images from disk** — always use Read tool for plan assets
- **Be specific** — "the grid should be 3 columns, got 2" not "layout is wrong"
- **Compare content verbatim** — headlines and body text must match exactly
- **Use base skill**: `verification-before-completion` for completion gate
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!