/qa-init

Phase: Entry point
Command: /qa-init

The recommended entry point for every new project and every new QA cycle. /qa-init orchestrates the full STLC journey with enforced phase gates - you cannot advance to the next phase without explicit confirmation.

---

What it does

1. Checks prerequisites - verifies /qa-setup has been run and dq-qa.config.json exists. If either is missing, it triggers the relevant skill automatically.
2. Domain scope selection - asks which of the four domains (UI, API, Accessibility, Performance) are in scope for this cycle.
3. Sequences all phases - runs planning, design, execution, and closure in order, pausing at each gate for your confirmation.
4. Enforces feedback loops - if execution produces failures, routes to /qa-triage before allowing closure.

---

Phase gate rule

Never advance to the next phase without explicit user confirmation.

If you ask to skip a phase, /qa-init will:

1. State the risk of skipping
2. Document the skip in qa-plan.md
3. Require you to confirm explicitly before continuing

---

When to use vs. individual skills

Scenario	Use
New project, first QA cycle	/qa-init
Returning cycle on a configured project	/qa-init
Running a single domain only (expert use)	Individual skill directly
Debugging or re-running one step	Individual skill directly

---

Example session

> /qa-init

I'll guide you through the full QA lifecycle. Let me check your environment first.

✔ dq-qa.config.json found (project: my-app)
✔ democratize-quality MCP server: active
✔ a11y-cli: v2.1.0
✔ dq-nbomber: v3.0.1

Which domains should we include in this cycle?
[ ] UI (E2E + Visual)
[x] API
[ ] Accessibility
[ ] Performance

→ Scope: API only

Phase 2 - Planning
Running /qa-requirement...

---

Related skills

• /qa-setup - installs CLIs
• /qa-onboard - configures project
• /qa-plan - derives test strategy