ai-sdlc-claude

QA / test engineer

Read time: 8 minutes. You know how your product is tested today. Claude Code access helps; not required.

What this is

Stage-gate QA at the end of a phase cannot keep up with agents writing most of the code. In this loop, quality moves into the work: acceptance criteria are written into the spec before code, Claude runs the tests after every step and cannot report done without them, a fresh-context verifier re-checks, the AI review checks the diff against the spec, and evals regression-test Claude’s own configuration. Your expertise moves from executing test cycles to defining what “acceptable” means and making sure the checks stay sharp.

Where you plug in

| Stage | Your contribution | How | |—|—|—| | 2 Design | Acceptance criteria that are observable and testable | Review Spec: PRs; comment on ## Acceptance criteria. Each AC becomes a test in the plan’s “Proof”. | | 3 Build | The proof section names the tests that demonstrate each AC | Review plan.md “Proof” in the PR; ask for missing negative and boundary cases. | | 4 Test | The one-command check Claude runs (commands.test) is complete and exits non-zero on failure | Own the test targets with the platform engineer; list them in sdlc.config.json and CLAUDE.md. | | 4 Test | Bug reports become failing tests first | Report bugs with a reproduction; the engineer runs /sdlc:verify --fix, which commits the failing test before any fix. | | 4 Test | Evals: real tasks with deterministic checks that guard the agent configuration | /sdlc:eval-add <PR or incident>; review evals/cases/*.json; keep 20–50 live cases. | | 5 Deploy | The review policy’s Compliance pass checks spec coverage | Suggest changes to REVIEW.md when review misses what you would have caught. | | 6 Maintain | Every production incident becomes an eval | /sdlc:eval-add <incident id> after the fix ships. |

Your commands

/sdlc:status                      what is in flight and where
/sdlc:verify                      run the configured checks and paste the proof
/sdlc:verify --ui <mock>          screenshot loop against the approved design
/sdlc:eval-add <PR | incident>    turn a case into a permanent eval
/sdlc:review <PR>                 run the REVIEW.md passes locally (findings only)

Writing acceptance criteria Claude can prove

Good: “For each of the four claim states, the panel renders the matching pill and next-step text.” Good: “A customer requesting another customer’s claim status receives 403.” Weak: “Status is shown correctly.” (not observable, no boundary)

What an eval looks like

{ "name": "status-endpoint-403-for-other-customer",
  "prompt": "Add GET /claims/{id}/status behind existing auth per sdlc/changes/<id>/spec.md.",
  "allowed_tools": "Read,Edit,Write,Grep,Glob,Bash(make test)",
  "checks": [ { "type": "command", "run": "make test", "expect_exit": 0 },
              { "type": "file_contains", "path": "claims-api/routes/status.py", "pattern": "require_auth" },
              { "type": "no_changes", "globs": ["tests/**"] } ] }

The suite runs nightly and on any change to CLAUDE.md, .claude/**, REVIEW.md or sdlc.config.json; a drop below the threshold blocks that change. As models improve, retire cases that stop discriminating ("retired": true) and add new ones from real work.

What only you can do

Decide what acceptable means, in observable terms. Judge whether a test proves the criterion or merely passes.

What you never have to do

Run manual regression cycles at phase boundaries, or re-test what the toolchain already proved: the PR carries the literal test output, the verifier’s report, and the screenshot.

How you know it is working

/sdlc:metrics is run by your platform engineer or leadership; ask them for: first-pass CI success for agent changes rising; review time per PR falling; regressions caught in CI outnumbering those found in production; incident → eval time shrinking.

This site is open source. Improve this page.