Tdd discipline

Skill Elmmly/genie-team/skills/tdd-discipline

Enforces test-driven development with Red-Green-Refactor cycle. Use when writing new code, implementing features, fixing bugs, or when tests are mentioned. Ensures tests are written before implementation.From its SKILL.md

Install

npx -y skills add Elmmly/genie-team --skill tdd-discipline

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.9 KB, as published. Nobody here has run it

TDD Discipline

You MUST follow strict test-first development. This is NOT optional.

The Cycle

RED → GREEN → REFACTOR → (repeat)

Phase 1: RED (Write Failing Tests)

Write ALL tests BEFORE any implementation code.

Requirements:

Tests define expected behavior from requirements/design
Use Arrange-Act-Assert (AAA) pattern
Run tests and CONFIRM they fail
Do NOT write implementation during this phase

AAA Pattern by Language:

TypeScript (Jest/Vitest):

// Arrange
const user = createTestUser({ role: 'admin' });
const request = mockRequest({ userId: user.id });

// Act
const result = await authService.validateAccess(request);

// Assert
expect(result.allowed).toBe(true);

Go:

// Arrange
user := createTestUser(t, "admin")
req := mockRequest(user.ID)

// Act
result, err := authService.ValidateAccess(req)

// Assert
require.NoError(t, err)
assert.True(t, result.Allowed)

Rust:

// Arrange
let user = create_test_user(Role::Admin);
let request = mock_request(user.id);

// Act
let result = auth_service.validate_access(&request).unwrap();

// Assert
assert!(result.allowed);

C# (xUnit):

// Arrange
var user = CreateTestUser(role: "admin");
var request = MockRequest(userId: user.Id);

// Act
var result = await _authService.ValidateAccess(request);

// Assert
Assert.True(result.Allowed);

Java (JUnit 5):

// Arrange
var user = createTestUser("admin");
var request = mockRequest(user.getId());

// Act
var result = authService.validateAccess(request);

// Assert
assertThat(result.isAllowed()).isTrue();

Swift (XCTest):

// Arrange
let user = createTestUser(role: .admin)
let request = mockRequest(userId: user.id)

// Act
let result = try await authService.validateAccess(request)

// Assert
XCTAssertTrue(result.allowed)

Kotlin (JUnit 5):

// Arrange
val user = createTestUser(role = "admin")
val request = mockRequest(userId = user.id)

// Act
val result = authService.validateAccess(request)

// Assert
assertThat(result.allowed).isTrue()

AAA Rules:

Separate phases with blank lines
One action per test
Specific assertions (not just "not null")
No conditional logic in tests

Phase 2: GREEN (Minimal Implementation)

ONLY after tests are confirmed failing:

Write minimal code to pass tests
Do NOT modify tests to make them pass
If a test is wrong, STOP and ask — never "fix" the test
Focus on green, not perfect

Phase 3: REFACTOR (Clean Up)

ONLY after all tests pass:

Improve code quality
Tests MUST stay green
If tests fail, revert and retry

Anti-Patterns to Catch

Pattern	Response
Writing implementation first	STOP — write tests first
Modifying tests to pass	STOP — fix implementation instead
Skipping the red phase	STOP — run tests, confirm failure
Complex test setup	Simplify — tests should be readable

Output Format

When implementing with TDD, structure your work:

=== PHASE 1: RED ===
Writing tests...
[test file changes]
Running tests: X failed (expected)

=== PHASE 2: GREEN ===
Writing implementation...
[implementation changes]
Running tests: X passed

=== PHASE 3: REFACTOR ===
[any cleanup]
Tests still passing: X passed