qa-start

---
name: qa-start
description: >-
license: MIT
---

<objective>
A sequenced launcher for bootstrapping QA where none exists. It contains no QA guidance itself — it chains three skills in the correct order so engineers don't jump to writing tests before deciding what to test or why. Run `qa-project-context` → `test-strategy` → `test-planning` and you end with a context file, a strategy document, and a first test plan: a complete QA foundation.
</objective>

## When to Use This

Reach for `qa-start` whenever the answer to "where do we start with QA?" is unclear and no QA foundation exists yet:

- A brand-new project with no test infrastructure.
- Joining an existing codebase that has **no QA setup at all** — old code, but quality work was never formalized. Still `qa-start`, not `qa-project-bootstrap` (that one is for joining a team that *already has tests*).
- Rebooting QA after neglect — tests deleted, coverage collapsed, no strategy. You are rebooting QA from the foundation up.

If the codebase already has a real test suite and you are a QA engineer ramping onto the team, use `qa-project-bootstrap` instead.

## Quick Route

Pick your entry point — skip any step whose artifact already exists.

| Situation | Start at |
|-----------|----------|
| No QA at all (no context file, no strategy, no plan) | Step 1 |
| `.agents/qa-project-context.md` already populated | Skip Step 1 — invoke `test-strategy` (Step 2) |
| Context file AND strategy document both exist | Skip Steps 1 and 2 — invoke `test-planning` (Step 3) |
| All three done — what next? | After Step 3 |
| A QA engineer ramping onto an existing team with existing tests | Not this skill — see `qa-project-bootstrap` |

## Step 1: Capture Project Context

**Skill:** `qa-project-context`

Creates `.agents/qa-project-context.md` in your project root. That file records your tech stack, test frameworks, CI/CD pipeline, environments, coverage goals, risk areas, and team structure. Every later skill reads it, so it never asks you the same questions twice.

**What to do:** Invoke `qa-project-context` and work through its discovery questions. The skill walks each section interactively, discovers what it can from the repo, and writes the file.

**Done when:** `.agents/qa-project-context.md` exists in your project root with all sections filled in. It is the source of truth for everything that follows.

## Step 2: Create the Test Strategy

**Skill:** `test-strategy`

Produces a strategy document defining how the project approaches quality: the test pyramid (what proportion of unit, integration, and E2E tests fits your product), entry and exit criteria, tool selection, environment coverage, and quality gates for CI and release.

**What to do:** Invoke `test-strategy` once Step 1 is complete. It reads the context file automatically and will not re-ask anything answered there.

**Done when:** You have a strategy document (e.g. `strategy.md`) covering test-pyramid rationale, tool choices with justification, quality gates for CI and release, and entry/exit criteria per test type. One page of clear decisions beats a sprawling template.

## Step 3: Build the First Test Plan

**Skill:** `test-planning`

Translates the strategy into an actionable plan for the first sprint or release. Maps features to test cases, assigns effort, and decides what gets covered first versus deferred.

**What to do:** Invoke `test-planning` after Step 2. It consumes the strategy from Step 2 and the context from Step 1. Provide the feature list or sprint scope when prompted.

**Done when:** You have a test plan (e.g. `plan.md`) with features mapped to test cases, coverage priorities set, effort estimated, and scope boundaries clear. This is the artifact your team executes against.

## After Step 3

You now hold the foundation: context, strategy, and a first plan. Next actions depend on your stack — this launcher is not the final step.

- **First automated tests:** Use `playwright-automation` or `cypress-automation` to write the first E2E tests against your highest-risk flows.
- **CI integration:** Use `ci-cd-integration` to get tests running on every pull request.
- **Tracking quality:** Use `qa-metrics` once the suite runs to define what health looks like and how to measure it over time.

## qa-start vs qa-project-bootstrap vs qa-do

The single most common routing confusion, answered in one place:

- **`qa-start`** — bootstrap QA where **none exists**. New project, or QA was deleted and you are rebooting it. Sequence: context → strategy → first plan. Output is the QA *foundation*.
- **`qa-project-bootstrap`** — a 30-day ramp for a QA engineer **joining an existing team** with existing tests. Covers team processes, onboarding timeline, and an audit of the test suite already in place. Use it *after* a foundation exists, not to create one.
- **`qa-do`** — last-resort router for "which skill do I use?" when nothing clearly matches. If you already know you have no QA, skip it and run `qa-start`.

A brand-new project with no QA — even on an old codebase — is always `qa-start`, never `qa-project-bootstrap`.

## Pin as a Manual Command

Re-run anytime from the Claude Code `/skills` menu.

To pin this skill as a manual-only command, add `disable-model-invocation: true` to the frontmatter, or set it via `skillOverrides` in `.claude/settings.local.json`.

> Caveat: in some Claude Code builds `disable-model-invocation: true` also suppresses the manual slash command (ref anthropics/claude-code#26251). If you still want to invoke `/qa-start` by hand, set the `skillOverrides` state to `user-invocable-only` instead.

## Related Skills

- **qa-project-context** — Step 1. Captures project setup, tech stack, and quality goals into `.agents/qa-project-context.md`.
- **test-strategy** — Step 2. Defines the testing approach, pyramid, tools, and quality gates.
- **test-planning** — Step 3. Builds the first test plan with features mapped to test cases.
- **qa-project-bootstrap** — go here instead when a QA engineer is ramping onto an existing team with existing tests; this skill creates the foundation, bootstrap onboards onto one.
- **qa-do** — last-resort router when no skill clearly matches; not needed if you already know there is no QA.
- **playwright-automation / cypress-automation** — after the plan, write the first E2E tests against your highest-risk flows.