ui-qa
Skill19 starsChanged 37 days agoMITView on GitHub
Verify UI changes against spec acceptance criteria. Use when a task changes user-visible interface behavior, layout, or flows.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- NodeJSmith/hassettetheir own version, first seen Oct 8, 2026
- Mesteriis/Engineering-Bible-AItheir own version, first seen Jun 28, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- NodeJSmith/hassette★ 81same name
- Mesteriis/Engineering-Bible-AI★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- broSkill
- closingSkill
- context-auditSkill
- decision-logSkill
- dependency-freshnessSkill
- documentation-updateSkill
- failure-learningSkill
- git-disciplineSkill
- goblin-modeSkill
- project-mapSkill
- run-and-verifySkill
- spec-from-screenshotSkill
- sdd-updateSkill
- sdd-workflowSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 8 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Check that UI changes match their spec's acceptance criteria — routes, visual states, interaction flows, responsive behavior, and …
- Distinctive: line 33
When no UI can be run or observed in the environment — record that QA was not performed instead of claiming it was.
- Distinctive: line 46
Test account credentials names if auth is required — provided by the developer at run time, never stored.
- Very specific: line 51
If the project has the browser-tester agent installed (browser-tester in the harness's agents directory), invoke it with the spec's UI …
- Distinctive: line 56
Start the UI with the project's dev command (or use the running instance the developer points to).
- Distinctive: line 61
Check the spec's responsive and accessibility criteria where present.
- Distinctive: line 62
Run the project's existing UI test suite if one exists.
- Distinctive: line 75
Never store credentials in specs, skills, or evidence.
- Distinctive: line 78
No destructive actions against shared or production environments.
≈ “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
UI QA
Purpose
Check that UI changes match their spec's acceptance criteria — routes, visual states, interaction flows, responsive behavior, and accessibility — and record the evidence.
Two execution paths:
- Browser-tester agent (when installed —
questions.md§18 option 2): invoke thebrowser-testersubagent to walk the criteria in a real browser through its scoped Playwright MCP. Browser tools exist only inside that agent (seemcps/playwright-policy.mdin the kit). - Manual path (always available): use the verification means already in the project — dev server, manual steps, existing UI test commands, developer-provided screenshots.
When to use
- A task changes user-visible behavior, layout, styling, or flows.
- A spec contains visual or interaction acceptance criteria.
- A UI bug fix needs before/after confirmation.
When not to use
- Backend-only or non-visual changes.
- When no UI can be run or observed in the environment — record that QA was not performed instead of claiming it was.
Required inputs
- The spec's UI acceptance criteria: target route/component, expected visual state, interaction flow; screenshots or mockups if provided.
- The spec's
Visual evidencesection, when present (filled by thespec-from-screenshotskill if installed): image inventory with IDs, observed/expected behavior, affected routes. For bug fixes, compare the before screenshot with the implemented after state. - How to run the UI locally (dev server command from
AGENTS.md/ the project map). - Test account credentials names if auth is required — provided by the developer at run time, never stored.
Procedure
- If the project has the
browser-testeragent installed (browser-testerin the harness's agents directory), invoke it with the spec's UI acceptance criteria — it executes steps 1–3 in a real browser and returns the per-criterion checklist. Continue manually only for criteria it could not verify. - Start the UI with the project's dev command (or use the running instance the developer points to).
- Walk each acceptance criterion: navigate to the target route, perform the interaction, compare the observed state with the expected one (screenshots/mockups when provided).
- Check the spec's responsive and accessibility criteria where present.
- Run the project's existing UI test suite if one exists.
- Record per-criterion results: pass, fail (with what was observed), or not verifiable (with why).
Output artifact
A UI QA checklist in the task's review notes: criterion → result →
evidence (screenshot reference or description). When the spec has visual
evidence, record the comparisons in the Visual verification section of
review.md (criterion/image → evidence → result).
Safety constraints
- Never store credentials in specs, skills, or evidence; ask the developer to provide them at run time and prefer test accounts.
- Require explicit approval before using any credentials.
- No destructive actions against shared or production environments; verify against local/test instances.
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.