Run any Skill in Manus with one click

test-strategy-review

Stars5

Forks0

UpdatedJuly 10, 2026 at 09:59

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

tollens-ai

tollens-ai/quality-strategy-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

More from this repository

same repository

quality-strategy-review

tollens-ai/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.

2026-07-115

quality-strategy

tollens-ai/quality-strategy-skills

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.

2026-07-115

operational-distillation

tollens-ai/quality-strategy-skills

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.

2026-07-105

tooling-strategy

tollens-ai/quality-strategy-skills

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.

2026-07-105

test-strategy

tollens-ai/quality-strategy-skills

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.

2026-07-105

strategy-variants

tollens-ai/quality-strategy-skills

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.

2026-07-105

name	test-strategy-review
description	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.

Test Strategy Review

This skill audits a test strategy — the light testing lane /test-strategy produces. The document under review is deliberately light (a filter table plus per-ility Have / Improve / Add discussions and agreed moves), so the review is proportionate: one sealed forward-walk, a set of mechanical checks, one consolidated report. What it does not relax is the bar — the five indicators in $PLUGIN_ROOT/skills/test-strategy/INDICATORS.md (Direction / Priority / Sufficiency / Feasibility / Honesty) are predictions about what happens when the team runs the doc, and the review judges against them.

Resolving file paths — do this first

This skill is part of the quality-strategy plugin. Before anything else, resolve two absolute paths and use them throughout:

PLUGIN_ROOT — the plugin's install directory: ${CLAUDE_PLUGIN_ROOT} (Claude Code expands this to an absolute path when it loads this file; read it off and note it down). The grounding files this skill reads live under it.
PROJECT_DIR — the absolute path of the project whose test strategy you're reviewing (normally the current working directory; confirm with the user if it's ambiguous). The strategy docs normally live under $PROJECT_DIR/quality/ — but /quality-strategy asks at session start where the strategy should be saved, so they may live elsewhere. If $PROJECT_DIR/quality/ is absent, get the docs home instead of assuming: from the orchestrator's brief when this skill was dispatched, else by asking the user; if the path you're given ends in /quality, its parent is the home. From then on treat $PROJECT_DIR as that docs home wherever a path below says $PROJECT_DIR/quality/... — one substitution, made once, before you act on any path.

File references below use the $PLUGIN_ROOT and $PROJECT_DIR placeholders. Substitute the resolved absolute paths before you act on them — both when you Read a file yourself and when you put a path into a subagent brief; a dispatched subagent inherits none of your context.

Before you start

Read $PLUGIN_ROOT/PHILOSOPHY.md, $PLUGIN_ROOT/skills/test-strategy/FRAMINGS.md, and $PLUGIN_ROOT/skills/test-strategy/INDICATORS.md. If $PROJECT_DIR/quality/test-strategy.md doesn't exist, tell the user: "There's no test strategy to review. Run /test-strategy first." You also need $PROJECT_DIR/quality/strategy.md — the review is relative to the quality strategy the doc claims to serve; without it you can only check internal consistency, and you say so plainly.

The work, in order

1. Read both docs

Read $PROJECT_DIR/quality/test-strategy.md and $PROJECT_DIR/quality/strategy.md (Parts 3–6 at minimum) end-to-end. Note the release each names — a test strategy stamped for a different release than the quality strategy it cites is a finding, not a detail. If quality/archive/ holds prior test-strategy-* versions, the newest is the diff instrument for check 8.

2. The forward walk (sealed dispatch — the primary lens)

Dispatch one subagent (the Agent tool, general-purpose), sealed from your conclusions, with the resolved absolute paths of both docs and $PLUGIN_ROOT's PHILOSOPHY / FRAMINGS / INDICATORS in its brief. Its job: simulate carrying out the agreed moves exactly as written, in order, and predict what comes back. After each move: what question got answered, what does Part 6's risk map look like now — which Unknowns became known, which confidences moved? Then judge the whole doc against the five indicators, aggressively (flag freely; the main agent filters): Direction (every kept ility and move traces to a risk-map row; nothing targets a None or non-goal), Priority (Dealbreaker-linked first; cheap-first within impact), Sufficiency (every H/M ility has a filter verdict; every Dealbreaker addressed by some lane or eyes-open declined; the fresh-eyes recon on the table or reason-recorded), Feasibility (each move concrete: question, answered-when state, who runs it, sane human/agent split), Honesty (guesses marked as guesses; "what the tests actually tell you" not proxy comfort). It returns findings with quotes and locations.

3. Mechanical checks (main agent)

Run these yourself against the doc on disk:

Filter-table coverage. Every H/M ility from the quality strategy's Part 5 appears in the filter table with a verdict (in this lane / named sibling lane / out, with reason). A silently absent H/M ility is a FAIL.

