# Quality Strategy Review > 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. - **Type:** Skill - **Install:** `agentstack add skill-tollens-ai-quality-strategy-skills-quality-strategy-review` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [tollens-ai](https://agentstack.voostack.com/s/tollens-ai) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [tollens-ai](https://github.com/tollens-ai) - **Source:** https://github.com/tollens-ai/quality-strategy-skills/tree/main/skills/quality-strategy-review ## Install ```sh agentstack add skill-tollens-ai-quality-strategy-skills-quality-strategy-review ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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 `$PLUGIN_ROOT/PHILOSOPHY.md` and `$PLUGIN_ROOT/skills/quality-strategy/SKILL.md` to ground yourself. > > Then read `$PROJECT_DIR/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 `$PROJECT_DIR/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](https://github.com/tollens-ai) - **Source:** [tollens-ai/quality-strategy-skills](https://github.com/tollens-ai/quality-strategy-skills) - **License:** Apache-2.0 Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-tollens-ai-quality-strategy-skills-quality-strategy-review - Seller: https://agentstack.voostack.com/s/tollens-ai - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.