Requirement quality rules for coding tasks with traceable MUST/SHOULD and verifiable acceptance criteria.
<when_to_use>
Defining or validating coding task requirements before implementation
Need to enforce definition of done and scope boundaries
Need requirement-to-evidence traceability in reviews
</when_to_use>
<normative_language>
MUST indicates absolute requirement
SHOULD indicates strong recommendation with documented exception
MAY indicates optional behavior
</normative_language>
<input_requirements>
Task objective and in-scope boundaries
Acceptance criteria with pass/fail expectations
Quality gates (tests/lint/typecheck/security/perf as relevant)
Constraints (security, compatibility, rollout, tooling)
Out-of-scope and future work notes
</input_requirements>
<requirement_categories>
Scope and intent
Functional acceptance criteria
Definition of done gates
Constraints and guardrails
Non-functional requirements
Verification evidence
</requirement_categories>
<writing_templates>
</writing_templates>
<quality_rules>
Every requirement is singular, unambiguous, and testable
Every AC maps to direct evidence in code/tests/behavior
Out-of-scope changes are flagged explicitly
NFRs are measurable when they affect release decisions
</quality_rules>
Requirements use explicit MUST/SHOULD/MAY intent
Each REQ has verification method and evidence target
AC coverage is complete and traceable
DoD gates are declared before implementation starts
Exceptions include rationale, owner, and expiration
<do_not>
Do not accept vague language like "improve" without metric
Do not mix requirement and implementation preference without reason
Do not mark done without traceability matrix
</do_not>
<output_requirements>
Requirement table with REQ-ID, type, verification, evidence
AC coverage matrix and uncovered gaps
List of approved exceptions and compensating controls
</output_requirements>
