preview-spec
SolidMakes a UI pull request autonomously verifiable. `author` generates a step-by-step UI verification spec for the PR's visual change and injects it into the PR description as a collapsed, machine-findable block (delegated to by `create-pr` on UI diffs; also runnable standalone). `run` extracts that block, resolves the PR's live preview deployment URL via the GitHub deployments API, and runs the spec against it with Playwright by dispatching the `aw-tester` agent, then reports a pass/fail verdict. A two-way LoreKit memory loop connects them: the runner records navigation quirks it hits, and the author reads those lessons so future specs start correct from the outset. Web only — the spec grammar and Playwright runner are `aw-tester`'s; this skill owns the PR-embedding, URL resolution, and the authoring loop. Triggers on "write a preview spec", "add a UI verification spec", "verify this PR's preview", "run the preview spec", "test the preview deployment", "/preview-spec".
Install
Quality Score: 86/100
Skill Content
Details
- Author
- mthines
- Repository
- mthines/agent-skills
- Created
- 4 months ago
- Last Updated
- yesterday
- Language
- JavaScript
- License
- MIT
Integrates with
Similar Skills
Semantically similar based on skill content — not just same category
compose-preview-review
Review pull requests that change Compose UI by rendering @Preview composables on base and head and diffing them. Use when reviewing a UI PR locally or from a CI agent session (@claude mention), authoring an agent-opened PR that touches UI, or triaging flaky or unstable previews (time/random/animation). Pairs with the compose-preview skill; for wiring the CI that posts those diffs, see the compose-preview-ci skill.
spec-review
Review a diff on the two axes a dev-flow project can check that a generic reviewer cannot: the **spec** it was built from (`.workflow/PRD.md` + `tasks.md`) and the **contract** it was built under (golden rules, `meta.json#stack`). Two parallel sub-agents, reported side by side and never merged, with a Fowler smell baseline as the floor. Use when the user says "review this branch", "spec review", "review since <ref>", "does this match the PRD?", "controlla il diff contro la spec", or dev-flow proposes it after a feature lands. Requires `.workflow/`; without one use the built-in `/code-review`. Records `meta.json#spec_review`; no phase bump. Not for: generic review with no spec (built-in `/code-review`), UI quality (`shadscan`), legal (`compliance-audit`), Vercel cost (`vercel-doctor`), or running tests (`write-tests`).
spec-workflow
Drive the spec-driven lifecycle for any non-trivial work item: SPIDR-split a new spec into vertical slices, transition state markers (DRAFT → READY_FOR_REVIEW → READY_FOR_IMPLEMENTATION → IN_PROGRESS → REVIEWED → RECONCILED → DONE; also DEFERRED for parked slices with a stated resolution trigger), enforce the reconciliation checklist before commit, and surface stale specs/ADRs whose `last_verified` date has aged past dependency changes. Use when starting non-trivial new work, creating a spec, transitioning a slice's state, parking a slice as DEFERRED, reconciling a reviewed slice, or auditing doc freshness. Do not use for quick one-off fixes that don't need a spec, or for bug-shaped work where `jig:bug-fix` is the better fit.