sumo-qa-deciding-approach

Deciding the QA approach

Announce at start: "Picking the QA approach for this change."

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

SHAPE FIRST, then REACHABILITY. Decide single-change vs repo-wide vs no-tests-recommended before picking a per-change approach — wrong shape means wrong-shaped tests. When the shape is single-change, check reachability/load-bearing before picking a test-writing approach — orphan code routes to recommend-removal, not test scaffolding.

When to Use

using-sumo-qa routes here on every QA-shaped intent; this skill ALWAYS runs before any other QA skill. Even simple intents pass through — no-tests-recommended and verify-existing exist for cases that don't merit new tests.

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 verbatim and any supplied target paths.
2. Call sumo_qa_load_classifications() and sumo_qa_load_approaches() — the only catalogues this router loads (see Catalogue responsibilities).
3. Reason about classification: which single catalogue entry is the PRIMARY one? Cite the words / paths internally. Then run the grounded security-relevance pass (see using-sumo-qa) on ORDINARY work too, not only explicit security requests: if the change ALSO touches auth/authorisation, secrets, input sanitisation, rate limiting, audit logging, or a security-relevant config/dependency movement, note internally that security_change co-applies (it does NOT replace the primary classification) so the routed sub-skill carries that grounded gap forward — no parallel taxonomy; not grounded → don't add it. The routing payload still emits the single primary classification.
4. Reason about shape: single change vs repo-wide / strategy ask vs config tweak vs docs-only? Strategy-shaped asks ("audit", "strategy", "pyramid", "rollout") route to strategy-orchestration — do NOT force per-change output.
5. Run the removability gate BEFORE picking a test-writing approach. If the user named target paths and the code is orphaned — zero internal callers, zero CI/workflow refs, zero README/docs refs, no entry-point declaration (pyproject [project.scripts], package.json scripts, etc.) — set the approach to recommend-removal regardless of natural classification, and surface the reachability evidence in the rationale. If reachability is genuinely ambiguous (external cron, hand-invoked tooling, public CLI), ask ONE clarifying question. Do NOT collapse this into no-tests-recommended (that's for behaviour-less changes — docs, typos); recommend-removal is for dead production-shaped code that should be deleted.
6. Pick the approach. Security-test requests or material grounded security gaps needing deeper evidence route to security-focused-qa; simple gaps stay as test/review/static/dynamic/config/dependency actions. The catalogue is authoritative; use n/a only when no catalogue approach fits and capture the non-canonical surface in rationale.
7. If a real ambiguity remains (e.g. user said "test the thing" with no paths and no domain), ask ONE clarifying question. Otherwise, do not ask.
8. Return INTERNALLY using the Routing-payload shape below — routing data the next skill consumes, NOT user output. Route to the named sub-skill silently; it produces what the user sees.