interface-qa
Skill1 starsChanged 2 months agoApache-2.0View on GitHub
Validates changed interfaces and user-facing flows across web, mobile, desktop, CLI, or APIs. Use after interface changes to check expected states, interaction behavior, errors, accessibility or usability concerns, and relevant client-side evidence.
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Test the primary successful flow plus relevant loading, empty, invalid-input, error, permission, authentication, unavailable, interrupted, …
- Distinctive: line 16
Verify inputs, outputs, state transitions, persistence, navigation, cancellation, recovery, and error feedback that are observable through …
- Distinctive: line 20
Mobile or desktop UI: check lifecycle transitions, permissions, supported window or viewport changes, interrupted flows, platform …
- Distinctive: line 21
CLI: check exit status, standard output and error output, help text, invalid arguments, non-interactive behavior, piping or scripting …
- Distinctive: line 22
API: check request and response contracts, status or error semantics, authentication and authorization behavior, validation, idempotency …
- Distinctive: line 24
Check accessibility and usability properties that apply to the interface rather than assuming every surface has the same interaction model.
- Distinctive: line 28
After a fix, re-run the affected flow and nearby behavior with meaningful regression risk.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
Interface QA
- Identify the affected interface, acceptance criteria, supported clients or platforms, relevant versions, and expected user or consumer behavior from project evidence.
- Establish the exact build, commit, version, environment, local state, or endpoint being tested when that distinction matters. Do not infer it from stale context.
- Test the primary successful flow plus relevant loading, empty, invalid-input, error, permission, authentication, unavailable, interrupted, retry, and boundary states.
- Verify inputs, outputs, state transitions, persistence, navigation, cancellation, recovery, and error feedback that are observable through the interface.
- Apply interface-specific checks where relevant:
- Browser: inspect responsive layouts, keyboard and focus behavior, semantic labels, browser console errors, failed network requests, navigation, refresh, and back/forward behavior.
- Mobile or desktop UI: check lifecycle transitions, permissions, supported window or viewport changes, interrupted flows, platform interaction conventions, and relevant application logs.
- CLI: check exit status, standard output and error output, help text, invalid arguments, non-interactive behavior, piping or scripting behavior, and interruption handling.
- API: check request and response contracts, status or error semantics, authentication and authorization behavior, validation, idempotency where relevant, and documented compatibility expectations.
- Check accessibility and usability properties that apply to the interface rather than assuming every surface has the same interaction model.
- Record defects with the smallest reliable reproduction steps and enough evidence to identify the tested state.
- After a fix, re-run the affected flow and nearby behavior with meaningful regression risk.
This skill validates each interface against its own expected behavior. Use a cross-surface consistency review separately when equivalent capabilities must remain aligned across multiple interfaces.
Report what was tested, the exact test context when relevant, evidence collected, failures found, and anything intentionally not tested.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- automation-cost-controlSkill
- backup-and-recovery-reviewSkill
- calculation-model-validationSkill
- change-reviewSkill
- compatibility-and-rolloutSkill
- continuous-improvementSkill
- cross-surface-consistencySkill
- delegation-strategySkill
- dependency-changeSkill
- documentation-syncSkill
- environment-release-safetySkill
- high-risk-change-reviewSkill
- root-cause-debugSkill
- secret-exposure-responseSkill
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.