Quality Strategy Review

Quality Strategy Review

This skill audits a quality strategy document. It is the source of truth for "is this strategy any good?". Run it as the final step of /quality-strategy, or on its own against any existing quality/strategy.md.

The skill uses an expansion-and-collapse pattern:

• Expansion. Three subagents run in parallel, each with its own review lens. Their briefs tell them to be aggressive — flag freely, dig for specifics, raise anything that feels off — because the main agent will filter their output. In review work, missing a real issue is worse than raising a false alarm.
• Collapse. The main agent reads all three outputs, drops false or trivial findings, looks for findings that share a root cause, separates blockers from flags, and writes one consolidated report.

This is brainstorm-then-curate, not one-pass judgement. One-pass review tends to miss things or drown the reader in trivia; two stages avoid both.

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 and framework files this skill reads live under it.
• PROJECT_DIR — the absolute path of the project whose 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. The Read tool does not expand variables, and it resolves relative paths against the current working directory — not this skill's directory. A dispatched subagent starts with none of your context. So an unexpanded placeholder or a bare relative path will fail. Always pass full absolute paths.

Before you start

Read $PLUGIN_ROOT/PHILOSOPHY.md. The disciplines and the framework grounding are the foundation of the review.

What you need

The strategy doc to review at quality/strategy.md. If quality/pre-read.md exists, also read its summary and discrepancies sections — pre-read findings the strategy didn't address are themselves review findings.

If quality/archive/ holds prior versions of the strategy (files whose names start with strategy-), the newest may be the instrument for a revision review: subagent A diffs it against the current doc (check 22) rather than trusting the revision's own account of what changed. An archive alone does not make the doc a revision — fresh-replace and new-release runs archive too; check 22 detects which this is.

If quality/strategy.md doesn't exist, tell the user: "There's no strategy doc to review. Run /quality-strategy first."

The work, in order

1. Read the strategy

Read quality/strategy.md end-to-end. Note which parts are present, which are missing, which look thin.

If quality/pre-read.md exists, read its summary and discrepancies sections.

2. Contextual-fit gate (Pass 0)

Run this before the indicators, and carry its verdict into the collapse step. If you hold a pre-implementation or deliberately thin strategy to the full production-grade scale, you get the wrong answer: deliberate scope control reads as weakness, and quality strategy turns into ceremony. The framework's spirit is contextual quality. So first work out what this strategy is for, then judge whether it's fit for that job.

Read the ## Strategy job paragraph at the top of the doc. If it's present, take its job classification. If it's missing, that is itself a finding — the producer skill should have written it. Infer the job from the content (no code yet + mostly-Unknown actuals ⇒ pre-implementation; "one-shot" / "agentic implementation attempt" language ⇒ agentic one-shot; thin slice with many deliberate Nones ⇒ lightweight slice; otherwise durable production) and flag the missing paragraph.

Classify on these axes:

• Lifecycle stage — pre-implementation / implementation / alpha / beta / production / maintenance.
• Intended use — one-shot brief / release alignment / test planning / stakeholder alignment / operational dashboard.
• Evidence available — no code yet / runnable prototype / production telemetry / user feedback.
• Expected weight — lightweight decision aid / full durable strategy.
• Allowed to ignore — what this strategy explicitly says is out of scope.

This produces one of four jobs: durable production / pre-implementation / agentic one-shot / lightweight slice.

What the gate changes — and what it doesn't. The seven indicators and the oracle checks apply to every job; the gate does not switch indicators on or off. What it adapts is severity — where the line sits between a blocker and a deferral. Specifically:

• Pre-implementation — unknown actuals (the "where are we now" side of the risk map) are normal, not a weakness. Don't score situational awareness harshly for unknown actuals. The question becomes: does the strategy name what evidence the first implementation must produce? A missing production-observability section is a deliberate deferral, not a blocker.
• Agentic one-shot — additionally check the strategy captures: one-shot success / partial-success / failure criteria; final-report evidence requirements (spec gaps, judgment calls, commands run, environment issues, human steering); predictable agent failure modes (scope substitution, fake tests, overbuilding integrations, skipping hard e2e, silent redesign) with decision rules; and explicit Nones to keep the implementation thin. Absence of these is a blocker for this job; absence of production machinery is not.
• Lightweight slice — missing production observability, mature process, broad compatibility, and long-term reporting are not blockers if the strategy explicitly makes them non-goals. If they're silently absent (not declared Nones), that's a flag, not a blocker.
• Durable production — full machinery enforced; the standard severity rules below apply unchanged.

