Problem
Agents writing test scenarios frequently violate the functional requirements rules defined in ai/rules/requirements.mdc. The tdd.mdc rule instructs agents to write given/should strings that "clearly state the functional requirements from an acceptance perspective", but without an explicit pointer to requirements.mdc, agents lack the context needed to correctly frame those requirements.
This creates a common pain point: test given/should descriptions end up describing literal values or implementation details instead of user-facing jobs-to-be-done, violating both the TDD and requirements rules simultaneously.
Root Cause
tdd.mdc references the assert type contract:
type assert = ({ given: string, should: string, actual: any, expected: any }) {
`given` and `should` must clearly state the functional requirements from an acceptance perspective…
}
However, it does not explicitly reference requirements.mdc, which defines the canonical form for functional requirements:
type FunctionalRequirement = "Given $situation, should $jobToDo"
Agents therefore miss the constraint that requirement language must focus on the user journey and the job to be done, not on specific values, UI interactions, or implementation details.
Proposed Fix
Add an explicit cross-reference to ai/rules/requirements.mdc inside tdd.mdc — ideally in the assert section where given/should are defined — so agents loading the TDD rule are directed to also load and follow the requirements rule when composing test scenario descriptions.
Example addition (approximate placement):
## assert
> See also: `ai/rules/requirements.mdc` — functional requirement format and constraints.
type assert = ({ given: string, should: string, actual: any, expected: any }) {
`given` and `should` must clearly state the functional requirements from an acceptance perspective…
Expected Outcome
- Agents authoring test scenarios consistently apply the
FunctionalRequirement format ("Given $situation, should $jobToDo").
given/should strings describe user-facing behavior, not literal values or implementation details.
- Fewer review cycles needed to correct poorly framed test assertions.
Files Affected
ai/rules/tdd.mdc (source of truth, synced to .cursor/rules/tdd.mdc)
ai/rules/requirements.mdc (no changes needed — only a reference to it)
Labels
bug, dx, agent-quality
Problem
Agents writing test scenarios frequently violate the functional requirements rules defined in
ai/rules/requirements.mdc. Thetdd.mdcrule instructs agents to writegiven/shouldstrings that "clearly state the functional requirements from an acceptance perspective", but without an explicit pointer torequirements.mdc, agents lack the context needed to correctly frame those requirements.This creates a common pain point: test
given/shoulddescriptions end up describing literal values or implementation details instead of user-facing jobs-to-be-done, violating both the TDD and requirements rules simultaneously.Root Cause
tdd.mdcreferences theasserttype contract:However, it does not explicitly reference
requirements.mdc, which defines the canonical form for functional requirements:Agents therefore miss the constraint that requirement language must focus on the user journey and the job to be done, not on specific values, UI interactions, or implementation details.
Proposed Fix
Add an explicit cross-reference to
ai/rules/requirements.mdcinsidetdd.mdc— ideally in theassertsection wheregiven/shouldare defined — so agents loading the TDD rule are directed to also load and follow the requirements rule when composing test scenario descriptions.Example addition (approximate placement):
Expected Outcome
FunctionalRequirementformat ("Given $situation, should $jobToDo").given/shouldstrings describe user-facing behavior, not literal values or implementation details.Files Affected
ai/rules/tdd.mdc(source of truth, synced to.cursor/rules/tdd.mdc)ai/rules/requirements.mdc(no changes needed — only a reference to it)Labels
bug,dx,agent-quality