quality-strategy-skills

Audit a quality strategy document. Applies seven indicators of a good strategy plus mechanical oracle checks, and asks "where is this strong, where is this weak?". Use after /quality-strategy completes, or to audit an existing quality/strategy.md cold.

Produce or revise a quality strategy for a project — a business-level document defining who matters, what they value, where the gaps are, and what to do about it. Use when starting a project, planning a major release, or when "quality" is being talked about vaguely.

Turn a complete-but-dense quality or test strategy into something operational — a 6–10 line TL;DR plus a one-page triage rubric (and an optional operator cheat sheet) placed at the top of the doc, so a returning reader re-orients in seconds instead of skimming hundreds of lines. Use from /quality-strategy at the end of the plan of work, or standalone to distill any existing strategy.

Produce the strategy for the second quality question — "how do we know if what we have is good?" Gathers every place the strategy lanes could NOT answer that (risk-map Unknowns nothing can judge yet; build items agreed in /evaluation-strategy; /test-strategy moves blocked on instruments or oracles) and turns them into a prioritised oracle/instrument build plan at quality/tooling-strategy.md. Use after /evaluation-strategy (ideally also /test-strategy), when Unknowns are piling up in the risk map, or when deciding what measurement or test infrastructure to build next.

A deliberately light follow-up to /quality-strategy for the testing lane — ingest the release's quality strategy, filter for the ilities testing can make a dent on (where you don't know where you stand and investigating would tell you), then per ility discuss what testing you have, what could be improved, and what could be added. High-level ideas and questions, not step-by-step hand-holding. Produces quality/test-strategy.md. Use after /quality-strategy completes for a release.

Derive audience-facing variants from a finished quality strategy — a distributable one-pager for the people the strategy names, and a client-safe ("polite") version that drops frank internal candor without lying. Use after /quality-strategy has produced and reviewed quality/strategy.md, when you need something to hand to engineers, a PM, contributors, or a named external audience — a client, or for a project with no client, its end users, funders, or a due-diligence reader — rather than the full internal artifact. Gates mechanically on strategy completeness before producing anything.

Detect cross-Part contradictions in a quality or test strategy document — places where one part of the doc asserts something another part denies or undercuts. The mechanical doc-internal-consistency check that the user-facing substantive checkpoint misses, because "this feels wrong" and "Part 3 contradicts Part 4" are different failure modes. Use from /quality-strategy at step boundaries, or standalone to audit any strategy doc for internal contradictions.

A deliberately light follow-up to /quality-strategy for the evaluation lane — ingest the release's quality strategy, filter for the ilities where better judging or better indication can make a dent (Unknowns nothing can judge yet, claims resting on signals that couldn't support them, "we wouldn't notice if it broke"), then per ility discuss what quality instruments — oracles and proxies — you have, what could be improved, and what could be added. High-level ideas and questions, not step-by-step hand-holding. Produces quality/evaluation-strategy.md. Use after /quality-strategy completes for a release. (Formerly /oracle-strategy.)

Audit whether a quality strategy's actual-state assessment can be trusted — for each dimension, is there an adequate oracle to judge what level the project is actually at, and an adequate instrument to observe it? The explicit "how do we know?" (Q2) check that agents skip by deferring to whatever measurement exists and by treating hard-to-judge dimensions as permanently Unknown. Use from /evaluation-strategy when the have/improve/add discussion contests whether an existing oracle can be trusted, or standalone to audit the oracles behind an existing strategy's actuals.

A deliberately light follow-up to /quality-strategy for the rules-and-processes lane — ingest the release's quality strategy, filter for the ilities that rules, invariants, standards, or repeatable processes can make a dent on, then per ility discuss what you have, what could be improved, and what could be added. High-level ideas and questions, not step-by-step hand-holding. Produces quality/process-strategy.md. Use after /quality-strategy completes for a release.

Audit a test strategy document. Asks "will carrying out these agreed moves move the quality strategy in the right direction with the right priority?" by forward-walking the moves as the primary lens, with mechanical checks as backstop. Use after /test-strategy completes, or to audit an existing quality/test-strategy.md cold.

Audit whether a test strategy's learning needs can actually be answered — both the instrument to exercise and observe the system, and the oracle to judge whether the result is correct (including cheap simulated/reference oracles agents now make possible). The explicit "how do we know?" (Q2) check that agents skip by deferring to existing tooling and by assuming hard-to-judge things are untestable. Use from /test-strategy when whether the existing means can answer a question at all is the live issue, or standalone to audit a codebase's test tooling and oracles.

Turn a finished quality strategy into a shareable, glanceable visual artefact — a bespoke self-contained SVG or HTML file designed for a stated audience and purpose. Describe the view you want ("a tweetable summary of where quality stands", "a story of our quality year, told frame by frame", "a dashboard of just the payment risks for my standup") and it designs and builds that view from quality/strategy.md, poster-first, then scores itself against seven principles before presenting. Presets — social card, risk heatmap, multi-frame story, interactive dashboard, quality radar — are worked examples, not a menu. Use after /quality-strategy has produced and reviewed quality/strategy.md, when you need the strategy in a form someone can take in at a glance, screenshot, or share.