agentleFS
Sign inStart free
frankxaifrankxai/starlight-agent-skills/skills/coding/starlight-qa/SKILL.md

starlight-qa

Skill1 starsChanged 4 months agoMITView on GitHub

Exercise a web experience or API through real user flows, semantic accessibility checks, responsive viewports, console/network inspection, and release-specific assertions. Use when a preview or deployed surface needs evidence-based QA; use the host-approved browser connector and avoid unauthorized external side effects.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    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
  1. Distinctive:

    Test accounts or fixtures explicitly approved for the run.

    line 23
  2. Distinctive:

    Test validation, loading, empty, error, success, refresh, and back-navigation states as relevant.

    line 31
  3. Distinctive:

    Verify keyboard access, focus, names, heading order, reduced motion, contrast, and image alternatives.

    line 32
  4. Distinctive:

    Check representative phone, tablet, and desktop viewports for overflow and occlusion.

    line 33
  5. Distinctive:

    Use the browser or computer-use capability approved by the active host.

    line 43

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Starlight QA

Purpose

Prove that the supported journey works on the candidate revision, not merely that a page renders.

When it fires

  • A web, mobile-web, API, installer, or marketplace flow is ready for verification.
  • Responsive, accessibility, network, or state regressions are possible.
  • A preview must be checked before merge or production.

Inputs

  • Exact candidate URL or revision and supported environments.
  • Critical journeys, expected outcomes, and side-effect boundaries.
  • Test accounts or fixtures explicitly approved for the run.
  • Accessibility, performance, and browser support requirements.

Workflow

  1. Confirm the candidate revision and environment.
  2. Load each critical route and inspect status, console, and failed requests.
  3. Exercise the journey with role/label-based interactions and observable assertions.
  4. Test validation, loading, empty, error, success, refresh, and back-navigation states as relevant.
  5. Verify keyboard access, focus, names, heading order, reduced motion, contrast, and image alternatives.
  6. Check representative phone, tablet, and desktop viewports for overflow and occlusion.
  7. Capture the smallest useful screenshot or payload receipt for each material finding.
  8. Re-run focused checks after fixes and report anything not tested.

Output contract

Return candidate revision/URL, environments, journeys, pass/fail assertions, console/network findings, accessibility findings, responsive findings, evidence references, defects with reproduction, and untested boundaries.

Tools & MCP

Use the browser or computer-use capability approved by the active host. Reuse existing sessions where policy requires it. Never hardcode a local CDP endpoint as a portable dependency. Do not submit real purchases, publish content, send messages, or alter production data without explicit authorization.

Quality bar

  • Assertions target user-observable outcomes.
  • Semantic checks complement visual screenshots.
  • The report distinguishes automated, manual, and inferred results.
  • No “fully tested” claim when environments or destructive paths were skipped.

Example

Input: “QA the Academy evidence export on the PR preview.”

Good output: fill the labeled fields, complete the evidence phases, prepare the JSON, validate its schema/counts/approval state, verify the download link, inspect mobile overflow and semantics, and name any browser-download limitation.

Built on SIP — Starlight Intelligence Protocol Vertical: starlight-agent-skills · portable capability layer

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free