qa-workflow

name	qa-workflow
description	QA validation and fix loop workflow — validates implementation completeness then iterates fix cycles until all acceptance criteria pass and quality gates clear
version	1.1.0
model	sonnet
invoked_by	both
user_invocable	true
tools	["Read","Write","Edit","Bash","Glob","Grep"]
agents	["qa","developer","code-reviewer"]
category	Validation & Quality
tags	["qa","testing","validation","fix-loop","quality-assurance","sign-off"]
verified	true
lastVerifiedAt	"2026-02-22T00:00:00.000Z"
best_practices	["Be thorough - you are the last line of defense","Be specific with file paths and line numbers","Fix what QA found, don't add features"]
error_handling	graceful
streaming	supported
source	builtin
trust_score	100
provenance_sha	20cc308c655217c9

QA Workflow Skill

Overview

Comprehensive quality assurance workflow that validates implementation completeness and correctness, then iterates through fix cycles until approval. You are the last line of defense before shipping.

Core principle: You are the last line of defense. If you approve, the feature ships. Be thorough.

When to Use

Always:

• After implementation is marked complete
• Before merging or deploying changes
• When validating acceptance criteria

Exceptions:

• Documentation-only changes (may use minimal validation)
• Trivial fixes with skip_validation flag

Iron Laws

1. NEVER approve without verifying every acceptance criterion — you are the last line of defense; partial verification equals no verification.
2. ALWAYS document issues with exact file paths and line numbers — vague reports like "the tests fail" are unfixable and waste the fix loop cycle.
3. NEVER sign off on implementation with failing tests — all test categories (unit, integration, E2E) must pass before approval, no exceptions.
4. ALWAYS run the full test suite for regression check — a feature that breaks existing functionality is not production-ready regardless of new test results.
5. NEVER exceed 5 fix loop iterations without escalating to human review — repeated loops signal a root cause that automated fixes cannot resolve.

Anti-Patterns

Anti-Pattern	Why It Fails	Correct Approach
Approving before checking all acceptance criteria	Ships bugs disguised as features; breaks the quality contract	Verify every criterion in the spec before writing the verdict
Writing vague issue reports ("tests fail", "broken")	Developer cannot reproduce or fix what is not precisely described	Include file path, line number, exact error message, and reproduction steps
Signing off with known failing tests	Failing tests are documented bugs being shipped to production	All tests must pass; if tests are wrong, fix them first and document the change
Only running new tests, not the full regression suite	New code breaking old functionality is invisible without full suite	Always run full suite with ; regressions block approval