quality-strategy

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

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 (<project>/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/<project-name>/ — right when this is one person's take that you want to iterate on privately and share only if and when it's ready. Or name any directory you like."

When in-repo would put the answers in front of a wide audience — many committers, an open or org-visible repo, the user's own description of the project already says so (a shared team repo, an org everyone reads), or the user hesitates at "anyone with repo access"; where it isn't already stated, a glance at the git log's author list and the remote host, or simply asking "roughly how many people can read this repo?", settles it — don't just offer the local pass neutrally: recommend it, proactively, in the same breath as the ask. If the wide-audience signal is already evident from what the user has told you, fold the recommendation into this very first ask — don't wait to see whether the user lands on local-first themselves and then merely ratify it once they do; volunteering it yourself and then agreeing is not the same as recommending it. Do the private copy first, tidy it up or redact later, and share when it's ready. The choice stays the user's; the recommendation is part of an honest ask, not pressure.

With several repos in scope, "in the repo" sharpens to "in which repo?" — suggest the umbrella or primary repo if one exists; when none stands out, a folder outside all of them is usually cleaner. Set $DOCS_DIR to the answer (normalised as in "Resolving file paths": the named directory is the home; the quality/ folder goes inside it). The whole output family follows it as one unit — strategy, pre-read, release bank, ideas ledger, scratch state, archive, feedback notes — never half the docs in one place and half in another. If the user asks for in-repo-but-gitignored, honour it but name the hazard in one line: a private draft inside a shared working tree is one accidental git add from published, so a folder outside the repo is the safer private option. And when there is no repo at all (see "Running without a repo is first-class"), the ask collapses to confirming which folder should hold the docs — it still runs; what never happens is silently defaulting a candid draft into a location the user didn't choose.

Promoting a local pass later needs no machinery — when it's ready to be everyone's, tidy or redact anything that was for-your-eyes-only candor (the user's own editorial pass on their draft — no skill does it for them), copy the quality/ folder into the repo, refresh session-config.md inside it to record the new in-repo location (or delete the note and let the next session re-ask), and commit; .skill-feedback.md deliberately stays behind — it's notes about the skill, not part of the strategy. Say so if the user asks. Whenever local-first is settled — whether by your recommendation or the user's own choice — name the other route to something shareable in the same breath, and always answer directly if the user asks what "tidy it up" or "redact later" actually means: /strategy-variants (run once the strategy is finished and reviewed) derives audience-facing files — a distributable one-pager, or a client-safe version pitched at an external reader the user names (a paying client; or, when there's no client anywhere, end users, funders, a due-diligence reader) that drops the frank internal candor without lying — without ever editing the honest doc, so the private pass can stay private and still produce something to hand out. A user who asks what "tidy it up later" means and gets only a vague reassurance hasn't had the question answered — name the mechanism, don't just promise the outcome.

And candidness is raised here, once — never sprung mid-session. Folding the honesty rationale into this ask is what licenses the pointed questions later (who really matters, what's actually weak, what would you cut): by the time they arrive, the user already knows where their words go, because they chose it. Don't re-open the subject mid-interview with a fresh "this next part is sensitive" warning — a user surprised by candidness halfway through has been failed by this ask, not helped by the warning. If the user turns visibly guarded mid-session (answers going suddenly short, hedged, or diplomatic), restate the standing choice in one line — "this still only goes to <location> — nobody else reads it unless you move it" — rather than running a new disclosure ceremony.

Ask the commit-cadence question (when the save location is git-managed). Where $DOCS_DIR is git-managed — unless the docs are gitignored there, in which case commits can't include them: skip the question and record "gitignored — no cadence" in the session-config note — ask once: "As the strategy doc builds up, want me to commit at each step boundary, commit everything at the end, or leave the commits to you?" Suggest commit-as-we-go as the default — rollback stays cheap, and each boundary commit doubles as visible progress. One qualifier: where the docs sit in a repo other people share, say what the cadence means in the same breath — each boundary commit publishes that step's draft to everyone who pulls. The user chose in-repo knowing who reads it; this line keeps the consequence visible at the moment it becomes mechanical, and a user who hesitates at it may prefer commit-at-the-end or a local pass after all. Honour the answer at every step boundary from then on; don't drift.

Record the choices in the session-config note. Write the session-start decisions — the repo scope (every absolute path with its scratch slug — the directory basename, lowercased; when two in-scope repos share a basename, disambiguate each slug with a short path-derived suffix — e.g. api-core and api-payments from their parent directories — so every slug is unique: the pre-read dispatches and the review's one-triple-per-repo audit both read slugs from this note, and colliding slugs would overwrite one repo's evidence with another's — plus anything deliberately scoped out this pass), the save location (with its one-line who-can-see-this reasoning), and the commit cadence (or why there is none: "not git-managed", "gitignored") — to $DOCS_DIR/quality/.scratch/session-config.md, so they survive /clear: a resumed session reads the note and restates the standing choices in one line instead of re-asking, and re-asks only what the note is missing. (Strategies begun under older versions may carry only quality/.scratch/commit-cadence.md; read the cadence from it and carry it forward into session-config.md.)

The standing rule behind all of this (and behind the progress lines and visible exits at every boundary — see "Substantive checkpoint at step boundaries"): the user must never feel the process is unbounded. At any moment they should know where they are, what remains and roughly how big it is, and what they keep if they stop here.

The four-question frame and the strategy's job

A quality strategy answers four questions, in order:

1. What does good look like? — stakeholder bars, dimensions, required levels (Steps 1–6.1).
2. How do we know if what we have is good? — the oracles (ways of judging) and instruments (tools that measure) we'd use to judge the actual state. This is its own question, not a free rider on Q3.
3. Is what we have good? — the actual-state assessment, each actual naming the basis that judges it (Steps 6.2–6.3).
4. How do we make it good? — the plan of work to close gaps (Step 7 — a sketch, and optional; see "The plan of work is a sketch" below).

Q2 is explicit on purpose — and deliberately not executed here. The common failure is to collapse Q2 into Q3 — to claim an actual level from whatever signal happens to exist, without ever asking whether that signal can judge the dimension. This skill's share of Q2 is honesty: sub-step 6.2 requires every actual to name its basis (what was observed, and what judges it) or be recorded as Unknown. The Q2 sweep — auditing each dimension's oracle and planning better judging — is the follow-on /evaluation-strategy lane, run after the strategy closes; the quality strategy stays pure (who matters, what they value, where we stand) rather than attempting an oracle sweep it isn't equipped to carry.

The strategy's job. Before the analysis, Step 1 (sub-step 1.1) asks what this strategy is for, right now, and records it as a ## Strategy job paragraph at the top of the doc. The four jobs:

• Durable production strategy — active product/release; ongoing quality management; full machinery applies.
• Pre-implementation strategy — actuals are mostly unknown; the job is to focus the build and name what evidence the first implementation must produce.
• Agentic one-shot experiment — the primary question is whether the docs can steer an agent to a correct, usable artifact with minimal human steering.
• Lightweight slice / prototype — many production dimensions should be explicitly None, not treated as gaps.

The same framework and the same rigour apply to all four; what differs is the right output and the right severity of review. /quality-strategy-review reads this paragraph first (its contextual-fit gate) and adapts what counts as a blocker accordingly. Project shape (solo / team / org; shipped / not-yet / dormant; agent-driven or not) is a separate axis that shapes how questions are phrased, not how deep the analysis goes — full project-shape branching is a later phase, but capture shape in Step 1 where it helps phrasing.

Running without a repo is first-class. Two of the four jobs — pre-implementation and agentic one-shot — are normally run with little or no code to hand, and even a durable-production strategy can be built by a founder or lead who has the project in their head but no repo open. This is a supported, sensible way to use the skill, not a degraded fallback: a quality strategy is most valuable before the build, when it can still steer it. When there's no codebase to scan, the pre-read degrades honestly (it says so, and tags what it inferred vs scanned — see sub-step 0), the interview carries the load it always carries, and the closing review judges the strategy against its no-repo job rather than docking it for unknown actuals. Don't apologise for the missing repo or treat it as a problem to work around — interview the user as the authority on their own project, record assumptions, and produce the strategy. The only thing a missing repo costs is the pre-read's scan-derived hypotheses; everything load-bearing was always going to be asked, not read. (The session-start ask about where the strategy lives still runs — with no repo it just collapses to confirming which folder holds the docs.)

Sealed-context dispatch and scratch files

Wherever this skill does substantive analytical work via a subagent — the pre-read (sub-step 0), the dimension scout (5.1), the dimension rating (5.4), the targeted design deep-dive (6.2, when thin-evidence design-shaped dimensions exist), the boundary contradiction check (/contradiction-check), the distillation (/operational-distillation at 7.3), and — in revision mode — the two look-forward passes (the fresh defect recon and the what's-new context scan; see Revision mode) — the dispatch is sealed-context: the subagent sees only what it needs for its piece, not the parent's DONE criteria, not the rubric it will be judged against, not the destination doc's success conditions. The orchestrator's role is dispatch / collect / reconcile / present, not to do the analysis itself with the answer key in view. This is the central anti-shortcut principle of the pack.

Every such dispatch writes a scratch file at $DOCS_DIR/quality/.scratch/<sub-step>-<purpose>.md recording the real intermediate work it did (e.g. 0-pre-read-*.md, 5.1-dimension-scout.md, 5.4-dimension-rating.md, 6.2-design-deep-dive.md (conditional — an explicit skip note in the doc stands in when no dimension qualified), <boundary>-contradiction-check.md, 7.3-operational-distillation.md; revision mode adds revision-defect-recon.md, revision-context-scan.md, and — for its closing whole-doc contradiction check — revision-contradiction-check.md). This converts "did the orchestrator actually do the work?" from invisible to auditable: /quality-strategy-review mechanically checks that every claimed dispatch has its scratch file. A missing scratch file is hard evidence the dispatch didn't happen. quality/.scratch/ is working state, not part of the strategy — do not treat it as authoritative output, and don't leak its contents into quality/strategy.md.

Process-note leak prevention. Orchestrator meta-observations about the skill itself (an awkward step, a suspected bug, phrasing that didn't land) go to $DOCS_DIR/.skill-feedback.md only — never into quality/strategy.md. The strategy doc reads as an authored artifact, not a transcript of the skill running.

The machinery of running the skill — dispatch/scratch narration ("Subagent dispatched: …", "[ran 5.4 inline]", "scratch would be quality/.scratch/…"), append bookkeeping, sub-step/turn lineage refs ("corrected, turn-23", "split out at 5.2") — likewise has no place in quality/strategy.md. This is cleaned up at review time, not by loading the writing pass with a list of don'ts. Write the finding or the question; the step-boundary review and the final /quality-strategy-review strip any machinery that slipped through (see "Presentation cleanup at review points" below). The reasoning: a pass that's busy doing the real analysis shouldn't also juggle a list of don'ts — that taxes the work and still misses leaks. Catching them where the doc is reviewed is both lighter on the writer and more thorough.

Deliver revelations as moments

The highest-value thing this skill can produce is not the document — it's the moment the user realises something matters about their project that they never articulated (PHILOSOPHY: the revelation is the product). The sealed passes are where these surface: the dimension scout (5.1), the pre-read, the fresh-eyes recon in revision mode. Each reads the project without the user's framing, so each can find something the user never mentioned but their stated goals imply they'd care about.

When that happens, do not bury it in a consolidated list. Name it back as a moment, traced to their own goals: "you didn't mention X anywhere — but given what you said about Y, you'd care a lot if X failed. Does that land?" Then record the outcome either way: if it lands, it enters the doc as the user's own, with the trace; if it doesn't, record that it was considered and why the user set it aside. A rejected revelation is data, not failure — it usually sharpens a non-goal.

This is a delivery discipline, not a new pass. The work already happens; the discipline is to spend the find where it pays — as a named moment the user gets to react to, not row 17 of a table.

Scope of this skill — one release deep, every release captured

The strategy is explicitly per-release. The doc header names the release it covers (set at sub-step 2.1), and the depth analysis (stakeholders, three-lens, non-goals, dimensions, risk map, plan of work) is that release's analysis — one release at a time, typically the next one the team is about to ship. Other releases are noted at purpose level during sub-step 2.1 (Roadmap) so the strategy isn't blind to what's coming. This is deliberate: a release's context shapes the strategy heavily, and deep analysis of a release whose context isn't settled yet produces speculation, not strategy.

But capture faithfully across releases — the doc structure is negotiated, not assumed. Users often dictate more than one release's worth of strategy in one session ("for the beta, losing a game record is the dealbreaker — oh, and when we do the enterprise release, compliance becomes the whole game"). Never flatten that into the current release's sections, and never drop it — but don't assume banking is the only shape either. The first time sub-step 2.1 (Roadmap) surfaces that the session genuinely spans more than one release with real content beyond purpose-level, offer the structural choice explicitly rather than defaulting silently:

• Per-release doc + bank (default). This release gets full depth in this doc; content for other releases is banked — recorded faithfully, close to the user's own words, labelled with its release — in quality/releases/<release-slug>.md (slug: the release name, lowercased and hyphenated — for a release the user hasn't named yet, ask for a working name, or slug their own phrase for it; create the file on first use, append after). Worked in full when that release's own session arrives.
• Light sections in the current doc. When the user is only lightly touching future releases, their content lands as light, purpose-level sections inside this same doc rather than a separate bank file — visible alongside the current release's depth, without the full analysis.
• Two closely-related releases in parallel. When two releases are similar enough that treating them together makes sense, one document covers both at matched depth — a deliberate choice, not a default.
• Fully separate documents. When releases are different enough that sharing a document would blur them, each gets its own strategy document from the start.

Ask which fits, once multiple releases are genuinely on the table — "You've mentioned both the beta and the enterprise release with real detail. Do you want the beta banked for later, given light treatment right here, worked together with this release since they're related, or written up as fully separate documents?" Record the negotiated choice twice, once each for two different jobs: in quality/.scratch/session-config.md (the fast, within-session working reference) and — this is the durable record — stamped into Part 2 of quality/strategy.md itself, where the releases were laid out (2.1's Output template carries a "Document structure:" field for exactly this). Scratch can be lost, cleared, or simply not re-read; a strategy doc read cold, days later or by a different agent, must be able to tell its own structure from its own Part 2 without replaying the session. The choice is made once and stands for the rest of the session — a third or fourth release surfacing later routes the same way without re-asking, unless the user revisits it.

Every later step — Steps 3 through 7, not just 5.1 — reads Part 2's structure choice and organises its own output to match it. Two things this buys, depending on the choice:

• Under "two releases in parallel" (the one structure where more than one release gets full depth in the same document), each step's output is clearly separated per release — its own section, table, or (for Step 6) its own ## Part 6 header per release — never one blended pass that makes a reader work out which release a row belongs to.
• Under every other structure (per-release doc + bank, light sections, fully separate documents), only one release gets full depth in any given document — so the routing rule below is what keeps the other releases' material out of this one's tables.

The universal routing rule, every step: whenever material surfaces — at intake or mid-step, from a generator or straight from the user talking — that belongs to a release other than the one this pass is going deep on, it goes to that release's home per the negotiated structure (its own section under "parallel," its light section, its bank entry in quality/releases/, or its separate document) and is named to the user in half a line — "banked for the enterprise release", "that's a v3.0 item — added to its light section" — never silently folded into the current release's rows or tables. This is 5.1's original banking discipline, generalised: it isn't a Step-5-only move, it's what every step does with out-of-scope material the moment it shows up, including mid-conversation surfacing at Step 6 or 7 that has nothing to do with the inventory-building generators 5.1 runs. What's never negotiable, whatever the structure chosen: every dimension, bar, risk, or plan item names exactly which release — and, per "Name the scope" above, which stakeholder and surface — it belongs to. Don't detour into deep analysis of a release that isn't the one this pass covers (unless "two releases in parallel" was the negotiated choice, in which case both get their depth pass by design), and don't make the user repeat themselves when its turn comes. Banked or lightly-sectioned content is durable, not scratch: new-release mode pre-loads whichever form exists as starting hypotheses. Dictate once, keep it, use it when its release arrives.

When the team is ready to start a future release, re-invoke the skill in new-release mode (see Revision mode below) to produce a fresh strategy for it — whatever was banked, lightly sectioned, or already drafted in parallel comes in as starting hypotheses, named back for confirmation. Some sections (team, workflows, roadmap) carry over with incremental updates; others (stakeholders, dimensions, risk map, plan of work) are largely rewritten because the release context has changed.

Spontaneous user ideas — capture once, classify later

Users generate ideas as they work through the strategy — "we could diff the two implementations nightly", "every change should get a review pass", "I'd know it broke if the ramp-up doc stopped matching reality". Don't prompt for these — there's a time for that later: eliciting measurement, rule, and testing ideas is the follow-on lanes' job, and prompting mid-strategy derails the interview into solution space. But when the user spontaneously offers one — something that goes beyond answering the question just asked: a volunteered suggestion for how something could later be tested, measured, or enforced — it has a dedicated home — the ideas ledger, quality/ideas.md (create on first use, append after). A plain descriptive answer is not an idea: "we ship every two weeks" is Part 1 content, a dealbreaker threshold is a Part 3 bar; the ledger holds only the volunteered how-we'd-check-or-uphold suggestions that have no Part of their own.

• The user's words, close to verbatim, linked to the dimension or context it arose in (and the release). One bullet per idea, so a later lane can annotate a single entry: - "<the user's words>" — <dimension/context>, <release>, <date>. Acknowledge in half a line — "noted in the ideas ledger" — and carry on; no detour into designing it. The ledger is one file across all releases — deliberately, unlike the per-release bank: an idea volunteered during one release's session is usually still worth considering when a later release's lanes run, and the per-entry release tag carries the provenance.
• No classification at capture time. Don't decide whether it's a proxy, an oracle, a process rule, a test charter, or something else — the same idea is often several at once (a review-per-change habit is simultaneously a quality proxy and a process rule), and role assignment is the lanes' job, done later with the whole strategy in view. A capture that pre-files the idea under one role quietly closes the others off. Capture is also deliberately exempt from the pruning rule and the precision push-back — those govern what enters quality/strategy.md; the ledger is raw and unchallenged by design, judged later by the lane that considers adopting it.
• An idea for a different release still goes to the ledger — its release tag carries the provenance. The release bank holds non-idea strategy content — bars, priorities, purpose — dictated ahead of its release; a volunteered how-we'd-check-or-uphold suggestion goes to the ledger whichever release it's for.
• The lanes read the ledger as an input. Each follow-on lane, at ingest, walks the ledger and considers each idea for its own modality; an idea can land in several lanes. A lane that adopts one annotates the entry ("→ taken up in test-strategy, ") — never deletes it, since a sibling lane may want it too.
• In-session adoption works the same way. A lane isn't the only thing that can adopt a ledger entry — the main strategy itself sometimes does, later in the same session: a spontaneously-volunteered idea at one sub-step becomes the user's own stated bar at a later one ("before this ships I want some kind of shadow-mode check against real historical invoices", captured to the ledger at Part 2, becomes their own Good Enough bar in Part 3's three-lens pass twenty minutes later). This is the interview circling back, not a lane ingesting — annotate the entry the same way a lane would ("→ adopted directly into Part 3, "), never delete it, since a follow-on lane may still want the raw idea for the mechanics of building what the bar now requires.

The ledger is durable content, not scratch — like the release bank, it survives sessions and gets consumed by later skills.

The plan of work is a sketch — follow-on skills elaborate it

Part 7 (Step 7) lists, classifies, and sequences the work at strategy level — enough to see the shape of what's needed, the priorities, and the first moves. It is deliberately not a detailed work plan, and you should not let it become one. The detail belongs to the follow-on skills, each of which takes a slice of Part 7 and turns it into a first-class plan of its own:

• Testing work → /test-strategy — the testing lane: where investigation would move the risk map (quality/test-strategy.md).
• Evaluation work → /evaluation-strategy — the evaluation lane: where better quality instruments — oracles that judge, proxies that indicate — would make the project knowable (quality/evaluation-strategy.md); agreed build items go on to /tooling-strategy for the prioritised build plan (quality/tooling-strategy.md).
• Rules, process, and process-change work → /process-strategy — the rules/invariants/processes lane: where changing how work is done — including the team, org, or workflow itself, Part 7's fourth action class — prevents whole defect classes or reaches the goals more efficiently than a product fix (quality/process-strategy.md).
• Communicating the strategy → /strategy-variants — audience-facing variants of the finished doc.

The three lanes are deliberately lighter than this skill — high-level ideas and questions per ility, one or two focused conversations each, the differential stated in their own prompts. Each ingests this strategy for the release, filters for the ilities its modality can make a dent on, and works have-already / could-improve / could-add through them with the user.

Stakeholder work and fixing work have no follow-on skill yet; they stay at sketch level in Part 7 like everything else. Keep Part 7 entries to one or two lines each, resist expanding any of them into a mini-plan in place, and point at the relevant follow-on instead — a Part 7 that duplicates test-strategy.md's depth goes stale the moment the follow-on runs.

Step 7 is optional — the whole sketch can be deferred. At the Step 6 boundary, once the user has confirmed at the 6.3 substantive checkpoint, offer the choice: walk Step 7 now, or skip it and defer the plan of work wholesale to the follow-on lanes. Skipping is the right call when the team will run the lanes (/test-strategy, /evaluation-strategy, /process-strategy) immediately — a sketch written minutes before its own elaboration adds nothing. The skip is recorded, never silent: append a short Part 7 deferral note —

## Part 7: Plan of Work

Deliberately deferred — elaborated by the follow-on lanes rather than sketched here:
testing work → `/test-strategy` (`quality/test-strategy.md`); evaluation work →
`/evaluation-strategy` (`quality/evaluation-strategy.md`, builds via `/tooling-strategy`);
rules/process work → `/process-strategy` (`quality/process-strategy.md`). <If a slice of
the work has no follow-on planned — stakeholder work, fixing work — say in one line what
happens to it.>
First investigation: the risk map's hottest items (Part 6).

If any "aware, not investing this release" decisions surfaced during the risk-map discussion (the conscious deferrals sub-step 7.1 would normally record), capture them in the deferral note — that record must not be lost to the skip. Then run the same closing moves sub-step 7.3 prescribes, unchanged: the boundary /contradiction-check over the whole doc, /operational-distillation, /quality-strategy-review, and the /effective-comms pass (see "Final step: distill, then review"). The review treats a recorded deferral as satisfying its plan-of-work checks; a Part 7 that is simply missing or empty, with no deferral note, remains a failure.

How this skill is structured

The work is divided into 7 numbered steps, each with one or more sub-steps — 21 sub-steps in total, including the pre-read (sub-step 0) that runs before Step 1. Each sub-step lives in its own file under steps/. The full sequence:

Sub-step	File	Produces
0 — Pre-read	steps/0-pre-read/0-dispatch.md	Project digest at quality/pre-read.md
1.1 Purpose	steps/1-context/1-1-purpose.md	Product purpose, immediate goal, longer-term ambition
1.2 Team	steps/1-context/1-2-team.md	Roles + how they work together, including agent team members
1.3 Workflows	steps/1-context/1-3-workflows.md	How work actually flows — human + agentic-process walk, anticipated user workflows, working-well/friction per area
1.4 Release workflow	steps/1-context/1-4-release-workflow.md	How releases ship
1.5 Budget	steps/1-context/1-5-budget.md	Resources and constraints
2.1 Roadmap	steps/2-releases/2-1-roadmap.md	Per-release purposes
3.1 Identify stakeholders	steps/3-stakeholders/3-1-identify.md	Who matters per release
3.2 Three-lens analysis	steps/3-stakeholders/3-2-three-lens.md	Delight / Good Enough / Dealbreaker per stakeholder
4.1 Non-goals	steps/4-non-goals/4-1-non-goals.md	Explicit exclusions per release
5.1 Dimension inventory (raw)	steps/5-dimensions/5-1-inventory.md	Bottom-up + top-down (subagent) + reconcile → raw consolidated inventory
5.2 Unpack pass	steps/5-dimensions/5-2-unpack.md	Split composite dimensions into sub-dimensions where priorities differ
5.3 Old/new-world pass	steps/5-dimensions/5-3-old-new-world.md	Split trap dimensions where the audience (human vs agent) changes the rating
5.4 Rate dimensions	steps/5-dimensions/5-4-rate.md	Mechanical-anchor impact rating (H/M/None) per dimension — per-stakeholder via a sealed dispatch, then merged; no L (L-style aware-but-not-investing is a Step 7 decision)
5.5 Sanity checks	steps/5-dimensions/5-5-checks.md	High justification, stakeholder coverage, tensions, non-goal alignment
6.1 Required levels	steps/6-risk-map/6-1-required.md	What level is needed for each H/M dimension
6.2 Actual levels	steps/6-risk-map/6-2-actual.md	Where we are on each H/M dimension
6.3 Gap and confidence	steps/6-risk-map/6-3-gap-and-confidence.md	The risk map combining required + actual + confidence on both sides
7.1 Derive actions	steps/7-plan-of-work/7-1-derive.md	What needs doing, drawn from the risk map
7.2 Classify	steps/7-plan-of-work/7-2-classify.md	Each action as testing / stakeholder / fixing / process-change
7.3 Sequence	steps/7-plan-of-work/7-3-sequence.md	Phasing and dependencies
7.3 — Operational distillation	invoke /operational-distillation (separate skill)	TL;DR + triage rubric placed at the top of the strategy
7.3 — Effective Comms pass	invoke /effective-comms (separate skill)	Audience-fit / hidden-context / names-before-coordinates gate before the doc is finalized

Sub-steps 7.1–7.3 are optional — the user may defer the plan of work wholesale to the follow-on skills via a recorded deferral note (see "The plan of work is a sketch"); the 7.3 closing moves (contradiction check, distillation, review, Effective Comms pass) run either way.

Execution rules — non-negotiable

1. Execute the sub-steps strictly in order. Later sub-steps depend on earlier ones.

2. Read one sub-step file at a time. Do not read sub-step N+1 until you have completed sub-step N. Reading multiple sub-step files at once leads to racing through the work and producing a strategy that looks complete but skipped the substance.

3. For each sub-step:

   • Read its file.
   • Execute the pre-read, interview, and section-writing as the file directs.
   • Run the "This sub-step is DONE when" checklist at the end of the file.
   • If any check fails, return to questioning. Do not proceed.
   • When all checks pass:
     • At intermediate sub-steps (1.1–1.4, 3.1, 5.1–5.4, 6.1–6.2, 7.1–7.2), do a light wrap-up: summarise in 2–4 lines and ask "any quick concerns, or ready to continue?" Move on at yes.
     • At step boundaries (end of sub-steps 1.5, 2.1, 3.2, 4.1, 5.5, 6.3, 7.3), run the substantive checkpoint (see below) on the whole step's output. Only proceed after explicit, considered confirmation.
   • Only then read the next sub-step file.

4. Write output incrementally. As each sub-step completes, append the relevant section to quality/strategy.md. If a session is interrupted, what's already written is durable.

Substantive checkpoint at step boundaries

This is the single most important user-facing pattern in the skill. The strategy is waterfall — mistakes caught early cost minutes; mistakes caught late cost hours of rework. So each step boundary needs a real gate where the user genuinely engages.

Where it runs. At the end of each of the 7 steps — the close of sub-steps 1.5, 2.1, 3.2, 4.1, 5.5, 6.3, 7.3 — not at every sub-step. Per-sub-step transitions get a light wrap-up. The substantive checkpoint runs at step boundaries because that's when:

• The user has a complete chunk of strategy to evaluate (a whole Part of the doc, not a fragment).
• The user can read back the whole step and ask "does this hang together?" rather than evaluating a single piece in isolation. Smells about priorities or completeness usually only become visible when you can see the whole step at once — you can't tell if a stakeholder's three lenses are right by looking at one stakeholder; you tell by looking at all of them together.
• Cross-step revisions become practical. Doing later steps often surfaces things that change earlier steps' answers (e.g. while doing dimensions in Step 5, you realise a stakeholder's bar from Step 3 was wrong). The step-boundary checkpoint is when that gets acted on.

The pattern at each step boundary

0. Run the contradiction check first (sealed dispatch). Before summarising, dispatch /contradiction-check as a sealed-context subagent on the doc as written so far — substituting the resolved absolute $DOCS_DIR paths (the doc, and the quality/.scratch/ destination for its scratch file) into the brief, since a sealed subagent can't ask where the docs live. It mechanically cross-references the Parts for internal contradictions — a Part-3 dealbreaker a Part-4 non-goal excludes, an H/M dimension with no risk-map row, a high-confidence actual whose evidence is "none yet". This is a different failure mode from the substantive checkpoint below: the checkpoint catches "this feels wrong to me" (human, by feel); the contradiction check catches "Part X denies what Part Y asserts" (mechanical, by cross-reference). Fold any contradictions it returns into the summary so the user sees them at the checkpoint. The dispatch writes its scratch file (see "Sealed-context dispatch and scratch files"). A clean result is a real result — say so and move on.

0b. Silently strip presentation leakage from this step's Part(s). Re-read the section(s) this step just appended to quality/strategy.md and quietly remove machinery that isn't strategy — see "Presentation cleanup at review points" below for the patterns. Do this without narrating it; the cleanup never appears in what you say to the user. This is review-time cleanup of the freshly-written Part, the per-subsection counterpart to the final whole-doc review.

1. Summarise the whole step's output back to the user in 5–8 lines, covering the decisions that matter across all sub-steps in the step — plus any contradictions the check surfaced. Not a recap of process — a recap of decisions. Where Step 5 or Step 6's content falls into natural clusters, this summary (and the sub-step walkthroughs that built up to it) presents cluster by cluster rather than as one flat list (see "Cluster-by-cluster, not one flat list" above) — a large step read back as one undifferentiated block is exactly what makes "does this hang together?" hard to answer.

1b. Give the progress line and the visible exit. One line of where-we-are, with relative sizes: "That was Step 5 — the longest one. Two steps left: the risk map, about half the size of what you just did, and a short optional plan of work." And one line of what stopping here leaves them with: "If you stopped now, you'd walk away with your stakeholders' bars and the rated dimensions on paper — already something you can act on — and we can resume from the doc any time." Both are honest, not cheerleading: the doc genuinely is useful part-done, and resume genuinely is supported.

Ground any time-empathy in the actual session. A line acknowledging elapsed effort — "we've been at this a good while", "after all this work" — is only honest when it's true of this run. A half-hour lightweight session is not "a good while", and a weariness line that doesn't match the clock reads as canned and quietly undermines the trust the progress lines are building. So check the real session — elapsed time, the weight of what was covered, how many steps in — before you reach for one, and skip it entirely when the run has been short or light. Like the example prompts, these are intent, not a script to recite on a timer.

2. Run the substantive checkpoint:

   "Take a real moment to read this back. We've completed [Step name]. Is anything off — even if you can't articulate why? Anything that gives you a weird feeling? Anything in earlier steps that, in light of this work, you now think is wrong? Even vague unease is worth surfacing. Catching it now is cheap; catching it later costs hours of rework."

   Adapt the tone to the user. When the user has been giving precise, articulate, complete answers — an expert who knows their domain — the open "any vague unease even if you can't name it?" prompt reads as a tic. Prefer the targeted form as the default: name the one place you most expect to be wrong and why, and ask them to test it — e.g. "Here's the one place I'd bet this is most likely wrong, and why: <…> — does that hold?" Reserve the open-unease phrasing above for users who are visibly uncertain or inarticulate. This is a change of phrasing only — the checkpoint itself still runs at every step boundary and still does the same work.

3. Wait for the user's response. Treat any of the following as signals to dig in, not as confirmation:

   • "I think so."
   • "Looks fine I guess."
   • Silence.
   • "Yeah, sure."
   • Any hesitation or non-committal response.

   Honest follow-up: "What's making it 'I guess' rather than 'yes'? Even a vague feeling is worth investigating — that's a smell, and smells are signal."

4. If the user surfaces something, treat it as a finding:

   • Articulable concern about this step — address it now. Re-do the relevant sub-step.
   • Articulable concern about an earlier step — surface explicitly: "That's about [earlier step]. Want to revisit that section before continuing? Or note as OPEN QUESTION and keep going?" Cross-step revision is first-class, not a failure.
   • Vague unease, can't articulate — investigate together. Probing questions: "What part of the section draws your eye?" "If you imagine this strategy in six months, where would the regret most likely come from?" "What's the closest you can get to naming it?" Either it resolves and the section is corrected, or it remains as OPEN QUESTION: with the user's explicit acknowledgement that we're proceeding with that risk visible.

5. Only move on after explicit, considered confirmation — not silence, not a non-committal response, not a polite "yes" with hesitation behind it. Once confirmed, this is where the boundary commit lands if the user chose commit-as-we-go at session start — the commit snapshots the confirmed step, never a version still under discussion.

Per-sub-step (intermediate) wrap-up

At the end of intermediate sub-steps (1.1–1.4, 3.1, 5.1–5.4, 6.1–6.2, 7.1–7.2), do a light wrap-up only: summarise back in 2–4 lines, ask "Any quick concerns, or ready to continue?" — get a yes, move on. Save the deep engagement for the step boundary. The user can't really evaluate intermediate sub-steps in isolation anyway — full evaluation needs the whole step in view.

While you're here, give the sub-section you just appended a quick, silent presentation-leakage scan (see below) — it's cheaper to strip a stray "scratch would be…" line now than to find a Part full of them at the step boundary. Keep this light and unannounced; the thorough pass is the step-boundary one.

Presentation cleanup at review points

The strategy doc should read as an authored artifact — the findings and decisions, not a transcript of the skill's machinery producing them. Rather than load the writing pass with a list of don'ts (which taxes the real work and still misses leaks), the cleanup happens at review time, on text already written, where it's both lighter and more reliable. Three review points share the job:

• Intermediate sub-step wrap-ups — a light scan of the one sub-section just written.
• Step boundaries — a thorough scan of the whole Part this step produced (item 0b in the pattern above), before you summarise it back.
• The final /quality-strategy-review — its check 21 is the whole-doc backstop for anything the per-Part passes missed. It is a strip, not just a flag: machinery check 21 surfaces is removed from the doc before the strategy is declared done, not merely noted. This matters most in revision / resumption mode: the per-Part boundary scans only see Parts written this session, so a strategy carried over from a prior version can contain leak patterns (provenance columns, sealed-pass narration) the boundary scans never touched — the final review must scan the entire doc, inherited content included.

Do all of this silently — narrating the cleanup is itself a leak. The scan is internal hygiene: never announce you ran a presentation pass, never tell the user the doc is "clean of machinery / no turn refs / no inferred-as-scanned", never report the result of the scan. The user hears findings and questions; the cleanup is invisible. (The worst version of this is narrating "presentation-cleanup pass… clean" at every step boundary — ironically leaking the machinery while claiming to remove it.) The same "findings, not plumbing" discipline applies to your own user-facing turns: talk to the user about the strategy, not about dispatches, scratch files, sealed passes, or which sub-step produced what. This is one light principle — speak findings, not machinery, and do the cleanup without mentioning it — not a content-prohibition list.

At each scan, re-read the target text and strip these machinery patterns — keep the finding, drop the narration:

• Dispatch / scratch / sealed-pass narration — "Subagent dispatched: …", "[ran 5.4 dimension-rating inline]", "scratch would be quality/.scratch/…", and the sealed-context merge vocabulary: "sealed pass landed M", "surfaced to the user", "merged to H because…", "the sealed dispatch returned…". Keep the decision (the rating, the merge outcome and its reason); drop the mechanism that produced it. E.g. rewrite "Bundle footprint — sealed pass landed None, surfaced to the user, merged to H" as "Bundle footprint — rated H: no stakeholder bar referenced it directly, but a stakeholder added a promotability bar that makes it a dealbreaker."
• Append / orchestration bookkeeping — "I'll hold off appending Part 4 until the user confirms", "now writing this to the doc". Do it silently.
• Sub-step / turn lineage references — both turn refs ("corrected, turn-23", "the turn-22 binding test") and sub-step-number refs ("split out at 5.2", "Action 6 from 7.1", "folded in from 7.1", "(pulled out of non-goals at turn 16)"). The reader of the final doc has no "turn 23" and no "7.1"; the strategy carries no provenance or lineage — it reads as settled content. (Cross-references to the doc's own Parts — "see Part 6" — are fine; references to the process that built it are not.)
• Provenance / source-column vocabulary — in the dimension inventory's source/evidence column and in rating rationales, the name of the internal pass that surfaced or rated a dimension: "Subagent pass", "reference-list pass", "subagent C's design observations", "Subagent dispatched: dimension-scout", "the per-stakeholder pass returned None … merged to H", "the oracle-adequacy pass as direct inputs". Keep the real grounding the column exists to carry — the stakeholder bar, the pre-read observation, the named file — and drop the dispatch/pass name that produced it. A "source" cell should cite what the dimension rests on, not which internal pass emitted it. (This pattern hides in table cells and rationale prose, so it survives a prose-only scan — look for it explicitly.)
• Scratch-file path citations — a "Sources consulted: quality/.scratch/5.1-dimension-scout.md" or "rests on … + quality/.scratch/5.4-dimension-rating.md". quality/.scratch/ is working state the reader does not have; cite the real underlying source (the pre-read digest, the stakeholder bars, the named code files) instead, or drop the citation. A .scratch/ path must never appear as a source in the strategy doc.
• Inferred-as-scanned pre-read lines — a "no audited gem detected" / "no .github/workflows found" written as if a scan ran when no code was actually read. Rephrase to the honest form the pre-read uses ("not yet established — confirm in interview") or cite the interview honestly. (This is the review-side companion to sub-step 0's honest-degradation rule.)

Two exemptions. The ## Since the last revision section a revision writes (see Revision mode) is content, not machinery — its what-happened verdicts and newly-found items compare the project against its prior strategy, which is analysis the reader wants. Leave it. And a pointer to the release bank or the ideas ledger ("further detail for the enterprise release: quality/releases/enterprise.md"; "ideas volunteered along the way: quality/ideas.md") is content too — both are durable, reader-visible files, unlike .scratch/ — leave the pointer; what gets stripped is capture narration elsewhere in the doc ("banked for X", "noted in the ideas ledger", "wrote to the bank") — keep the pointer, drop the play-by-play.

This is presentation cleanup only. It changes nothing about what work runs or which scratch files get written — every sealed dispatch still executes and still writes its scratch file, which /quality-strategy-review's scratch-file audit reads on disk. What changes is only what lands in the doc and what you say to the user.

Names before coordinates (PHILOSOPHY: write for both readers). The doc's own cross-references, and everything you say to the user, follow the pack's dual-legibility rule: labels and numbers ("Action F", "dimension 14", "Part 6") are pointers for cross-referencing, not names. At first mention in any section — and in any user-facing turn — call the thing by its human name with the label trailing as a pointer: "the payment-divergence simulation (Action F)", not a bare "Action F". Each section of the strategy should stand on its own for a reader who didn't write it and doesn't have the rest of the doc in working memory.

Initial pre-read

Before reading sub-step 1.1, run sub-step 0 (steps/0-pre-read/0-dispatch.md). Sub-step 0 is the first thing in the whole process that writes to disk, so the session-start moves — above all, where the strategy lives — must be settled before it runs. It dispatches subagents that read the repo(s) in scope — one dispatch set per repo when the scope has several — and produces a structured digest at quality/pre-read.md. Later sub-steps use the digest as starting hypotheses so the main agent does not have to load the whole project into its own context window.

Pause and resume

The work is hard thinking — the user will need breaks, not just want them. Be opinionated about where to take them: some sub-steps belong tightly together and breaking between them costs working memory; others are natural seams. If a user is trying to push through past 90 minutes of intense thinking, tell them the work degrades when they're tired and recommend a break — better to resume fresh tomorrow than ship a sloppy step today.

Stick-together sets — keep going, do not suggest /clear

These sub-step sequences depend heavily on the user's live working memory from the previous sub-step. The strategy doc captures the artefact, but not the live discussion (which stakeholder felt thin, which trade-off was surfaced, which dimension nearly got dropped). Breaking in the middle forces the next sub-step to re-orient from cold doc — losing real signal.

• 3.1 → 3.2 — stakeholder identification flows into three-lens. The discussion about who matters and why is the working memory for the lens analysis.
• 5.1 → 5.2 → 5.3 — the inventory evolves through unpack and old/new-world. The user's mental model of the dimensions accumulates across all three.
• 6.1 → 6.2 → 6.3 — required, actual, gap. Each H/M dimension should stay fresh across all three; jumping between dimensions while context is cold loses precision.

When the user is partway through a stick-together set, do not suggest /clear. If they ask to take a break, tell them: "This sub-step is part of a tight sequence with the next — we'd lose some working memory if we broke here. Want to push through to [end of set], or take a longer break before starting fresh?" Let them choose; just be explicit about the cost.

Natural break points — recommend /clear here

After any of these, the conversation is at a natural seam and /clear loses nothing important (the strategy doc + pre-read digest are the source of truth):

• After sub-step 0 (pre-read)
• After Step 1 (after 1.5)
• After Step 2 (after 2.1)
• After Step 3 (after 3.2)
• After Step 4 (after 4.1)
• After 5.3 (inventory complete)
• After 5.5 (Step 5 complete)
• After Step 6 (after 6.3)
• After Step 7 (before review)

At each of these natural break points, proactively suggest /clear rather than waiting for the user to notice the conversation is long — and say how to resume in the same breath, so resuming is stated, never guessed: "That's a natural break point. The strategy doc captures everything we've agreed; if you'd like to take a break or do this in another session, this is a good place to /clear. To pick up, just run /quality-strategy again — it reads your quality/ docs and scratch state and resumes from where we left off; you won't lose your place." Don't make the user notice and ask, and don't leave them to gamble that re-running the skill works — tell them it does. If the strategy lives outside the repo (a local first pass), add the one extra thing resuming needs: "we saved the strategy at <DOCS_DIR> — if you resume from a folder that doesn't hold it, just point me at that path."

Step 5 specifically

Step 5 is the longest single step (five sub-steps, with 5.1–5.3 stick-together). Before starting 5.1, check in: "Step 5 (Quality Dimensions) is the longest step — five sub-steps, three of which (5.1–5.3) work best done in one session. If you're tight on time, this is a good place to take a break first."

Resumption

On re-invocation, first re-find the docs home (this is the same on-every-invocation rule as in "Resolving file paths"), then detect the state of quality/strategy.md:

• If the working directory has a quality/ folder, the working directory is the docs home: set $DOCS_DIR to the working directory, read quality/.scratch/session-config.md, and restate the standing choices (repo scope, save location, commit cadence) in one line instead of re-asking.
• If it doesn't, don't assume a fresh start — the strategy may be a local pass saved elsewhere. Ask: "Starting a fresh strategy here, or resuming one saved somewhere else? If elsewhere, point me at the folder." One pointer restores everything: the session-config note saved beside the strategy carries the rest of the choices. (If the pointed-at path ends in /quality, its parent is the docs home.) Only when the user confirms fresh does the session-start sequence run from the top.

If a partial strategy exists:

• Read the existing doc to determine the last completed sub-step.
• Tell the user, naming the step in human words, not bare coordinates: "I see a partial strategy. Last completed: the dimension ratings (sub-step 5.4). Want to pick up from the sanity checks that follow, or revisit something earlier first?" — and give the session-start itinerary (see "Session start — the itinerary, the repo scope, where the strategy lives, and the commit cadence") so they see what's done, what remains, and the relative sizes.
• If the user is resuming into the middle of a stick-together set (e.g. they completed the raw dimension inventory in the prior session and are now resuming at the unpack pass), name it in human words, same as above: "Note that the unpack pass works best done in the same sitting as the raw inventory before it and the human-vs-agent framing check after it — re-orient from the inventory in quality/strategy.md before we start to recover the working memory."
• Resume from the user's chosen sub-step.

Within a sub-step

"Let me come back to that" is allowed. Record the deferred item as OPEN QUESTION: <one-line description> in the relevant section of the strategy doc. The sub-step's DONE checklist tolerates flagged-as-deferred items, as long as they are explicitly recorded. The final review skill will surface all open questions across the strategy.

Revision mode

The mode map — establish which mode you're in before touching anything. The same skill serves five modes, and each forbids different things. An agent landing mid-task (after /clear, a handoff, or a compaction) reads the doc and scratch state to establish the mode — in this order: a ## Since the last revision recording a correction scope means a correction in progress, bound by its recorded union; otherwise a fresh archive snapshot in quality/archive/ (dated this revision) means an interrupted re-walk or new-release run — the session-config note or the archive's own name says which; only a part-done doc with no fresh archive and no ## Since the last revision is a plain resumption (## Since the last revision is written late, so its absence alone proves nothing when an archive exists) — and then follows that mode's protocol, not a blend:

• Fresh — no strategy exists (or path (a) below): run the sub-steps from the top. Forbidden: silently carrying anything over.
• Resumption — a partial strategy: continue from the last completed sub-step (see "Resumption"). Forbidden: re-opening confirmed sections without the user asking.
• Correction — path (b): the doc misstates something; entry triage first, then scoped template re-application over the touched sections' downstream tree (see "Correction path (b)"). Forbidden: re-opening sections outside the recorded union; propagating any downstream change without user ratification.
• Full re-walk — path (c): walk all sub-steps, existing content as starting hypothesis. Forbidden: treating inherited content as confirmed without the look-back/look-forward movements.
• New release — path (d): archive, then a fresh strategy for the new release, bank pre-loaded. Forbidden: silently inheriting the old release's analysis as still current.

If quality/strategy.md already exists at full length (i.e. all sub-steps were completed in a prior session), one check before anything else: if the doc's ## Since the last revision records a correction scope whose union members still lack outcomes, that correction is in progress — resume its union walk under the recorded scope (no second archive, no re-ask). Otherwise ask the user before doing anything else:

I see a complete strategy. Are we: (a) starting fresh and replacing it; (b) correcting or revisiting specific sections — I'll first check with you whether it's a genuine correction or the world has moved; (c) doing a full re-walk of the current strategy, using the existing content as starting hypothesis; (d) starting a new release — in which case I'll archive the current strategy to quality/archive/strategy-<release-name>-<YYYY-MM-DD>.md and produce a fresh one for the new release?

Archive first — whatever the answer. Before changing a word, snapshot the current doc to quality/archive/strategy-<last-updated-date>.md — the date the doc was last updated, from its header if it carries one, else the file's modification date (path (d) uses its release-name form above). If that filename is already taken, suffix -2, -3, … — never overwrite an archive. Never silently rewrite history: the archive leaves a before/after trail the user can compare and share, and it is the instrument /quality-strategy-review diffs against when it reviews the revision. Mention the archive in your closing summary so the user knows it exists. One exception: re-entering the skill to fix blockers from a /quality-strategy-review of this same, not-yet-done strategy is the tail of the same writing session, not a revision — don't archive again, and don't re-run the movements below.

• For (a), proceed normally; the existing file will be overwritten as you go.
• For (b), run the correction path below: entry triage, then scoped template re-application over the downstream tree — plus the three movements, scoped to the union.
• For (c), walk all sub-steps as the three movements below, using the existing content as starting hypothesis for the look-back.
• For (d) — new-release mode — walk all sub-steps fresh, starting with sub-step 0 (pre-read). If the recorded repo scope (quality/.scratch/session-config.md) is unchanged from the prior release's session, the existing quality/pre-read.md may be reused rather than re-scanned — the code shape didn't change just because the release focus did — but say so plainly in the doc ("pre-read reused from the prior session — repo scope unchanged since ") rather than silently carrying it forward or silently re-running it. If the scope changed at all — a repo added, removed, or simply unreachable this session where it was reachable before — dispatch a fresh sub-step 0 pass; reachability and content-staleness are different reasons to re-scan, and both get a fresh pass, not just a genuinely-changed scope. Sub-steps that change less between releases (1.1 Purpose, 1.2 Team, 1.3 Workflows, 1.4 Release workflow, 1.5 Budget, 2.1 Roadmap) should pre-load the archived prior version's section as starting hypothesis and ask "what's changed?". Sub-steps that change more (3.1, 3.2, 4.1, 5.x, 6.x, 7.x) start more or less from scratch because the release context is fundamentally different — except what the user already dictated: check quality/releases/ for this release's banked notes (see "Scope of this skill") and pre-load them as starting hypotheses at the sub-steps they belong to, named back for confirmation ("when we banked this you said compliance becomes the whole game — still true?"), never silently assumed still current. Don't make the user repeat what they already told a previous session. Once the bank is worked through, mark it consumed — prepend "Consumed into the strategy, " to the bank file so a later session pre-loads only what's new, and the user never re-adjudicates notes twice. And note the doc lifecycle: path (d) rebuilds the strategy fresh after the archive — sub-step 1.1 re-creates the header (new Release: placeholder) and 2.1 stamps the new release.

Correction path (b) — triage first, then scoped template re-application

Entry triage — correction, drift, or context change? Users under-flag context changes — people are really bad at flagging every context change as a release — so diagnose rather than accept the user's framing. The discriminating question, asked of yourself and of the user: "was the document wrong about what was true then, or has what's true changed since?"

Verdict 0 — the document was never actually wrong. Check this before diagnosing which of the three verdicts below applies: re-read the passages the user cited directly, rather than trusting their framing or your own memory of the doc. Sometimes what looks like a contradiction is a reading error, not a documentation one — the required/actual/gap machinery is working exactly as designed (Part 3 names a bar, Part 6 honestly says it isn't met, Part 7 records that as a deliberate, non-silent choice), and the user applied the required-vs-actual distinction to two sentences that, read together, aren't in tension at all. If direct re-reading confirms the doc already says the right thing, there is no correction to make: show the cited passages side by side, explain the reasoning, and leave the doc untouched. No edit means no ## Since the last revision entry and no union-recording ritual — both exist to track changes, and this path makes none. This is not a way to dodge a real complaint — reach for it only when the passages genuinely support the doc as written, not as a default response to avoid the harder verdicts below.

1. Genuine correction — the doc misdocumented what was true for this release; the world is unchanged. ("Marta's dealbreaker was recorded too strictly — she always tolerated one-offs.") Run the scoped re-application below.
2. Small context drift — something has genuinely changed since, but the goals hold: the stakeholder bars (Part 3) and non-goals (Part 4) still say what they'd say if re-asked today. ("The release slipped three weeks — dates move, nobody's bar does.") Correction-style handling is still safe: run the scoped re-application, eyes open, and record in ## Since the last revision that this was drift handled as a correction, naming what drifted.
3. Overall context changed — what's true has changed and the goals move with it: re-asked today, some bar, priority, or non-goal would come out differently. ("Our biggest customer churned — who matters and what's a dealbreaker just changed.") However the user framed it, this is implicitly a new (or different) release: switch to new-release mode (path (d)) — the whole template, the previous doc referenced as starting hypotheses, but assume anything might have changed. Say why you're switching, in the user's terms: "that's not the doc being wrong — the world moved; if we patch sections one by one we'll keep a strategy whose goals no longer fit it."