xiduzo/wtf/wtf-steer-qa

Steer QA

Generate or refine docs/steering/QA.md — the QA standards document. This document is the canonical reference for test strategy, coverage requirements, and test patterns. It also defines the definition of done that every implementer and QA engineer must follow.

The shared steering-doc flow (exists-check → research → interview → draft → review → write → wiki sync → continue) lives in ../references/steering-doc-process.md. Follow that process with the skill-specific inputs below.

• Doc path: docs/steering/QA.md
• Template: references/qa-template.md
• Display name / wiki page: WTF-QA.md
• Commit message: docs: add QA standards steering document

Step 2 — Research checklist

Use the Agent tool to extract QA facts. Do not ask the user for things you can read:

• Test framework: test runner config (vitest.config.ts, jest.config.js, pytest.ini, etc.)
• Test scripts: package.json scripts for test, test:watch, test:coverage
• Coverage config: coverage thresholds in test config files
• Test file conventions: where tests live, naming patterns (.test.ts, .spec.ts, _test.go, etc.)
• Existing test types: are there unit, integration, and e2e tests? What tools?
• CI config: .github/workflows/ — what test gates run on PRs?
• CLAUDE.md: extract any testing rules already defined there
• Known flaky areas: skip, xit, @pytest.mark.skip usage or TODO comments in tests

Also check docs/steering/TECH.md if it exists. Extract testing-related constraints already documented there.

Produce a concrete draft of Test Strategy, Test Patterns, and Commands from research alone.

Step 3 — Gap-topic list

Ask only about items research could not determine. For each unanswered item, call AskUserQuestion (per ../references/questioning-style.md):

1. Coverage thresholds — question: "What is the minimum acceptable test coverage?" / header: "Coverage thresholds" / options: pre-fill with thresholds found in test config or CLAUDE.md.
2. Definition of Done — question: "What must be true before any trace can be merged?" / header: "Definition of Done" / options: pre-fill with DoD items from CLAUDE.md or existing trace templates.
3. Test environments — question: "What environments are available for testing? (local, staging, CI)" / header: "Test environments" / options: pre-fill from CI config or README.
4. Known flaky areas — question: "Are there known areas that produce non-deterministic test failures?" / header: "Known flaky areas" / options: pre-fill with skipped tests or TODO comments found in step 2.
5. Mock strategy — question: "Are there project-specific exceptions to the 'only mock at boundaries' rule?" / header: "Mock strategy" / options: pre-fill with mock patterns found in existing tests.

Step 4 — Writing rules

• Apply strict STE per ../references/ste-writing.md before you write any durable body (shared process Step 4 also requires this).
• Coverage thresholds are stated as enforced minimums. They are not targets.
• Test commands must be exact and match what CI actually runs.
• If the project has a Gherkin runner (playwright-bdd, cucumber-js, behave, …), name it under Gherkin → Test Mapping. wtf.verify-trace reads that declaration.
• Definition of Done items are written as checkboxes — concrete and binary.
• Known Flaky Areas is honest. It is not aspirational. Flag real issues.

Step 8 — Continue options

• {label: "Create VISION.md", description: "Run wtf.steer-vision to document the product vision"}
• {label: "Create TECH.md", description: "Run wtf.steer-tech to document the technical guidelines"}
• {label: "Create DESIGN.md", description: "Run wtf.steer-design to document the design guidelines"}
• {label: "Stop here", description: "Exit — no further action"}