From quality-strategy
Audit whether a quality strategy's actual-state assessment can be trusted — for each dimension, is there an adequate oracle to judge what level the project is actually at, and an adequate instrument to observe it? The explicit "how do we know?" (Q2) check that agents skip by deferring to whatever measurement exists and by treating hard-to-judge dimensions as permanently Unknown. Use from /quality-strategy during the risk-map actual-state pass, or standalone to audit the oracles behind an existing strategy's actuals.
How this skill is triggered — by the user, by Claude, or both
Slash command
/quality-strategy:oracle-adequacyThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill answers the second of the four quality questions — **"How do we know if what we have is good?"** — for the *actual-state assessment* of a quality strategy. It checks whether you can trust how the strategy decided "this dimension is actually at level X".
This skill answers the second of the four quality questions — "How do we know if what we have is good?" — for the actual-state assessment of a quality strategy. It checks whether you can trust how the strategy decided "this dimension is actually at level X".
It is the /quality-strategy counterpart to /tooling-adequacy (which does the same job for /test-strategy's learning needs). The two share one oracle core; they differ in what they assess. /tooling-adequacy assesses a learning need (a question the strategy wants testing to answer); /oracle-adequacy assesses a dimension's actual-state claim — the entries Part 6 (Risk Map) records as the project's current level on each H/M dimension.
Judging where a project actually stands on a dimension takes two distinct capabilities, and both can fail independently:
An actual-state claim is only trustworthy if both are adequate. A perfect instrument with no oracle means you can see plenty and still not know if "plenty" is good enough; a perfect oracle with no instrument means you know what "good" looks like but have nothing observed to compare it to.
This skill exists because of two reliable agent failure modes. (1) When "how do we know?" is collapsed into "is it good?", agents claim an actual level (often a comfortable Medium) by deferring to whatever signal happens to exist, never asking whether that signal can actually judge this dimension — so the risk map records confidence the evidence doesn't support. (2) When there's no obvious oracle, agents mark the dimension Unknown and move on as if Unknown were a dead end. But an oracle is usually cheap to build now, and building one turns the Unknown into a knowable actual.
This skill is part of the quality-strategy plugin. Before anything else, resolve two absolute paths and use them throughout:
${CLAUDE_PLUGIN_ROOT} (Claude Code expands this to an absolute path when it loads this file; read it off and note it down). The grounding files this skill reads — PHILOSOPHY.md, and skills/tooling-adequacy/SKILL.md for the shared oracle taxonomy — live under it.$PROJECT_DIR/quality/.File references below use the $PLUGIN_ROOT and $PROJECT_DIR placeholders. Substitute the resolved absolute paths before you act on them. The Read tool does no variable expansion and resolves relative paths against the current working directory, not this skill's directory — so an unsubstituted placeholder or a bare relative path will fail.
/quality-strategy — invoked during the risk-map actual-state pass (sub-step 6.2), after required levels (6.1) and before gap-and-confidence (6.3). Input: the H/M dimensions with their proposed actual levels (or Unknowns) and the evidence each is based on. Output: an oracle-adequacy assessment plus a list of oracle-build items that seed Step 7's plan of work and that 6.3 records against the affected dimensions.$PROJECT_DIR/quality/strategy.md (Parts 5–6), plus what the team can observe about the codebase.This skill judges adequacy and names the gaps; it does not plan the build. /tooling-strategy consumes its oracle-build items (together with /tooling-adequacy's, from the test side) and turns them into a prioritised build plan.
$PLUGIN_ROOT/PHILOSOPHY.md. The disciplines that recur — make confidence visible; push back on vagueness; record assumptions; understand the why — are load-bearing here.$PLUGIN_ROOT/skills/tooling-adequacy/SKILL.md. The oracle kinds (Specified / Property-or-metamorphic / Differential-or-simulated / Golden-master / Human-or-agent-judge) and the "kill the old-world reflex" move are the canonical oracle core; this skill applies the same taxonomy to actual-state assessment rather than to test learning needs. The one-line gists are restated in step 3 below so this file is usable on its own, but the fuller treatment lives there./quality-strategy: the H/M dimensions from Part 5 with the proposed actuals and evidence from sub-step 6.2. Standalone: read Parts 5 and 6 of $PROJECT_DIR/quality/strategy.md, and ask the user what they can observe if the doc is thin./tooling-adequacy, reading source is allowed here — actual-state assessment is about the system as built, not about preserving an independent testing perspective. But read only enough to judge whether an oracle is feasible; this skill assesses the means of knowing, not the actual state itself (that's 6.2's job).For each H/M dimension (standalone: each dimension with a claimed actual), state the two things the actual-state claim rests on:
For dimensions marked Unknown in 6.2, the instrument and oracle are what would be needed to resolve the Unknown. The "to resolve" note in 6.2 is the starting hypothesis; this skill pressure-tests whether that resolution path actually has an oracle.
Classify the oracle on the same scale. The oracle is whatever lets you decide an observation means the claimed level. The kinds, from cheapest signal to richest (the canonical treatment is in $PLUGIN_ROOT/skills/tooling-adequacy/SKILL.md step 3):
Kill the old-world reflex. "There's no oracle for this dimension, so its actual is just Unknown and there's nothing to do" mixes up two different things: an Unknown that is gated on an oracle that doesn't exist yet, and an Unknown that is cheap to resolve once you decide how to judge it. When the oracle is Missing or Inadequate, the default move is to propose building one — most often a property statement or a simulated/reference oracle — as an oracle-build item, not to leave the dimension permanently Unknown.
For each dimension, give a verdict:
Oracle-build items (state the property set; write a reference/simulated oracle; capture the golden master; define the SLO and its measurement) are first-class outputs — often the highest-value work an early-stage strategy can name, because they turn permanently-Unknown dimensions into knowable ones.
/quality-strategy) the verdicts and oracle-build items are returned to the orchestrator so sub-step 6.2/6.3 can adjust confidences and Step 7 can absorb the build items, and a scratch file is written (see Output).When run from /quality-strategy, return the assessment to the orchestrator and write it to $PROJECT_DIR/quality/.scratch/6.2-oracle-adequacy.md (the sealed-dispatch scratch file the review skill audits — see /quality-strategy SKILL.md, "Sealed-context dispatch and scratch files"). Standalone, surface it in the conversation and offer to write it to $PROJECT_DIR/quality/oracle-adequacy-<YYYY-MM-DD>.md. Shape:
# Oracle adequacy — actual-state assessment
*Do we actually know where we stand on each dimension — and would we know if a claim were wrong?*
| Dimension | Instrument (observe state) | Oracle (judge level) | Verdict | Oracle-build items |
|---|---|---|---|---|
| … | … — Adequate/Inadequate/Missing | … — Adequate/Inadequate/Missing | Trustworthy / Over-confident / Gated | … |
## Oracle-build items (seed plan of work)
- **<oracle to build>** — unblocks the actual-state assessment of <dimension(s)>. <Note if it's a property set, a simulated/reference oracle, a golden master, or a defined SLO + measurement.>
(Or: "None — every assessed dimension has an adequate instrument and oracle, with the per-dimension reasons above.")
Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub tollens-ai/quality-strategy-skills --plugin quality-strategy