Qa start

<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.