Dealbreaker coverage. Every Part 3 Dealbreaker is addressed by an agreed move here, explicitly handed to a named sibling lane, or explicitly declined eyes-open with a reason. FAIL only a Dealbreaker with none of the three — a dealbreaker ility may legitimately also carry deferred lower-priority ideas; that alone is not a violation.

Fresh-eyes recon disposition. The standing fresh-eyes defect recon is agreed, on the table, or dropped with the user's recorded reason. Silently absent is a FAIL; its briefs, if agreed, must be stated blind to the strategy.

Proxy milestones are labelled and bounded. An agreed move's "answered when" may cite a proxy milestone (coverage %, green CI, review-per-change in place) — proxy goals are legitimate (FRAMINGS #8) — but only when the move states what remains unknown about the ility when the proxy is satisfied; that statement is what labels it a proxy. FLAG an answered-when that treats proxy satisfaction as the ility achieved (no what-remains-unknown stated) — not the mere presence of a proxy milestone.

Header stamps. The header carries the release (matching the quality strategy's *Release:* line) and the version stamp with a resolved version (a literal <version> placeholder is a FLAG; the stamp itself is deliberate attribution — never strip it).

Independence preserved. Nothing in the doc suggests the strategy was derived from reading the product's source (FRAMINGS #3) — e.g. moves justified by source-file internals no conversation or strategy section carries. FLAG with the quote.

Claimed audits have evidence. /test-strategy no longer runs a mandatory tooling audit, but if the doc claims a /tooling-adequacy (or other) audit ran, its output must exist where claimed (quality/.scratch/ or conversation record). A claimed-but-absent audit is a FAIL — fabrication signal.

Update integrity (updated test strategies only). Detect an update: the doc's own ## Since the last cycle section, or a diff against the newest quality/archive/test-strategy-* showing substantial carried-over content (an archive alone is NOT the signal — fresh runs archive too). An update by diff with no ## Since the last cycle section is a FAIL — a silent revision. If you cannot read the filesystem, report INCONCLUSIVE, never PASS on faith. For a detected update, diff, don't trust: (a) every prior agreed move carries a what-happened verdict, and every "answered/closed" cites the finding or is honestly believed answered at a stated confidence — an unevidenced closure is a FAIL; (b) the update contains genuinely new content not derivable from the prior doc — a closures-only diff is the anchoring signature, a FAIL ("the gaps have moved; verifying the past is not assessing the present"); a recorded note that nothing relevantly changed stands in as n/a. FLAG a ## Since the last cycle section with no prior version in quality/archive/ — the producer archives before revising, so a missing archive means history was silently rewritten.

No process-note / scaffolding leak. The port of /quality-strategy-review's check 21. Run an actual grep-style scan over the whole doc, including content inherited from a prior version (exactly what earlier passes never re-saw). The body must be clean of process/provenance/lineage artifacts — they belong in quality/.scratch/ or .skill-feedback.md. FLAG any that leaked (a doc peppered with individually-minor instances still FLAGs), and note the producer must remove them before the doc is done — a strip, not a note. Patterns: (i) first-person-about-the-skill commentary ("this step was awkward", "the skill asked me to…"); (ii) dispatch/scratch/sealed-pass narration ("[ran /tooling-adequacy inline]", "Subagent dispatched: …", "scratch would be quality/.scratch/…") — keep the decision, drop the mechanism; (iii) turn/step lineage refs ("corrected, turn-23", "folded in from the filter step") — cross-references to the doc's own named sections are fine, references to the process that built it are not; (iv) scratch-file path citations as sources — cite the real underlying source (the risk-map row, the named finding) or drop it. Two exemptions: a ## Since the last cycle section is content, not machinery; the header version stamp is deliberate attribution — leave both.

Effective Comms backstop. The producer runs /effective-comms before finalizing; this catches the reader-facing modes the leak scan doesn't: (i) numbered references without meaning (a row/ility cited only by ID); (ii) coordinate-before-name (a path or label leading where a human-readable name should); (iii) buried recommendation — the doc's "do this next" hard to find when actionability is its job. FLAG with a one-line "name it / lead with the name / surface the action".

Severity: FAIL on checks 1–3, 7, and 8 is a blocker; the rest are flags.

4. Collapse and report

Merge the forward-walk findings with the mechanical results: drop false or trivial findings, group shared root causes, split blockers (the doc would steer the team wrong or claims things that didn't happen) from flags (worth fixing, not blocking). Produce one consolidated report: the forward-walk's headline prediction ("run as written, here's where the risk map lands"), then per-indicator verdicts with quotes, then the mechanical checklist with PASS/FLAG/FAIL and one-line fixes. End with the two or three changes that would most improve what running the strategy produces. Offer to walk the user through any finding.