agent-skills/skills/audit-requirements-quality/SKILL.md

name, description

name	description
audit-requirements-quality	Use when reviewing a specification, PRD, or requirements document for completeness, clarity, consistency, measurability, traceability, and scenario coverage without testing implementation behavior.

Audit Requirements Quality

Create “unit tests for English.” The checklist asks whether the requirements are written well enough to build and test. It never asks whether the product currently behaves correctly.

The decisive distinction

Bad item — implementation test:

- [ ] Verify the page displays three featured cards.

Good item — requirements-quality test:

- [ ] CHK001 Are the number, ordering, and selection rules for featured cards explicitly specified? [Completeness, Spec §FR-004]

The bad item belongs in a test plan. The good item can fail while no code exists, because it evaluates the words.

1. Choose audit depth and focus

Read the authoritative requirements and any linked plan or principles needed to interpret them. State the requested focus, such as security, API, accessibility, migration, performance, or general readiness.

Use one of three depths:

• light: 10–15 highest-risk items;
• standard: 20–30 items across all applicable dimensions;
• deep: up to 40 items, including cross-section consistency and exception coverage.

Use a soft cap of 40. Merge near-duplicates and consolidate low-impact edge cases rather than producing checkbox noise.

2. Inventory the requirement surfaces

Collect stable requirement IDs, user journeys, acceptance criteria, success criteria, assumptions, dependencies, entities, and explicit exclusions. If IDs do not exist, cite headings and flag traceability as a gap.

Classify scenarios:

• primary;
• alternate;
• exception/error;
• recovery/rollback;
• non-functional;
• boundary and empty state.

Do not infer that an implementation probably handles a missing scenario. Absence in the requirements is the finding.

3. Generate quality questions

Group items under applicable dimensions:

• Requirement Completeness
• Requirement Clarity
• Requirement Consistency
• Acceptance Criteria Quality
• Scenario Coverage
• Edge Case Coverage
• Non-Functional Requirements
• Dependencies and Assumptions
• Ambiguities and Conflicts
• Traceability

Use these forms:

- [ ] CHK001 Are failure outcomes defined for every external dependency? [Completeness, Gap]
- [ ] CHK002 Is “fast” quantified from the user’s perspective? [Clarity, Spec §NFR-002]
- [ ] CHK003 Are retention obligations consistent between FR-008 and the privacy section? [Consistency, Spec §FR-008]
- [ ] CHK004 Can the success threshold in SC-003 be measured objectively? [Measurability, Spec §SC-003]
- [ ] CHK005 Are rollback requirements defined for interruption after partial migration? [Coverage, Gap]

At least 80% of items must contain a direct section/ID reference or one of [Gap], [Ambiguity], [Conflict], [Assumption], or [Dependency].

4. Cover domain-relevant failure classes

Ask whether requirements exist and are precise for:

• actor permissions and ownership boundaries;
• empty, loading, stale, duplicate, and partial data;
• invalid input and dependency failures;
• concurrency, conflict resolution, retries, and idempotency;
• security failures, abuse limits, and sensitive-data handling;
• accessibility and localization;
• capacity, latency, degradation, and recovery targets;
• deletion, retention, rollback, and irreversible operations;
• compatibility, versioning, and migration.

Only include a class when it could plausibly affect the feature. A generic security checklist pasted onto a static copy edit is not a quality audit.

5. Apply the wording gate

Reject any item that:

• starts with “Verify,” “Test,” “Confirm,” or “Check” and then describes product behavior;
• tells a user to click, navigate, render, execute, or load something;
• says “works correctly,” “functions as expected,” or “displays properly”;
• names code, framework internals, algorithms, or test procedures;
• merely restates a requirement as a behavior assertion.

Require items to ask one of:

• Are requirements for X defined/documented?
• Is vague term X quantified or clarified?
• Are A and B consistent?
• Can criterion X be objectively measured?
• Are scenarios or edge cases X covered?
• Does the document define missing aspect X?

6. Write a reviewer-owned artifact

Use globally increasing IDs and leave new items unchecked:

# <Focus> Requirements Checklist: <Feature>

**Purpose:** Evaluate the quality of written requirements for <focus>.
**Source:** <document path or link>

**Marker semantics:** `[x]` means a reviewer found the requirements-quality criterion satisfied. It does not mean implementation is complete.

## Requirement Clarity

- [ ] CHK001 ...

## Notes

- Record the requirement edit or decision beside any resolved item.

When appending to an existing checklist, continue from its maximum ID. Never delete, renumber, mark as passed, or overwrite reviewer-owned items during generation.

7. Self-audit the audit

Before handoff:

• every item tests prose quality, not runtime behavior;
• categories reflect actual feature risk;
• scenario classes are represented or intentionally excluded;
• near-duplicates are merged;
• at least 80% of items are traceable;
• each item contains one answerable quality proposition;
• new markers remain unchecked;
• the list is within the selected depth cap.

Report item count, focus, depth, source documents, and the most material uncovered requirement areas. Do not claim the underlying requirements pass until a reviewer evaluates the checklist.