Full STLC Coverage
Five structured phases - Setup, Planning, Design, Execution, and Closure - with enforced phase gates so nothing gets skipped.
Guide your team through the full Software Testing Life Cycle - UI, API, Accessibility, and Performance - with the expertise of a Senior QA Expert, powered by major Coding Agents.

Most QA tooling gives you tools. dq-awesomeqa gives you a process. It is a coding-agent plugin that embeds the judgment of a senior QA engineer - asking the right questions, explaining trade-offs, and always closing with clear next steps.
Without dq-awesomeqa
With dq-awesomeqa
qa-plan.mdqa-summary.md dashboardThe biggest risk with AI-assisted testing is vibe coding - letting the model improvise tests without structure or accountability. dq-awesomeqa enforces a strict five-phase STLC (Setup, Planning, Design, Execution, Closure) with enforced phase gates so you cannot skip ahead. Every skill reads from dq-qa.config.json before acting, and missing config triggers /qa-onboard automatically. The plan gates execution - design skills and /qa-exec will not run a domain not listed in qa-plan.md. Your testing is structured, repeatable, and auditable - never improvised.
AI assists with planning, but execution is deterministic. /qa-exec delegates to purpose-built CLIs - the democratize-quality MCP server for API tests, accessibility-cli for UI and WCAG audits, and dq-nbomber for performance load tests. The execution order is fixed and intentional: API first (backend stability), then UI + Accessibility (browser tests), then Performance (load tests after functional tests pass). Skills orchestrate and interpret - they never generate or run tests from scratch. Domain scope is tracked in qa-plan.md, and execution respects those boundaries.
Three active hooks guard every session. A safety guard blocks all writes to application source code (.ts, .tsx, .js, .py, .go, .java, etc.) and only permits writes to QA artifacts like qa-reports/, qa-plan.md, and test configs. Prompt injection detection scans every input before the model sees it - hard blocks drop malicious messages entirely. An append-only audit log records every tool call, timestamp, and input to JSONL. Destructive operations like rm -rf, git reset --hard, and DROP TABLE are blocked. Package installs are blocked outside /qa-setup. Generated code only lands in qa-codegen/ - never in your application source tree.
Each of the 15 skills acts as a senior QA consultant for its domain. /qa-plan derives a structured test strategy with risk registers, domain scope, and test objectives from your requirements. /qa-triage applies a consistent P0-P3 severity model - P0 (data loss, security, WCAG critical) triggers a no-ship verdict; P2 (workaround exists) ships with a ticket. The plugin explains why it asks what it asks, interprets findings in professional QA language, and always closes with recommended next steps. You build domain knowledge as you go - or bring your own and let the plugin structure it.
AI helps you design tests - generating API test plans from your OpenAPI schema, building UI interaction YAML from live app exploration, creating WCAG audit configs, and producing NBomber load scenarios from your schema. But when it is time to run, execution is fully deterministic via CLI pipelines. /qa-codegen exports Playwright .spec.ts files and full C# .NET projects for CI integration. No AI in the loop at runtime - just your pipeline running exported, version-controlled test code.
| Domain | Design (AI-Assisted) | Execution (Deterministic) |
|---|---|---|
| API | Plan from OpenAPI/GraphQL schema | democratize-quality MCP server |
| UI | YAML from live app exploration | accessibility-cli (Playwright) |
| A11y | WCAG audit config per page | accessibility-cli (axe-core) |
| Performance | Scenario from schema | dq-nbomber CLI (NBomber) |
| CI Export | - | .spec.ts / C# .NET project |
Testing is never one-and-done. When requirements change mid-cycle, /qa-impact tracks the diff, updates affected domain requirement files, and flags only the domains that need re-run. Test failures flow into /qa-triage for severity classification and root-cause analysis, then back into re-execution. Each domain produces its native report, and /qa-report aggregates them all into a single qa-summary.md dashboard for stakeholders - one view across API, UI, accessibility, and performance results.