spec-writing

From README

Spec Writing What Makes Good Acceptance Criteria Each criterion is a single, testable statement. It describes one observable behavior in one sentence. Good: Bad: The test: Can a developer write a test from this criterion without asking clarifying questions? If yes, it's good. If no, it needs more detail. Rules for Good ACs One behavior per AC. If you wrote "and" in the middle, split it into two. Observable outcome. Someone can look at the screen or the API response and verify it. No implementation details. Say "Shows error when email is taken", not "Returns 409 Conflict with JSON error body." Include error cases explicitly. "Shows error when..." ACs are first-class, not afterthoughts. No vague qualifiers. Never use "correctly", "properly", "well", "appropriate" without defining what that means. Code in Specs Small indicative code is fine when it clarifies intent: Use code to show contracts and shapes. Never use code to show logic — that's the TDD planner's job.