agentleFS
cloudnative-cocloudnative-co/claude-code-starter-kit/skills/tdd-workflow/SKILL.md

tdd-workflow

Skill153 starsChanged 8 months agoMITView on GitHub

Use this skill when the user explicitly asks for TDD or a tests-first workflow, or when developing a new feature with a test coverage requirement. Provides a structured red-green-refactor workflow with unit, integration, and E2E test guidance.

128 other projects use a version of this, 57 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use brand-discovery, configure-ecc and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • ysyecustSkill

    brand-discovery

    Use when a brand needs to discover or articulate its identity through structured multi-session interviews. Covers purpose, positioning, audience, personality, voice, narrative, and founder-brand tension across 8 modules using laddering, 5 Whys, and projective techniques. Produces a resumable session with disk-persisted state and a master brandbook (90_SYNTHESIS.md).

    Also in 6 projects that use this

  • royaluniondesign-sysSkill

    configure-ecc

    Interactive installer for Everything Claude Code — guides users through selecting and installing skills and rules to user-level or project-level directories, verifies paths, and optionally optimizes installed files.

    Also in 12 projects that use this

  • junimnjwSkill

    ralphinho-rfc-pipeline

    RFC-driven multi-agent DAG execution pattern with quality gates, merge queues, and work unit orchestration.

    Also in 12 projects that use this

  • loulanyueSkill

    nuxt4-patterns

    Nuxt 4 app patterns for hydration safety, performance, route rules, lazy loading, and SSR-safe data fetching with useFetch and useAsyncData.

    Also in 10 projects that use this

  • royaluniondesign-sysSkill

    content-hash-cache-pattern

    Cache expensive file processing results using SHA-256 content hashes — path-independent, auto-invalidating, with service layer separation.

    Also in 16 projects that use this

  • RojiosSkill

    dart-flutter-patterns

    Production-ready Dart and Flutter patterns covering null safety, immutable state, async composition, widget architecture, popular state management frameworks (BLoC, Riverpod, Provider), GoRouter navigation, Dio networking, Freezed code generation, and clean architecture.

    Also in 7 projects that use this

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 117 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use the project's test runner.

    line 53
  2. Distinctive:

    Write minimal code to make tests pass.

    line 62
  3. Distinctive:

    Use the project's coverage tooling.

    line 79
  4. Distinctive:

    Write Tests First: - Always TDD

    line 88
  5. Distinctive:

    Test Error Paths: - Not just happy paths

    line 94
  6. Distinctive:

    Clean Up After Tests: - No side effects

    line 96
  7. Distinctive:

    All tests passing (green)

    line 102
  8. Distinctive:

    No skipped or disabled tests

    line 103

“Common” is measured: kept by at least 6 in 10 of the 117 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Test-Driven Development Workflow

This skill provides a structured TDD workflow for projects that adopt tests-first development.

When to Activate

  • The user explicitly asks for TDD or tests-first development
  • New feature work where test coverage is a stated requirement
  • Adding API endpoints or components under a coverage policy

For routine bug fixes or refactors, add focused tests for the changed behavior instead of invoking this full workflow (the /tdd command and tdd-guide agent remain available when you want it explicitly).

Core Principles

1. Tests BEFORE Code

Within this workflow, the default is to write tests first, then implement code to make tests pass.

2. Coverage Guidance

  • Coverage target follows the project's own standard (e.g., 80% as a common baseline); scale effort with the size of the change
  • Cover relevant edge cases
  • Test error scenarios
  • Verify boundary conditions

3. Test Types

Unit Tests - Individual functions, utilities, component logic, pure functions, helpers.

Integration Tests - API endpoints, database operations, service interactions, external API calls.

E2E Tests (Playwright) - Critical user flows, complete workflows, browser automation, UI interactions. Applies to web UI projects only.

TDD Workflow Steps

Step 1: Write User Journeys

As a [role], I want to [action], so that [benefit]

Example:
As a user, I want to search for markets semantically,
so that I can find relevant markets even without exact keywords.

Step 2: Generate Test Cases

For each user journey, create comprehensive test cases covering happy paths, edge cases, fallback behavior, and sorting/filtering logic.

Step 3: Run Tests (They Should Fail)

Use the project's test runner. Examples:

npm test                      # Node.js
pytest                        # Python
bash tests/run-unit-tests.sh  # shell projects
# Tests should fail - we haven't implemented yet

Step 4: Implement Code

Write minimal code to make tests pass.

Step 5: Run Tests Again

Re-run the same test command (e.g., npm test, pytest):

npm test
# Tests should now pass

Step 6: Refactor

Improve code quality while keeping tests green:

  • Remove duplication
  • Improve naming
  • Optimize performance
  • Enhance readability

Step 7: Verify Coverage

Use the project's coverage tooling. Examples:

npm run test:coverage   # Node.js
pytest --cov            # Python
# Verify coverage meets the project's target

Best Practices

  1. Write Tests First - Always TDD
  2. One Assert Per Test - Focus on single behavior
  3. Descriptive Test Names - Explain what's tested
  4. Arrange-Act-Assert - Clear test structure
  5. Mock External Dependencies - Isolate unit tests
  6. Test Edge Cases - Null, undefined, empty, large
  7. Test Error Paths - Not just happy paths
  8. Keep Tests Fast - Unit tests < 50ms each
  9. Clean Up After Tests - No side effects
  10. Review Coverage Reports - Identify gaps

Success Metrics

  • Coverage target met (per project standard, e.g., 80%)
  • All tests passing (green)
  • No skipped or disabled tests
  • Fast test execution (< 30s for unit tests)
  • E2E tests cover critical user flows
  • Tests catch bugs before production

References

These templates target JavaScript/TypeScript stacks; adapt the structure for other languages.

  • references/test-templates.md - Unit, integration, E2E, and mocking code templates (JS/TS)
  • references/testing-mistakes.md - Common pitfalls, file organization, coverage config, CI setup (JS/TS)

Remember: Give changed behavior a focused test. Tests are the safety net that enables confident refactoring, rapid development, and production reliability.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.