sumo-qa-preparing-for-work

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.