qa

Verify changed applications at runtime against acceptance criteria and edge cases.

88|6|Updated Mar 25, 2026
One-click install
npx skills add https://github.com/heliohq/ship --skill qa-heliohq
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: qa
Source: https://github.com/heliohq/ship/tree/main/skills/qa
Command: npx skills add https://github.com/heliohq/ship --skill qa-heliohq

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you validate a change in a running application when automated checks are not enough, so you can catch real-user issues before shipping.

Core Features & Use Cases

  • Runtime verification: Start the app, exercise the changed paths, and confirm acceptance criteria against the live system.
  • Exploratory testing: Probe edge cases, UX rough edges, console errors, and unexpected interactions that codified tests may miss.
  • Evidence-driven reporting: Capture screenshots, command output, and per-reference reports so findings are reproducible and actionable.
  • Use case: A release candidate passes E2E, but you still want an independent QA sweep of the changed screen, API, or CLI before creating the PR.

Quick Start

Ask the AI to start the application, verify the spec against the live change, collect evidence, clean up services, and return a concise QA report.

Frequently Asked Questions about qa

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is independent runtime QA and when do I need it for my application?

Runtime QA verifies a changed application by independently exercising acceptance criteria and edge cases against a live system. You need it after automated tests pass to catch real-user issues in web apps, APIs, CLIs, or Electron apps before shipping.

How do I perform exploratory testing on a release candidate after E2E tests pass?

Exploratory testing probes edge cases, UX rough edges, console errors, and unexpected interactions that codified tests miss. Start the app fresh, interact with changed paths, capture evidence like screenshots, and clean up services to return pass, fail, or blocked verdicts.

Can I use runtime QA verification for both API endpoints and CLI applications?

Yes, runtime QA verification applies to web apps, APIs, CLIs, and Electron apps. It independently exercises acceptance criteria and edge cases against the live running system after review is clean and automated tests are green.

What is the best way to capture evidence during a manual QA sweep of changed application paths?

Evidence-driven reporting captures screenshots, command output, and per-reference reports during a QA sweep. This ensures findings are reproducible and actionable, producing clear pass, fail, or blocked verdicts for the changed application paths.

Does runtime QA require a fresh application startup for each verification session?

Yes, runtime QA requires fresh startup of the application. It independently exercises changed paths, probes edge cases, captures evidence, and mandates cleanup of services afterward to produce accurate pass, fail, or blocked verdicts.

Why should I run exploratory testing when my automated E2E checks are already green?

Automated checks often miss real-user issues like UX rough edges, console errors, and unexpected interactions. Exploratory testing independently probes these edge cases against the live system to catch problems before creating a PR.