From quality-strategy
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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/quality-strategy:contradiction-checkThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill finds **internal contradictions** in a strategy document — two claims that cannot both be true, or one part that assumes something another part rules out. It is mechanical and doc-internal: it does not judge whether the strategy is *good*, only whether it is *consistent with itself*.
This skill finds internal contradictions in a strategy document — two claims that cannot both be true, or one part that assumes something another part rules out. It is mechanical and doc-internal: it does not judge whether the strategy is good, only whether it is consistent with itself.
It exists because two different failure modes need two different catches. The substantive checkpoint in /quality-strategy catches "something here feels wrong to me" — a human reading the whole step and trusting their unease. That catch misses contradictions the reader doesn't happen to feel: a Part 3 stakeholder Dealbreaker that a Part 4 non-goal quietly excludes, a Part 1 workflow that the Part 7 plan assumes is different, a dimension rated None in Part 5 that Part 6 builds a risk-map row for. These are mechanical inconsistencies — findable by systematic cross-reference, easy to miss by feel. This skill is the systematic cross-reference.
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 file this skill reads — PHILOSOPHY.md — lives 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 — both when you Read a file yourself and when you put a path into a subagent brief. The Read tool does not expand variables, and it resolves relative paths against the current working directory, not this skill's directory; a dispatched subagent inherits none of your context. So an unsubstituted placeholder or a bare relative path will fail — always pass full absolute paths.
/quality-strategy, at each step boundary — the orchestrator runs this skill as a sealed-context subagent (one that sees only its brief, not the conversation) when a step closes: after the step's sub-steps are written, before the user sees the substantive checkpoint. It checks the Parts written so far, so a contradiction this step introduces against an earlier step gets caught at the boundary, not at final review. The orchestrator folds any findings into the checkpoint it then surfaces./test-strategy — the same, on quality/test-strategy.md against quality/strategy.md (a test strategy can contradict the quality strategy it operationalises).$PLUGIN_ROOT/PHILOSOPHY.md — enough to know what the Parts mean and what kinds of claim each carries.$PROJECT_DIR/quality/strategy.md (and, for a test strategy, $PROJECT_DIR/quality/test-strategy.md). When dispatched mid-build at a step boundary, only the Parts written so far exist — that's expected; check what's present.Locate Part boundaries by their headings (## Part 1: Context, ## Part 3: Stakeholders, etc.) and the sub-section headings within them. Read everything that exists once, and build a short index of the load-bearing claims in each Part: stakeholder bars (Part 3), non-goals (Part 4), dimension ratings (Part 5), risk-map required/actual/gap (Part 6), plan-of-work actions (Part 7), and the context/workflow/release facts (Part 1–2).
Walk these systematically. For each, a contradiction is a specific pair of claims, cited by Part and quote — not a vague "these feel in tension."
These classes overlap deliberately — a single contradiction may show up under two of them. Report it once, under the clearest class.
This skill reports contradictions only. Do not report:
OPEN QUESTION: noting two stakeholders disagree) is not a contradiction; it's honest. A contradiction is an unacknowledged clash the doc presents as if both sides were settled truth.If you're unsure whether something is a contradiction or a gap, state the specific claim pair and let the orchestrator judge — but lean toward not reporting, to keep this check low-noise.
/quality-strategy-review."When dispatched from /quality-strategy (or /test-strategy) at a step boundary, return the findings to the orchestrator and write them to $PROJECT_DIR/quality/.scratch/<step-boundary>-contradiction-check.md (e.g. 3.2-contradiction-check.md — the sealed-dispatch scratch file the review skill audits; see /quality-strategy SKILL.md, "Sealed-context dispatch and scratch files"). The orchestrator folds the findings into the substantive checkpoint it surfaces next.
Phrase each finding for both readers — names before coordinates (PHILOSOPHY: write for both readers): state the two claims in plain words, with Part references trailing as pointers, so the user at the checkpoint can act on the finding without opening the doc to decode it.
Standalone, surface the findings in the conversation. Shape:
# Contradiction check — <doc name>
*Internal consistency only. Not a quality judgement.*
## Contradictions found
- **<class> — <Part X> vs <Part Y>.** "<quote A>" (Part X) cannot hold with "<quote B>" (Part Y), because <one line>. Suggested resolution: <re-do which sub-step, or which claim to change>.
(Or: "None found across the Parts present.")
If no contradictions are found, say so plainly — a clean check is a real and useful result, not a failure to look hard enough.
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