{
  "skill_name": "common-tdd",
  "evals": [
    {
      "id": 1,
      "prompt": "Implement a function that validates email addresses.",
      "expected_output": "Follow TDD RGR loop: RED — write failing test first: test('validates valid email', () => { expect(validateEmail('user@example.com')).toBe(true); }). Verify it fails. GREEN — write minimal implementation to pass. REFACTOR — clean up. Never write production code without a prior failing test.",
      "assertions": [
        { "type": "contains", "value": "failing test" },
        { "type": "contains", "value": "RED" }
      ]
    },
    {
      "id": 2,
      "prompt": "I already wrote the implementation. Now I'll add tests to reach 80% coverage.",
      "expected_output": "Violation: No test-after — writing tests post-implementation defeats TDD. The implementation must be deleted and restarted using Red-Green-Refactor. TDD is the Iron Law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST. Tests written after implementation do not validate design — they only verify existing behavior.",
      "assertions": [
        { "type": "contains", "value": "Iron Law" },
        { "type": "contains", "value": "delete" }
      ]
    },
    {
      "id": 3,
      "prompt": "Write tests for the order service that covers the happy path and three error scenarios.",
      "expected_output": "Apply AAA structure for each test: Arrange (set up Order, mock DB and payment), Act (call createOrder()), Assert (verify result — one logical assertion per test). Mock HTTP, Time, and external APIs. Never mock fast internal services (<200ms). Minimum 80% coverage. Use test descriptions that read as behavior specs.",
      "assertions": [
        { "type": "contains", "value": "Arrange" },
        { "type": "contains", "value": "Assert" }
      ]
    }
  ],
  "should_not_trigger": [
    "Design the database schema for a blog platform",
    "Configure Nginx load balancing",
    "Explain OAuth2 authorization flows"
  ]
}
