lp-interaction-qa
Skill0 starsChanged 4 months agoISCView on GitHub
Audit landing pages for functional production readiness after visual implementation. Use with mockup-to-code or any LP build when verifying links and CTAs, fragment navigation, forms, keyboard Tab/Enter behavior, visible focus, reduced-motion behavior, JavaScript-disabled access, and critical-content visibility; emit deterministic interaction-report/v1 evidence and a SHA-256 receipt. Do not use for pixel, box, spacing, or screenshot-fidelity QA.
In this repository11 other files it gives its agents.
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 3 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Treat interaction readiness as a separate gate from visual fidelity.
- Distinctive: line 12
Start the page on a stable local or preview URL.
- Very specific: line 26
When the pack was installed with a non-default --dest, set SKILL_ROOT to that destination before running the command.
- Very specific: line 29
Read interaction-report.json, then verify interaction-receipt.json before reporting readiness.
- Distinctive: line 40
Treat warnings, including feasible hover-affordance heuristics, as review items.
- Very specific: line 47
Use interaction-report.blocked.json only as a valid blocked starter, never as evidence from a run.
- Very specific: line 50
Use schemaVersion for manifest, report, and receipt contract identifiers.
- Very specific: line 51
Keep status, mode, findings, and blocked reasons factual.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
LP Interaction QA
Treat interaction readiness as a separate gate from visual fidelity. Never infer a pass from appearance.
Run the gate
- Start the page on a stable local or preview URL. Avoid production mutations.
- Mark indispensable content with
data-qa-critical; add stable selectors with repeated--critical-selectorflags when needed. - Run:
SKILL_ROOT="${SKILL_ROOT:-${CODEX_HOME:-$HOME/.codex}/skills}"
node "$SKILL_ROOT/lp-interaction-qa/scripts/check_lp_interactions.mjs" \
--url http://127.0.0.1:3000/ \
--out-dir artifacts/lp-interaction-qa \
--parent-root . \
--playwright-core "$SKILL_ROOT/mockup-to-code/node_modules/playwright-core" \
--critical-selector '[data-qa-critical]'When the pack was installed with a non-default --dest, set SKILL_ROOT to
that destination before running the command.
- Read
interaction-report.json, then verifyinteraction-receipt.jsonbefore reporting readiness. - Fix errors and rerun against the same URL. Preserve reports when the user needs before/after evidence.
The checker uses playwright-core resolved from the working project, an explicit --playwright-core path, or LP_INTERACTION_QA_PLAYWRIGHT_CORE. It tries an installed Chromium/Chrome executable. If no usable browser exists, it performs a conservative source audit, records mode: "degraded-static", and forces status: "blocked"; never promote that result to pass.
Interpret the result
pass: browser checks completed in normal, reduced-motion, and JavaScript-disabled states with no error findings.fail: browser checks completed and found production-blocking interaction defects.blocked: the required browser/state evidence could not be completed. Static findings remain actionable but incomplete.
Treat warnings, including feasible hover-affordance heuristics, as review items. Inspect false positives in context; do not weaken unrelated checks to silence them.
The checker covers invalid/placeholder links, missing fragments, suspicious hover affordances on noninteractive elements, form action/name/submit defects, Tab reachability, Enter activation, focus visibility, and critical visibility across states. It does not assess pixel matching, geometry, spacing, typography fidelity, animation polish, or general visual quality.
Contracts
- Validate reports against interaction-report-v1.schema.json.
- Use interaction-report.blocked.json only as a valid blocked starter, never as evidence from a run.
- Require the receipt's manifest and report hashes to match the emitted files. A changed manifest or report invalidates the receipt.
- Copy
interaction-receipt.json.specialistReporttospecialistReports.interaction; it is already rooted and hash-bound by--parent-root. - Use
schemaVersionfor manifest, report, and receipt contract identifiers; do not emit the legacyschemakey. - Keep
status,mode, findings, and blocked reasons factual. Do not self-approve incomplete browser coverage.
For checker options, run node scripts/check_lp_interactions.mjs --help. Run focused regression tests with node tests/run_fixture_tests.mjs after changing this skill.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

