flow-next-qa

Drives a running app against spec-derived scenarios and files evidence-backed P0/P1/P2 findings with a ship verdict.

692|55|Updated Dec 26, 2025
One-click install
npx skills add https://github.com/gmickel/gmickel-claude-marketplace --skill flow-next-qa
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: flow-next-qa
Source: https://github.com/gmickel/gmickel-claude-marketplace/tree/main/plugins/flow-next/codex/skills/flow-next-qa
Command: npx skills add https://github.com/gmickel/gmickel-claude-marketplace --skill flow-next-qa

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Static code review cannot catch bugs that only appear when a real user drives the running application. This Skill performs a live-app QA pass derived directly from the flow-next spec: it converts acceptance criteria into executable user scenarios, drives the deployed or local app, captures screenshots and console evidence, and ends with a YES/NO ship verdict recorded as a receipt.

Core Features & Use Cases

  • Spec-derived scenarios: Maps acceptance criteria to user scenarios, R-IDs to a coverage spine, boundaries to exclusions, and decision context to expected behavior, so testing intent comes from the spec rather than guesswork.
  • Evidence-gated verdicts: A SHIP verdict requires captured live-app evidence (screenshots, console dumps, observed state); PASS from source inspection is forbidden, and unreachable apps produce a BLOCKED outcome rather than a fabricated pass.
  • Structured bug filing: Files reproduce-twice-confirmed P0/P1/P2 findings with full repro steps and evidence into the bug memory track, with dedup via overlap scoring and promotion of findings to fix specs.
  • Autonomous pipeline integration: Runs interactively or as an optional pilot stage (pipeline.qa) in the autonomous build loop, suppressing prompts and emitting a qa_verdict receipt.
  • Use Case: After a spec's tasks are implemented, run a QA pass that drives the live app through each acceptance criterion at desktop and mobile viewports, files any failures with evidence, and emits a verdict the draft PR and reviewer can act on.

Quick Start

Ask the agent to run a live QA pass on the current spec, for example: "Run flow-next QA on spec fn-42 against the local dev server and give me the ship verdict."

Frequently Asked Questions about flow-next-qa

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

FAQPage Schema
How do I run a live-app QA pass against my spec?

Invoke the QA skill with a spec id, or let it resolve the spec from the current branch. It derives scenarios from the spec's acceptance criteria, drives the running app, captures evidence, and ends with a YES/NO ship verdict receipt.

How does spec-driven QA differ from static code review?

Static review inspects source and diffs, while this QA pass drives the actual running application like a real user. A SHIP verdict requires captured live evidence such as screenshots and console logs; passing from source inspection is explicitly forbidden.

Can this QA pass run autonomously in a CI-style build loop?

Yes. Enable the optional pipeline.qa stage so the pilot inserts a QA step before make-pr, or pass mode:autonomous. Autonomous runs suppress all prompts and emit a BLOCKED verdict instead of hanging when inputs are undocumented.

What happens when no live app or driver is reachable?

The outcome is BLOCKED, never a fabricated PASS. The skill records a blocked_reason in the qa_verdict receipt and exits cleanly, treating the missing live target as a surfaced limitation rather than a failure.

How are bugs filed and deduplicated during a QA pass?

Findings are filed into the bug memory track only after reproducing twice, with severity P0/P1/P2, full repro steps, and evidence paths. Overlap scoring stays on so duplicate findings fold into existing entries via --update instead of creating near-copies.

What are the limitations of the device matrix testing?

Version 1 covers viewport emulation only: one desktop (1280x800) and one mobile (375x812) viewport via the web driver ladder. It is not real-device or cross-device testing, and backend or CLI-only criteria are marked not live-QA-able.