菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Audit a quality strategy document. Applies seven indicators of a good strategy plus mechanical oracle checks, and asks "where is this strong, where is this weak?". Use after /quality-strategy completes, or to audit an existing quality/strategy.md cold.
Turn a complete-but-dense quality or test strategy into something operational — a 6–10 line TL;DR plus a one-page triage rubric (and an optional operator cheat sheet) placed at the top of the doc, so a returning reader re-orients in seconds instead of skimming hundreds of lines. Use from /quality-strategy at the end of the plan of work, or standalone to distill any existing strategy.
Produce the strategy for the second quality question — "how do we know if what we have is good?" Gathers every place the strategy lanes could NOT answer that (risk-map Unknowns nothing can judge yet; build items agreed in /evaluation-strategy; /test-strategy moves blocked on instruments or oracles) and turns them into a prioritised oracle/instrument build plan at quality/tooling-strategy.md. Use after /evaluation-strategy (ideally also /test-strategy), when Unknowns are piling up in the risk map, or when deciding what measurement or test infrastructure to build next.
A deliberately light follow-up to /quality-strategy for the testing lane — ingest the release's quality strategy, filter for the ilities testing can make a dent on (where you don't know where you stand and investigating would tell you), then per ility discuss what testing you have, what could be improved, and what could be added. High-level ideas and questions, not step-by-step hand-holding. Produces quality/test-strategy.md. Use after /quality-strategy completes for a release.
Derive audience-facing variants from a finished quality strategy — a distributable one-pager for the people the strategy names, and a client-safe ("polite") version that drops frank internal candor without lying. Use after /quality-strategy has produced and reviewed quality/strategy.md, when you need something to hand to engineers, a PM, contributors, or a named external audience — a client, or for a project with no client, its end users, funders, or a due-diligence reader — rather than the full internal artifact. Gates mechanically on strategy completeness before producing anything.
Detect cross-Part contradictions in a quality or test strategy document — places where one part of the doc asserts something another part denies or undercuts. The mechanical doc-internal-consistency check that the user-facing substantive checkpoint misses, because "this feels wrong" and "Part 3 contradicts Part 4" are different failure modes. Use from /quality-strategy at step boundaries, or standalone to audit any strategy doc for internal contradictions.
| 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. |
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.
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:
${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").$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.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.
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.
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.
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:
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.)
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.
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.
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.
A quality strategy answers four questions, in order:
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:
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.)
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.
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.
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:
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.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:
## Part 6 header per release — never one blended pass that makes a reader work out which release a row belongs to.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.
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>" — <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.quality/strategy.md; the ledger is raw and unchallenged by design, judged later by the lane that considers adopting it.The ledger is durable content, not scratch — like the release bank, it survives sessions and gets consumed by later skills.
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:
/test-strategy — the testing lane: where investigation would move the risk map (quality/test-strategy.md)./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)./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)./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.
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.
Execute the sub-steps strictly in order. Later sub-steps depend on earlier ones.
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.
For each sub-step:
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.
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:
/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.
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.
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.
Wait for the user's response. Treat any of the following as signals to dig in, not as confirmation:
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."
If the user surfaces something, treat it as a finding:
OPEN QUESTION and keep going?" Cross-step revision is first-class, not a failure.OPEN QUESTION: with the user's explicit acknowledgement that we're proceeding with that risk visible.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.
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.
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:
/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:
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."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.)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..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.
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.
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.
/clearThese 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.
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.
/clear hereAfter 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):
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 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."
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:
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./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:
quality/strategy.md before we start to recover the working memory.""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.
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:
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>.mdand 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.
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.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.
## Since the last revision that this was drift handled as a correction, naming what drifted.