preview-manual-test
SolidDiscover, wait for, sign in, create specific user data, and assert a PR preview deploy. Use on medium or high risk PRs, after pushing a ready-for-review PR, or when the user asks to test the preview URL.
Install
Quality Score: 83/100
Skill Content
Details
- Author
- modem-dev
- Repository
- modem-dev/ossrules
- Created
- 1 weeks ago
- Last Updated
- 5 days ago
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
preview
Stand up the project's live app and hand it to the user to try a change firsthand, then gate on their verdict before continuing. Use when the user asks to "preview the change", "let me try it", "spin up the app so I can test it", "set it up so I can poke at it", or before finalizing a UI/UX change that needs human eyes.
preview-spec
Makes 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".
preview-and-prove
Use when the user wants a real local or UI proof — launch local, relaunch, run local, "do not deploy / run local", QA via playwright, e2e in browser/app, tunnel for test mode, "did you verify/check it works" on a visible flow, preview, or responsive QA. Prefer this over deploy-and-prove when they say run local or do not deploy. Especially checkout, authentication, onboarding, forms, extensions, or responsive behavior.