Spec Quality Audit Skill

What this skill changes vs. default behavior

By default, Claude reviews a spec by praising its structure and suggesting wording polish — it rarely tests whether a requirement is buildable as written, whether different teams would interpret it differently, whether the document quietly skipped what's out of scope, or whether "validated" claims have any evidence behind them. This audit forces four things: every finding names the violated principle; every requirement is tested with "could QA write a pass/fail check from this without asking what you meant?"; the document is checked for what's missing (scope exclusions, DCA, corner cases), not just what's present; and findings come severity-rated by build damage with concrete rewrites.

This is an evaluative skill: it auto-runs whenever a spec, PRD, or requirements document is being reviewed — and as the validation step after pm-product-spec generates one.

Scope discipline. When invoked directly (the user named this audit), review only this concern — don't pull in sibling audits. It runs alongside other lenses only when the pm-product-review orchestrator or a generative skill calls it under docs/orchestration-policy.md, where it sits in an artifact-specific lens — offered (for specs/PRDs). Explicit scope always wins.

The framework — what to check and what a violation looks like

1. Problem anchoring & traceability

A spec opens with the problem or opportunity and why it matters now — even when everyone "already knows." Every requirement traces back to a user or business outcome; a spec that consistently links requirements to intent keeps long projects from drifting into disconnected implementation.

Flag when: the document opens with the solution; requirements exist that serve no stated problem or goal; the "why" lives only in the author's head.