Preparing for QA work

Output discipline (mandatory)

Inherits the global discipline from using-sumo-qa: output discipline (never surface internal taxonomy labels — say "behaviour change in pricing", not "Classification: business_logic_change"), output economy (spend output on findings not framing; no preamble or self-narration; one question per turn; no closing pleasantries), knowledge authority hierarchy, internal scaffolding stays internal, and specialty-tool fit.

The Iron Law

NO TEST IDEA WITHOUT A NAMED RISK. Every test you propose ties to a specific risk you identified.

When to Use

User intents that trigger this skill:

• "plan QA for this story"
• "I'm starting work on X — what should I test?"
• "what could break with this change?"
• "QA prep for ticket ABC-123"

Distinct from sumo-qa-creating-test-plan (formal entry/exit criteria, phases, deliverables) and from sumo-qa-deciding-approach (which only picks the approach). This skill produces a risk-shaped prep brief: named risks + smallest useful test set + named techniques + specialty fits if relevant.

Checklist

Track these as an ordered work list (use the host's task primitive if available, otherwise a numbered inline tracker) and complete in order:

1. Read the user's intent and target paths.
2. Call sumo_qa_load_standards(classification=...) and sumo_qa_load_rules(classification=...) using the classification the previous sumo-qa-deciding-approach step settled on.

3. Read the actual files in scope using the host's file tools. Do NOT ask the user for file content the host can read directly. When .sumo-qa/repo-map.json is present, sumo_qa_query_repo_map locates candidate tests and files for the area by path / tag / type (e.g. test_file) — a fast way to find what already exists, sharpening the named risks (step 4) and test set (step 7). Absent or stale → read the files directly; it's an accelerator, never a substitute for reading the code.

   Context bundle (optional input). If the host supplies a context bundle — a compact, host-neutral record of the issue/PR summary, changed files, any test/CI evidence (each with a source + freshness marker), and user constraints — PREFER it to seed scope and the user-constraint list: validate and read it via sumo_qa_format_context_bundle. When NO bundle is present, fall back to reading the files and the ticket directly — it is an accelerator, never a requirement, with no GitHub or network dependency. Treat any stale/unknown/absent test/CI fact in the bundle as stale: it informs which risks remain unproven, it never lets you claim a risk is already covered. The bundle sharpens the named risks (step 4); it does not replace reading the code.

4. Identify the 3-4 risks this change most plausibly breaks (never fewer than 3; a 5th only when the security-relevance pass below fires or the change spans several files and the 5th is a distinct failure the first four miss). Each extra risk dilutes the ones that matter. Cut rule (pinned): ask "does this change create or move this failure?" Cut what it doesn't (a field's rendering, label or layout when no new state, formatting or interaction sits behind them); where the classification's own risk column names a failure this change does create (a frontend_change's interaction or a11y regression), that is a risk, not padding. Where the change meets existing logic or state (a new amount against the tax base, a threshold, rounding, an empty-cart disabled state), that interaction IS a risk even if no rule for it is stated. On a change that looks too narrow for 3, the third risk comes from such an interaction, never from splitting one concern into valid/invalid halves or from padding. Each risk MUST be specific (not "input validation breaks" but "currency conversion at the GBP→USD boundary rounds incorrectly when the rate is supplied with >6 decimal places"). Anchor each in a file path or domain term from the user's words, and do not invent thresholds, rules, states, or edge cases that are not present in the supplied change or code. When the intent is refactor/move/extract without behaviour change, name preservation risks: rendered values, exact formatting, thresholds, rounding, disabled states, and public contract must remain unchanged. Do not merely restate the production formulae as generic calculation risks.

   Anchor-fit rule (pinned): the cited line must be semantically about the risk, not merely the nearest plausible-looking line. If the risk is about behaviour X and the cited code does Y, you have a stapled anchor — delete the risk. Before listing a risk, ask: "if I removed this line, would the risk still make sense?" If yes, the anchor is wrong.

   Stapled-anchor example (BAD): Risk: "discount must be correctly calculated when subtotal is at the tax threshold" citing const tax = subtotal * 0.0825. The cited line computes tax, not discount, and the sketch defines no tax threshold — this is a fabricated edge case wearing a real line number.

   Grounded example (GOOD): Risk: "valid promo code does not subtract from total" citing const total = subtotal + tax + shipping; — the cited line is the exact site where the discount must be applied.

   Security-relevance pass (grounded, pinned): run the internal security-relevance check from using-sumo-qa while naming risks. If the change creates a CONCRETE security failure mode — auth/authorisation, secrets, input sanitisation, rate limiting, audit logging, token lifecycle, or a security-relevant config/dependency movement — name it as ONE of the anchored risks (cite the file:line / behaviour, e.g. "old token still validates after refresh — no revoke-on-refresh"), give it a catalogue technique (step 5) and a concrete test (step 7), exactly like any other risk. Security CO-APPLIES, so step 2's single-classification load missed security_change's catalogue entries — when this pass fires, also load sumo_qa_load_standards(classification="security_change") and sumo_qa_load_rules(classification="security_change") before applying its must-consider probes. Deeper evidence → sumo-qa-security-testing. If the change has NO grounded security surface, OMIT security entirely — no generic "consider security" line. NEVER dump a vulnerability checklist (OWASP categories). For a security risk, the next action is a TEST/review/static/dynamic/config/dependency check phrased against the named risk — do NOT bolt on a scanner or vendor product name because the surface is security; a tool name is earned only via the discovery discipline (observed surface + the user's actual stack), exactly as for any other risk. An ungrounded scanner name on a security risk is the vendor/tool-name-dump anti-pattern.

   Surface-signal rule (pinned): when the change touches a recognisable surface — schema/model validation, request/response or IPC protocol, CI/config/deploy, async/retry/idempotency, auth/token — name the risk from the surface, not the library. Two changes on the same surface get the same probes (a removed field over any transport → "an existing consumer still referencing it keeps working or fails loudly, not silently"); the loaded rules (sumo_qa_load_rules) carry these per surface — apply them tech-agnostically, going library-specific only when the user or repo supplied the library. Cover the surface's distinct probes (don't restate one in three costumes), and make each test assert a concrete outcome — the input and what must hold — not that a consumer "accesses" a value (async retry → "a redelivered message double-charges unless an idempotency key makes the side effect run exactly once"; contract → "an old-shaped payload is still accepted or explicitly version-gated"). Review-feedback memory (advisory hints only). If the team saved recurring review lessons (sumo_qa_capture_review_feedback, #92 user-pack feedback/ subdir), use them only as HINTS that sharpen, never replace, the named risks: apply a lesson only on a trigger_signal match with THIS change, emit it as its OWN line right after the last numbered risk, before the tests, even when the requested format has no slot for it: "Advisory hint from saved review feedback: <recommended_probe> sharpens risk N (<source_note>)." Inside a risk, test, technique or risk title it is folded in, not separated. The risk it sharpens is an ordinary anchored risk (gets a technique in step 5). It NEVER overrides a canonical classification/change-rule (only a #92 pack does); absent/empty memory changes nothing. Do NOT auto-capture — saving is a separate, explicit, user-confirmed step storing only the user's own summary, never raw code/diff/secret/body.

5. Call sumo_qa_load_techniques(). Pick one technique per named risk. Use the catalogue's wording.
6. Recommend specialty tools (if any) by the discovery discipline from using-sumo-qa (observe the surface, web-search current options for the stack, cite; no tool catalogue; "I don't know" and an empty list are fine). Offer to install and scaffold the first tests against the named risks; confirm before installing dependencies.
7. Produce a smallest useful test set: one test per named risk, at most 5; put both sides of a boundary in one test idea. Oracle rule (pinned): work each expected value out through every line it passes (tax, threshold, rounding). If it hinges on a rule the change does not state (discount before or after tax), don't pick one or go vague: keep concrete inputs and an observable outcome; assert what holds under every candidate rule (discount applied exactly once, total never below zero) or each rule's expected value. List that rule under open assumptions. No generic "test happy path". Concreteness rule (pinned): if the change-shape supplies a numeric reproduction, a worked example, or specific inputs/outputs (e.g. "qty 2+3 currently shows 2, must show 5"), the corresponding test idea MUST reuse those exact numbers. Restating the risk in test-shape ("verify that the item count displays the correct total") is not a test idea — it's the risk again. A test idea names inputs and the observable outcome.

8. Output: conversational prose, sectioned (risks, then the advisory-hint line when saved feedback matched, tests, techniques, specialty tools, open assumptions). No JSON blob.

   Risk-to-test ledger appendix (optional, structured). The prose brief is the deliverable. When the user wants a paste-into-ticket artifact ("give me the ledger", "track these as a traceability table"), project the SAME named risks + proposed tests into the structured ledger via sumo_qa_format_risk_ledger and append it below the prose — never instead of it. A planning ledger needs NO code change and NO test run: every row is evidence_status: planned with test holding the proposed check (a planned: … phrase or a test path you'd write), source_anchor the risk's file/domain anchor, and residual: open. The tool only validates and formats — YOU name the risks (step 4). Skip it when the user just wants the prep brief.

Process Flow

See the Checklist above.

Red Flags

Examples

Good

User: "I'm adding a refund endpoint to the payments service. What should I test?"

• Risks: (1) refund amount exceeds original charge. (2) refund issued twice for the same charge (idempotency on charge_id). (3) partial refund recorded but downstream ledger update fails. (4) refund of an already-refunded charge isn't blocked.
• Techniques: boundary value analysis; state transition testing; decision table; state transition testing.
• Tools: Pact (consumer-driven contract test) + Hypothesis (property-based idempotency).

Good (refactor — "extract this without changing behaviour")

User: "I'm refactoring the cart totals into a useCartTotals helper without changing checkout behaviour."

• Risks: (1) subtotal.toFixed(2) rendering changes (e.g. 12.5 instead of 12.50) — visible at the data-testid="subtotal" node. (2) item-count text contents change after the move — visible at {cart.items.length} items. (3) $50 shipping threshold flips inclusive/exclusive after the extract — visible at subtotal >= 50 ? 0 : 6.99. (4) Checkout disabled state stops depending on cart.items.length === 0.
• Techniques: snapshot / golden output; DOM-render assertion; boundary value analysis; state transition testing.

Bad (refactor)

"Risks: subtotal calculation correct, tax calculation correct, shipping calculation correct." — These restate the production formulae, not the preservation contract. A refactor's risk is that the observable outputs drift; naming the formulae as risks tells you nothing about what to assert.

Bad

"Test that the endpoint returns 200 on success. Test that it handles invalid amounts. Test edge cases. Test the happy path." — No named risks, no anchors, no specific values.

Next skill in the chain

When the prep brief is signed off → sumo-qa-implementing-with-tdd to walk red → green for the agreed risks (the most common path).

When the work has 3+ independent tasks the user wants to dispatch across subagents → sumo-qa-planning-qa-rollout to turn the brief into a bite-sized, dispatchable plan first.