qa-start

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.

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. Start discovery with the repo and existing task, then write the file. Record unknown decisions explicitly. Ask only for a missing answer that changes the next action; continue useful checks when optional context is absent.

Done when: .agents/qa-project-context.md records observed setup, usable commands, current scope, and unresolved decisions. Do not invent team structure, targets, or credentials.

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.

Run the First Checks

Inspect the repository before producing planning documents. Use available context to make routine choices and keep the initial strategy and plan proportional to the project. A missing optional context file does not block an authorized local test run.

When the full QA Skills checkout is available, run:

node <qa-skills>/scripts/qa.mjs init --project <project> --wire-agent
node <qa-skills>/scripts/qa.mjs run --project <project> --goal "Check the critical user flow"

init creates a project config without overwriting an existing one. Use --wire-agent when the user wants QA integrated into future coding tasks; it adds a bounded workflow to the project's AGENTS.md, preserving existing instructions. Skip init for a configured project. The host agent must load that project instruction for automatic selection.

Read the selected domain skill and execute its workflow. If there are no tests, author and run the first test for an observed critical behavior; do not present setup as a pass. Retain a real report.html and result.json, including blocked dependencies and unrun flows. A successful smoke check establishes only the behavior that was exercised. See the repository's docs/QA-RUNNER.md for the runner contract.

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.