team-qa

Run a multi-phase QA pipeline on changed files after build.

1|Updated Mar 6, 2026
One-click install
npx skills add https://github.com/davekim917/bootstrap --skill team-qa-davekim917
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: team-qa
Source: https://github.com/davekim917/bootstrap/tree/main/plugins/workflow/skills/team-qa
Command: npx skills add https://github.com/davekim917/bootstrap --skill team-qa-davekim917

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

After a team build, QA often hinges on manual checks and scattered validation steps. This skill automates post-build quality validation by running a structured, multi-phase pipeline on changed files.

Core Features & Use Cases

  • Sequential denoise pass to prune noise and highlight actionable findings
  • Parallel validators for style, docs freshness, and domain-specific code review (swarm) plus Codex adversarial pass
  • Validator isolation with selective re-run to minimize blast radius and feedback cycles
  • Generates a consolidated QA report and enforces MUST-FIX gating before shipping
  • Supports dynamic reviewer scheduling and artifacts collection for audits

Quick Start

Trigger this skill after a successful /team-build to run the automated QA pipeline on the latest changes.

Frequently Asked Questions about team-qa

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

FAQPage Schema
How do I automate post-build code quality validation for changed files?

Automated post-build code quality validation runs a multi-phase QA pipeline on changed files, applying sequential denoise and parallel validators to generate a structured QA report. It enforces MUST-FIX gating before shipping to ensure codebase standards are met.

What is a Codex adversarial pass in code review?

A Codex adversarial pass is a parallel validation step within a QA pipeline that stress-tests changed files for edge cases and vulnerabilities. It runs alongside style, docs freshness, and domain-specific code review swarm validators to isolate and surface critical findings.

How do I run a parallel code review swarm and validators after a build?

Running a parallel code review swarm and validators requires triggering an automated post-build QA pipeline after a successful team-build completes. The pipeline orchestrates isolated validators for style, docs, and code review with selective re-run logic to minimize blast radius.

Do I need a completed build and CLAUDE.md conventions to run automated QA?

Yes, automated QA requires a completed build and CLAUDE.md conventions to execute the post-build validation pipeline properly. These prerequisites ensure the multi-phase validators have the necessary context and artifacts to enforce MUST-FIX gating before shipping.

What's the best way to gate shipping based on MUST-FIX findings from a QA pipeline?

Gating shipping based on MUST-FIX findings is handled natively by the automated QA pipeline, which consolidates validator outputs into a structured report. It enforces the gate automatically, preventing deployment until critical findings are resolved and selective re-runs pass.

Why does validator isolation matter in post-build QA pipelines?

Validator isolation in post-build QA pipelines minimizes blast radius and feedback cycles by containing failures to specific checks like style or docs freshness. This allows selective re-runs of failed validators without re-executing the entire multi-phase pipeline.