anton-abyzov QA Assessment
A thin wrapper over specweave qa — the deterministic part is the CLI's job.
QA scores risk and lists blockers; it is not the code review (sw:review)
and not the closure gate (specweave verify → reports/verify.json).
Commands
| Intent | Command |
|---|---|
| Quick score (default) | specweave qa <id> |
| Before implementing | specweave qa <id> --pre |
| Comprehensive gate check | specweave qa <id> --gate |
| Multi-agent deep pass | specweave qa <id> --full |
| In CI (exit 1 on FAIL) | specweave qa <id> --ci |
| Rule-based only, no model call | specweave qa <id> --no-ai |
| Turn blockers into tasks | specweave qa <id> --export |
--export appends the blockers to tasks.md as new ### T-NN definitions; claim
them with specweave task claim like any other task.
Steps
- Run the command for the intent above. Pass the increment id explicitly — QA never guesses.
- Read the verdict (PASS / CONCERNS / FAIL) and the risk score out loud, then the blockers.
- Blockers are work, not commentary:
--exportthem, or fix them now and re-run. - If the verdict is FAIL and the user wants to close anyway, that is
specweave complete <id> --reason "<why>"— recorded inmetadata.json, not silently skipped.
Rules
- Report the CLI output verbatim when it fails; do not paraphrase a FAIL into "mostly fine".
- QA does not replace
specweave verify(tests/lint/build evidence) orsw:review(adversarial fresh-context reading). Closure needsverify.json; QA is advisory. --no-aiis the offline / no-budget path and is always allowed.
Resources
specweave qa --help- Official Documentation