# Quality Strategy > 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. - **Type:** Skill - **Install:** `agentstack add skill-tollens-ai-quality-strategy-skills-quality-strategy` - **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 ## Install ```sh agentstack add skill-tollens-ai-quality-strategy-skills-quality-strategy ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Quality Strategy This skill runs a structured interview to produce `quality/strategy.md` — a business-level document defining what success looks like for the project and how to get there. It is grounded in Edmund Pringle's quality framework. The skill is intentionally long — a serious strategy takes a working day or two of hard thinking spread across multiple sessions (see README for full context). The work is broken into 21 small sub-steps so progress is easy to see, the user can pause at any point, and the strategy doc builds up section by section — what's already written survives interruptions. Taking longer than expected is a sign that real thinking is happening; rushing produces a strategy that looks complete but skipped the substance. ## Resolving file paths — do this first This skill is part of the `quality-strategy` plugin. Resolve three paths and use them throughout — `$PLUGIN_ROOT` immediately; the other two are settled by the session-start questions, not guessed beforehand: - **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). Every file this skill references — `PHILOSOPHY.md`, the sub-step files under `skills/quality-strategy/steps/`, etc. — lives under it, as does `.claude-plugin/plugin.json`, whose `version` field stamps the generated strategy (see sub-step 1.1 and "Output"). - **REPO_SCOPE** — the absolute path(s) of the repo(s) or directories being *analysed*: one or several. Products often span several repos — never assume one; session start asks which are in scope (see "Session start"), and the working directory is only the natural suggestion for a one-repo product. In the sub-step files, `$PROJECT_DIR` means *the repo a brief targets*: with one repo in scope it is simply that repo throughout; in a multi-repo scope, per-repo dispatches each get their own repo's absolute path substituted for it (the fan-out rules live in the sub-steps). The scope is analysis input only — the strategy stays one document for the system, not one per repo. - **DOCS_DIR** — the absolute path the strategy's outputs are *written* under: the whole `quality/` family (`quality/strategy.md`, `quality/pre-read.md`, `quality/releases/`, `quality/ideas.md`, `quality/.scratch/`, `quality/archive/`) plus `.skill-feedback.md`, together as one unit — never split across locations. This is the save location the user chooses at session start (see "Session start" below): one of the repos in scope when the strategy goes in-repo, or a directory outside them for a local first pass. Resolve it on **every** invocation, before the session-start moves write anything: if the working directory holds a `quality/` folder, the working directory is the docs home — read `quality/.scratch/session-config.md` and restate the standing choices; if it holds none, ask whether this is a fresh strategy here or one saved elsewhere (see "Resumption") — only a confirmed fresh start proceeds to the session-start ask. Normalisation: the directory the user names *becomes* `$DOCS_DIR` and the `quality/` folder is created inside it; if a path they point at already ends in `/quality`, its parent is `$DOCS_DIR`. Every `quality/...` path in this skill and its sub-step files resolves under `$DOCS_DIR` — including inside subagent briefs, where you substitute the resolved absolute path, since a sealed subagent can't ask anyone where the docs live. File references below use the `$PLUGIN_ROOT` and `$DOCS_DIR` placeholders, plus the per-repo `$PROJECT_DIR` in sub-step briefs. **Substitute the resolved absolute paths before you act on them** — both when you Read a file yourself (including the sub-step files) and when you put a path into a subagent brief. The Read tool does no variable expansion and resolves relative paths against the current working directory, not this skill's directory; a dispatched subagent inherits none of your context. So an unsubstituted placeholder or a bare relative path will fail — always pass fully-resolved absolute paths. ## Before you start Read `$PLUGIN_ROOT/PHILOSOPHY.md` if you haven't already. The disciplines that recur in every step — interview don't infer; ask rather than guess; record assumptions; understand the why; make confidence visible; push back on vagueness (ask for precision — when, how often, to what extent — never invent it); make non-goals explicit; stay sequential — are non-negotiable and applied throughout. ## Phrasing — adapt, don't recite You are running a working session as a sharp facilitator would — a useful management consultant, not a robot reading a script. The sub-step files quote example prompts (the *italicised* lines) to show the **intent** of each question and the bar it has to clear. They are illustrations, not lines to read verbatim. Put them in your own words, fitted to *this* user, *this* project, and what they just told you: compress or expand, match your tone to a precise expert versus a stuck novice, drop the preamble once rapport is established, follow up harder where an answer came back thin. What is fixed is the *substance* — the question that must get answered, the check that must pass, the push-back that must happen, the assumption that must be recorded. What is free is the *wording*. So: never skip a substantive question, soften a real check, or drop a required push-back to sound friendlier — but equally, never recite a prompt word-for-word when a more natural phrasing does the same job better. When a sub-step says *"ask X"*, it means *get X answered*, not *utter this exact sentence*. A session that sounds like a person thinking with the user beats one that sounds like a form being read aloud — and the framework's rigour lives in the substance, which adapting the words does not touch. Keep the language **plain** (PHILOSOPHY: *say it plainly*) — in what you say *and* in what you write to the doc. Framework terms get a one-clause gloss on first use; everything else is everyday English: short words, active verbs, concrete examples. You sound like a sharp consultant talking, not a standards document. ## Heavy only where it serves the user's goals This process is demanding, and the demand can feel heavy to a user who just wants to ship. The weight is a feature only when the user can see it serving **their own stated goals** — the stakeholder Dealbreakers and Delight bars, the release purpose, the things *they* said matter. Three standing rules keep it that way: - **Frame every why in the user's own words.** Every substantive ask or stretch of work gets its why framed in terms of what *this* user already said — *"we're digging here because you said losing a user's data is a dealbreaker"* — never in terms of the framework's own needs. Early on, before the stakeholder bars exist, the trace is the release purpose and whatever goals the user has stated so far; once Part 3 exists, trace to the named bars. - **The standing pruning rule.** An item — a question, a dimension, a check, an action — that traces to no stated goal is spurious weight. Either cut it, or challenge whether a goal is missing: *"nothing you've told me makes this matter — should it? Is there a stakeholder or a bar we haven't captured?"* Never carry untraceable weight silently. - **The honest fork when a goal-justified item meets resistance.** When the user pushes back on something the trace genuinely supports, show the trace, then offer the fork: *"this is here because you said X is a dealbreaker — so either this deserves the dig, or X isn't really a dealbreaker. Which is it?"* Be convinced the item matters for the goal, or revise the goal. **Both outcomes are legitimate**, and both get recorded — conviction lands in the section's rationale; revision lands as a change to the bar it traced to. This sharpens the substantive refusals rather than softening them: the things the skill refuses to skip (non-goals, the unpack pass and the old/new-world *reasoning*, real checkpoints) are exactly what make the user's stated goals checkable — when a user balks at one of those, that is the trace to show. (The old/new-world reasoning is non-skippable; what it is *not* is a ceremony the user sits through — it runs as machinery and surfaces only its outcomes. See sub-step 5.3.) ## Name the scope — release, stakeholder, surface An unscoped noun is where imprecise thinking hides. Whenever you name a dimension, a bar, a risk, or a plan item — in the doc's tables and in the conversation itself, not just on the page — say precisely which **release** it's for, which **stakeholder** (or stakeholder capacity) it's about, and which **surface** of the product it concerns. "Usability" said bare could mean the Studio user's usability, the agent-calling-the-API's usability, or the docs reader's usability — three different things with three different bars, and collapsing them into one unscoped word is exactly how a real distinction goes missing. **The dev-tool double.** Where the project is itself a tool that produces or hosts other people's work — an IDE, a CI product, a framework, this pack itself — naming the surface also means naming *which side*: the tool's own quality, or the quality of the work the tool helps its users produce. A dev tool's own reliability is not the reliability of the projects it builds; "usability" for the tool's own interface is not "usability" for the workflows it generates. Name the side explicitly, the same way a stakeholder is named. This applies everywhere a dimension, bar, risk, or action gets named, throughout the whole strategy — sub-step 5.1's scope column is where it's most visible on the page, but the discipline is conversational first: say the scope out loud before it goes on the page, and push back on your own draft language if it names a dimension without saying whose and where. ## Cluster-by-cluster, not one flat list When Step 5 (Dimensions) or Step 6 (Risk Map) has more than a handful of items and they fall into natural clusters — dimensions unpacked from the same composite (5.2), the agent-facing cluster (5.1), dimensions sharing a stakeholder or a theme the conversation has already surfaced — present and confirm them **cluster by cluster**: walk one cluster's items, get confirmation, move to the next. A single flat list dumped at the user for a large step forces them to hold everything in their head at once and makes disagreement hard to localise; a cluster at a time keeps the conversation anchored to one theme before moving on. This is a **presentation** discipline, not a re-derivation of the underlying work — the rating, the required/actual levels, the risk-map rows are still produced exactly the way each sub-step describes; clustering changes how they're walked back to the user for confirmation, not how they're computed. **Flat-list stays legal** when the items genuinely don't cluster — a short list, or one where nothing meaningfully groups. A rough test for "meaningfully": if you'd naturally introduce the group with a name before the user has to ask — *"let's do the security-shaped ones next"* — it clusters; if forcing a name for the group feels artificial, it doesn't. In the no-cluster case, record it plainly: *"considered, no clustering"* (with a one-line reason if it's not obvious), rather than silently presenting a flat list without having asked the question. What's not legal is a flat list nobody considered clustering at all — **and the record belongs in the doc, not only the conversation**: each sub-step's output carries a one-line "Clustering:" note (the groupings used, or "considered, no clustering") so a returning reader can verify it without replaying the transcript. This applies at 5.1 (surfacing the consolidated raw inventory, when it's long and clusters exist — a lighter touch than 5.4+, since 5.1 is still a single settle-the-list pass, not yet a per-item confirmation loop), 5.4 (rating summary and the High-justification glance), 5.5 (sanity-check findings), and 6.1–6.3 (required levels, actual levels, the risk map itself) — see each sub-step file for how it lands there. **Once a grouping is established** (typically at 5.4, the first sub-step where the H/M set is stable), later sub-steps reuse the same clusters rather than re-deriving fresh ones — a dimension that was "agent-facing" at 5.4 shouldn't silently become part of a different cluster at 6.2 with no stated reason; re-cluster only when the dimension set itself has genuinely changed since. ## Session start — the itinerary, the repo scope, where the strategy lives, and the commit cadence Five moves at the start of every working session (first or resumed), before the next sub-step's work begins — and, on a first session, before sub-step 0 writes anything to disk: **Give the itinerary, in plain words.** Walk the route by human name — what each step produces *for the user*, with rough relative sizes — not the sub-step table read aloud. For example: *"Seven steps, and the first two are quick: context (what the project is, who's working on it) and releases (what's shipping when). Then stakeholders — the first real thinking: who matters and what their bars are. Non-goals — short but load-bearing: what we're deliberately not doing. Dimensions — the longest step: the axes quality breaks into here. The risk map — the headline: where you're actually exposed. And the plan of work — short, and optional. We're at [X]."* On resumption the itinerary doubles as re-orientation: what's done, what remains. **Ask which repo(s) we're analysing (first session).** Products often span several repos — an app repo, an API repo, an infra repo — and a strategy that silently analyses whichever one you happen to be sitting in describes a fraction of the system. So ask, before the save-location question (whose options depend on the answer): *"Is everything we're analysing in this repo, or does the product span others? List everything that's in scope — paths I can reach, or names and I'll ask where they live."* Set `$REPO_SCOPE` to the answer; one repo is a fine answer, and with no repo at all the scope is empty and the interview carries the load. Beyond about five repos, warn that per-repo evidence gathering gets deep and slow at that width, and offer to scope this pass to the load-bearing repos — recording the rest as out of scope for this pass, not silently dropped. However many repos are in scope, the output is still **one strategy for the system**: repos are where evidence comes from (and evidence can cite which repo it came from), never a reason to split the document. **Settle where the strategy will live — and say why: you want their true opinions (first session).** The interview ahead asks for candid judgment: who really matters, what's actually weak, what the user would cut. Everything they tell you persists — each sub-step writes their answers into the `quality/` docs — and where those docs live decides who can read them. A user who doesn't know where their words are going either holds back exactly the candor the strategy needs, or gives it and regrets it. So before anything is written to disk, tell them two things in the same breath — that you want them to be able to answer really honestly, and where their answers will be recorded and who will see them — and ask where that should be: > *"Before we start: this works best when you can answer really honestly — your true opinions about what matters, what's actually weak, what you'd cut. Everything you tell me gets written into the strategy docs, so where they live decides who reads your answers. Two usual homes. **In the repo** (`/quality/`) — right when the strategy should be everyone's the moment it exists; anyone with repo access will read what you say here, and commits publish it to them. Or a **local first pass** — a folder outside the repo, say `~/strategies//` — right when this is one person's take that you want to iterate on privately and share only … ## 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 - 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%.