Open source · MIT · Spec-driven QA

Agree on what to test before you run.

QASpec turns intent into structured QA artifacts — risk analysis, test cases, and optional publish to your test management system — versioned in the repo, not lost in chat.

Get started

~/checkout-service

$qaspec init

✓/qsx commands installed · Cursor, Claude Code, Codex…

>/qsx:analyze coupon-stacking-fix

✓analysis.md — 3 risks · 2 capabilities

>/qsx:cases

✓testcases.md — 12 cases · awaiting approval

>/qsx:publish

✓12 cases → Qase

01 — The pipeline

Four actions, not rigid phases.

Run what the moment calls for and revisit earlier steps freely. Halts exist where human judgment matters — cases approval, publish confirmation.

01 /qsx:analyze

Analyze

Risks, affected capabilities, and validated clarifications — the signed-off source of truth.

→ analysis.md

02 /qsx:cases

Matrix

Test cases with preconditions and steps, built from sources — plus delta specs for the change.

→ testcases.md

03 /qsx:publish

Publish

Approved cases upload to Qase via MCP — only after you review the in-chat summary and confirm.

→ publish-log.md

04 /qsx:archive

Persistent artifacts beat one-off chat output.

✓

Review intent, not just code

Each change produces structured QA artifacts — analysis, test cases, and spec deltas — so reviewers understand what will be tested before execution.

✓

Context that persists

Specs and test plans live in your repository alongside the code. Agents read them for context; new teammates browse the library instead of digging through old chats.

✓

Something to review in seconds

Describe what you want to test; QASpec generates the change folder, tasks, and artifacts. Refine the plan before any test run.

✓

Works with your agent

Install skills and slash commands for Cursor, Claude Code, Codex, Windsurf, and dozens more via qaspec init.

03 — Install

From zero to spec-driven QA in three steps.

STEP 01

Install the CLI

npm install -g @qaspec/cli

One global install. Node is the only prerequisite.

STEP 02

Initialize your project

qaspec init

Installs /qsx commands, schemas, and reference scaffolds for your agent. Works on existing codebases — no big-bang spec generation.

STEP 03

Run it in your agent

/qsx:analyze

Point it at a PR, a requirement doc, a user story, or plain-text intent. Analysis investigates scope before writing analysis.md.

04 — Supported tools

Works with your agent.

Cursor

Claude Code

Codex

GitHub Copilot

OpenCode

Windsurf

Gemini CLI

Cline

RooCode

Kilo Code

Amazon Q

Qoder

Auggie CLI

Qwen Code

CodeBuddy

CoStrict

Crush

Factory Droid

iFlow

Antigravity

Subset shown — full list in docs/supported-tools.md

05 — Open source

Built in the open.

QASpec is MIT-licensed. Use it, fork it, and help shape what spec-driven QA becomes.

LICENSE·MIT

✓ Report bugs, suggest workflows, or improve docs via GitHub Issues.

✓ Submit pull requests for CLI fixes, schemas, agent skills, and the landing site.

✓ Share feedback on TCMS connectors and real-world QA workflows — contributions and design input are welcome.

06 — FAQ

Questions, answered.

How is QASpec different from ad-hoc agent planning?

Plans live in the repo across sessions and teammates. You align on what to test and why before running tests, with human approval gates on cases and publish.

Do I need a test management system?

No. Artifacts stay in git. Today /qsx:publish supports Qase via MCP; more TCMS connectors are in progress.

Can I use QASpec on an existing codebase?

Yes. Run qaspec init in your project. Specs and changes accumulate as you work — no big-bang upfront spec generation required.

How does this relate to spec-driven dev planning?

QASpec is inspired by OpenSpec on the development side and applies the same spec-driven idea to QA.