sumo-qa-deciding-approach

Deciding the QA approach

This hop is silent. It is internal orchestration: no announcement, checklist, status, taxonomy label, or routing payload reaches the user. Routed: the next skill's answer is the first thing they read. STOP: a short plain-English answer (decision + evidence).

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

Work through these in order as private reasoning. Never render them in chat: no numbered tracker, no [DONE] statuses, no step narration. If the host has a task primitive, keep this hop off it; a visible router checklist is the leak this skill exists to prevent.

1. Read the user's intent verbatim and any supplied target paths.
2. Call sumo_qa_load_classifications() and sumo_qa_load_approaches(), this router's own loads (see Catalogue responsibilities).
3. Reason about classification: which single catalogue entry is the PRIMARY one? Decide it by the executable-behaviour rule, not path; cite the words 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.
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 (security testing: via its bundle); it produces what the user sees. On STOP, answer in plain English instead.