The blocker rule the collapse step uses: a missing section is a blocker only if its absence prevents the strategy from doing its stated job in this context. If the missing section belongs to a later lifecycle stage, classify it as a deliberate deferral or a suggested future revision, not a current blocker. Every review finding goes in one of three buckets: current blockers, useful pre-implementation/now refinements, and later-lifecycle deferrals.

Record the job classification and the resulting severity lens; pass them into the subagent briefs (so subagents judge against the right job) and apply them in the collapse step.

3. Dispatch three review subagents in parallel

Use the Agent tool with three calls in a single message.

Subagent A — Mechanical oracle checks

> You are subagent A, running mechanical oracle checks against a quality strategy document. You are a backstop, not the primary line of defence — the writing process should already have enforced these checks via per-sub-step DONE checklists. Your job is to verify nothing slipped through. > > **This strategy's job is: `.** Mechanical checks still run regardless of job, but when you flag a missing-section check (non-goals, risk-map coverage, rating justification), note whether the gap looks like a *deliberate deferral* appropriate to this job rather than a true failure — the main agent decides severity per the contextual-fit gate. > > Be aggressive about flagging — false negatives (missing real issues) are much worse than false positives (the main agent will filter what you flag). > > **Meta-flag.** A failing oracle check is also evidence that the relevant sub-step's DONE checklist was never really enforced — the agent ticked a box without doing the check. So when you flag a failure, add to your explanation: *"this should have been caught in sub-step X.Y's DONE checklist, but wasn't."* The user wants to know that. > > First, read $PLUGINROOT/PHILOSOPHY.md and $PLUGINROOT/skills/quality-strategy/SKILL.md to ground yourself. > > Then read $PROJECTDIR/quality/strategy.md. > > Run the following oracle checks. For each, classify as **PASS / FLAG / FAIL** and write one line of explanation. For FLAGs and FAILs, also include a one-line "what to fix" suggestion plus the meta-note about which sub-step's DONE should have caught this. > > 1. **Non-goals not empty.** Part 4 has at least 3 non-goals, each with a reason. > 1a. **Non-goals are quality bars, not feature exclusions (the kind bar).** Each Part 4 entry names a quality dimension deliberately not being reached for this release's in-scope work — not a capability or feature the roadmap already defers. FAIL a Part 4 whose entries are *entirely* feature exclusions or unmodified roadmap deferrals with no quality-bar decision among them ("no Windows support" restated with nothing about what quality bar that implies is not a quality non-goal — that's the roadmap's job, and restating it doesn't count toward the minimum). A deferral-derived entry is fine when it's re-expressed as the bar it implies for in-scope work (e.g. "scalability beyond small files" citing a deferred bulk-import feature as its reason) — the check is on the entry's *kind* (a bar, not a feature), not on whether a deferral is mentioned in the reason. > 1b. **Non-goals reasoned forward, not from absence (no status-quo bias).** Each Part 4 non-goal's reason names an *intentional tradeoff traced to a stated goal*, not the mere fact that the capability isn't built. FLAG any non-goal whose stated reason is status-quo — "not built", "no code for it", "doesn't currently support" — with no goal-traced tradeoff behind it: an absence is a fact about the repo, never on its own a decision the user made. FAIL a non-goal that a **named event in Part 2** (a launch, a campaign, an onboarding spike) would plausibly pull back into scope — e.g. "no custom email / SMTP" recorded as a non-goal alongside a Part-2 Twitter launch that implies a signup spike: that is a buried gap wearing a non-goal's label. (This is the doc-visible half of sub-step 4.1's two disciplines; the confirmation half — was each cut named back and confirmed? — isn't visible on disk, so subagent C carries it as a consistency lens.) > 2. **No percentages in confidence ratings.** Grep for "%" in confidence contexts (Parts 5 and 6). Confidences should be H/M/L only. > 3. **Ratings grounded in the anchor.** Ratings use the H/M/None model. Every H rating's rationale names a stakeholder **Dealbreaker** bar from Part 3; every M rating's rationale names a non-Dealbreaker bar (Good Enough or Delight). A rating that doesn't cite the bar the anchor rests on is a FAIL. > 4. **None ratings reasoned.** Every None rating in Part 5 has explicit reasoning, not blank. > 4a. **Floors and default-ins.** Read $PROJECTDIR/quality/pre-read.md's floor-predicate section (and any predicates confirmed in the interview). For every floor whose predicate holds — handles secrets, holds PII, holds entrusted data a user would want back, ships to others' machines, licensing/data-protection law — the matching floor dimension must be present in Part 5 and **not rated None** (FAIL if a holding predicate has no dimension, or its dimension is None: a floor can't be voted off). For each default-in — **security always**, **data integrity / loss where the system holds user data**, **unbounded spend where the system can spend money** — Part 5 must either carry the dimension or the doc must carry an explicit, recorded eyes-open **accepted-risk** for it; a default-in that is *silently* absent (no dimension and no accepted-risk note) is a FAIL. The failure this catches: a sweep that produced no security dimension on a project whose headline risk was forgeable client-writable data. (If pre-read.md is absent or its floor-predicate section is missing, FLAG and judge the floors from the strategy body's own description of what the system holds and ships.) > 5. **Three lenses populated.** Every stakeholder in Part 3 has Delight, Good Enough, and Dealbreaker captured for the release the strategy covers (the header's Release:` line). > 6. Risk map covers all H/M dimension rows, scope preserved. Every dimension row rated H or M in Part 5 — keyed by dimension and scope, per Part 5's Scope column — has its own row in Part 6. FAIL if two same-named, differently-scoped Part 5 rows collapse into one Part 6 row (a dev-tool's "usability" for its own UI and "usability" for its API are two rows, two required levels, two actuals — never one shared row because the name matches). Where this doc's negotiated structure (2.1) covers more than one release, also FAIL a Part 6 row with no explicit release tag when more than one release's rows appear near each other — a bare "relevant release" is not sufficient. > 6a. Document structure recorded, and every later Part honours it (multi-release docs only). If the doc's content shows more than one release with real depth beyond purpose-level (check Part 2, and whether Parts 3–7 carry material for more than one release), Part 2 must carry a "Document structure:" field naming the negotiated choice (per-release doc + bank / light sections / two releases in parallel / fully separate documents) — FAIL if that content exists but the field is missing or blank; a doc structure can't be inferred reliably after the fact and its absence means a cold reader (or a later session) has no way to know how the doc was meant to be organised. Then check the chosen structure was actually honoured: under "two releases in parallel," Parts 3 through 7 (and Part 6 per check 6) show clearly separated per-release sections/tables/headers for both releases — FAIL a blended pass that mixes both releases' content with no separation. Under every other structure, only one release should carry real depth in Parts 3–7 of this document — FAIL any Part 3–7 content that is clearly about a different release and was folded into this release's tables/lists rather than routed to its bank entry, light section, or separate document (the tell: a stakeholder, non-goal, dimension, risk-map row, or action whose content plainly describes a different release's context, sitting unmarked among this release's rows). This is the doc-visible half of the routing discipline each sub-step's text now carries — SKILL.md → "Scope of this skill". > 7. Risk map confidence on both sides. Every Part 6 row has confidence-in-required and confidence-in-actual (or "—" for Unknown). > 8. Confidence vocabulary correct. All confidences are H/M/L (or "—" for Unknown actuals). > 9. Unknowns have resolution notes. Every Unknown actual in Part 6 has a "to resolve" note (test / ask / review / instrument / build). > 10. High justification — not distribution. Ratings use the H/M/None model (no L). Do not flag a High-dominated distribution by count alone: by rating time the low-stakes material was already deliberately cut (dropped at the inventory, excluded as a non-goal, rated None), so Highs dominating what remains is the expected sh

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: tollens-ai
• Source: tollens-ai/quality-strategy-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.