tdd-workflow
Skill3 starsChanged 10 days agoMITView on GitHub
Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests.
128 other projects use a version of this, 71 of them edited.
Adopted by
Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Most recently taken up by
- Rojios/everything-claude-codeedited, first seen Nov 8, 2026
- lhbsaa/apex-unifiededited, first seen Nov 8, 2026
- ahmadvahidi/skill-atlasedited, first seen Nov 8, 2026
- mahsumaktas/agent-evolution-kittheir own version, first seen Nov 8, 2026
- ControllableModel/SWE-Skills-Benchedited, first seen Nov 8, 2026
- LuisSambrano/antigravity-configtheir own version, first seen Nov 8, 2026
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.
ysyecustSkillbrand-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-sysSkillconfigure-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
junimnjwSkillralphinho-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
loulanyueSkillnuxt4-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-sysSkillcontent-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
RojiosSkilldart-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
Other versions128 projects use a version of this.
Word for word · 3
- affaan-m/ECC★ 246k100% same
- ysyecust/everything-claude-code★ 44100% same
- siva323388/claudeCode★ 0100% same
Edited · 71
- xu-xiang/everything-claude-code-zh★ 1.9k36% same
- loulanyue/awesome-claude-notes★ 27293% same
- cloudnative-co/claude-code-starter-kit★ 15339% same
- cohen-liel/hivemind★ 10893% same
- tpavanipradeep/everything-claude-code★ 10493% same
- mturac/everything-openai-codex★ 8996% same
- mit-network/everything-claude-code★ 7695% same
- Fmarzochi/EGC★ 6162% same
- myths-labs/muse★ 3894% same
- j7-dev/everything-github-copilot★ 1993% same
61 more not listed
Wrote their own version · 54
- vudovn/ag-kit★ 8.2ksame name
- vudovn/antigravity-kit★ 8.2ksame name
- ab604/claude-code-r-skills★ 202same name
- xenitV1/Antigravity-Workflows★ 130same name
- travisjneuman/.claude★ 106same name
- MRCalderon3D/everything-game-dev-code★ 105same name
- drvoss/everything-copilot-cli★ 48same name
- talayash/agentrium★ 48same name
- wolverin0/claude-skills★ 41same name
- johnqtcg/awesome-skills★ 30same name
44 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository72 other files it gives its agents.
- workflow/AGENTS.mdAGENTS.md
- docs/llms.txtllms.txt
- llms.txtllms.txt
- ai-video-prompt-engineerSkill
- api-contract-designSkill
- api-hardeningSkill
- brainstormingSkill
- cavecrewSkill
- caveman-commitSkill
- caveman-compressSkill
- caveman-helpSkill
- caveman-reviewSkill
- cavemanSkill
- councilSkill
- database-migrationsSkill
- deep-researchSkill
- dependency-auditSkill
- deployment-patternsSkill
- e2e-testingSkill
- error-handlingSkill
- exa-searchSkill
- finishing-a-development-branchSkill
- frontend-securitySkill
- github-opsSkill
- graphifySkill
- graphyloop-wavesSkill
- graphyloop-workflowSkill
- gsap-coreSkill
- gsap-frameworksSkill
- gsap-performanceSkill
- gsap-pluginsSkill
- gsap-reactSkill
- gsap-scrolltriggerSkill
- gsap-timelineSkill
- gsap-utilsSkill
- high-end-visual-designSkill
- image-to-codeSkill
- last30daysSkill
- minimalist-uiSkill
- postgres-patternsSkill
- prisma-patternsSkill
- receiving-code-reviewSkill
- redesign-existing-projectsSkill
- remotion-video-creationSkill
- requesting-code-reviewSkill
- search-firstSkill
- secrets-hygieneSkill
- security-reviewSkill
- security-scanSkill
- short-video-productionSkill
- story-engineeringSkill
- supabase-setupSkill
- swarm-memorySkill
- systematic-debuggingSkill
- terminal-opsSkill
- threejs-animationSkill
- threejs-fundamentalsSkill
- threejs-geometrySkill
- threejs-interactionSkill
- threejs-lightingSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
10 rules. 0 are common, 8 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 114 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
ALWAYS write tests first, then implement code to make tests pass.
- Distinctive: line 25
All edge cases covered
- Very specific: line 53
Do not assume npm test. The commands in the steps and examples below use <test>, <test-watch>, and <coverage> as placeholders for the …
- Distinctive: line 118
Write minimal code to make tests pass:
- Very specific: line 177
When the project uses Bun's built-in runner (see Step 0), import from bun:test and run with bun test — not bun run test.
- Distinctive: line 444
Write Tests First: - Always TDD
- Distinctive: line 450
Test Error Paths: - Not just happy paths
- Distinctive: line 452
Clean Up After Tests: - No side effects
- Distinctive: line 458
All tests passing (green)
- Distinctive: line 459
No skipped or disabled tests
“Common” is measured: kept by at least 6 in 10 of the 114 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.
Files
Test-Driven Development Workflow
This skill ensures all code development follows TDD principles with comprehensive test coverage.
When to Activate
- Writing new features or functionality
- Fixing bugs or issues
- Refactoring existing code
- Adding API endpoints
- Creating new components
Core Principles
1. Tests BEFORE Code
ALWAYS write tests first, then implement code to make tests pass.
2. Coverage Requirements
- Minimum 80% coverage (unit + integration + E2E)
- All edge cases covered
- Error scenarios tested
- Boundary conditions verified
3. Test Types
Unit Tests
- Individual functions and utilities
- Component logic
- Pure functions
- Helpers and utilities
Integration Tests
- API endpoints
- Database operations
- Service interactions
- External API calls
E2E Tests (Playwright)
- Critical user flows
- Complete workflows
- Browser automation
- UI interactions
TDD Workflow Steps
Step 0: Detect the Test Runner
Do not assume npm test. The commands in the steps and examples below use <test>, <test-watch>, and <coverage> as placeholders for the project's actual runner. Resolve them once before starting:
Run the package-manager detector (ships with ECC):
node scripts/setup-package-manager.js --detectIt resolves the package manager (npm / pnpm / yarn / bun) from, in order:
CLAUDE_PACKAGE_MANAGER,.claude/package-manager.json, thepackage.jsonpackageManagerfield, the lockfile, then global config.- Distinguish the package manager from the test runner — they are not the same. A project can use Bun to install dependencies yet still run Jest or Vitest. Inspect
package.jsonscripts.testand the test files:scripts.testinvokesjest/vitest-> run through the detected PM (npm test,pnpm test,yarn test, orbun run test).scripts.testisbun test, or test filesimport { test, expect } from "bun:test", or there is no jest/vitest config but Bun is present -> use Bun's native runner (bun test). See Bun Native Test Pattern below.
Runner command matrix:
| Runner | <test> | <test-watch> | <coverage> | <lint> |
| npm | npm test | npm test -- --watch | npm run test:coverage | npm run lint |
| pnpm | pnpm test | pnpm test --watch | pnpm test:coverage | pnpm lint |
| yarn | yarn test | yarn test --watch | yarn test:coverage | yarn lint |
| Bun (script runs jest/vitest) | bun run test | bun run test --watch | bun run test:coverage | bun run lint |
Bun (native bun:test) | bun test | bun test --watch | bun test --coverage | bun run lint |
bun test(Bun's built-in runner) is not the same asbun run test(which runs thepackage.jsontestscript). Picking the wrong one is a common failure — e.g. invoking Jest throughnpx/bun runin an ESM-only project breaks, whilebun testruns the suite natively. Confirm which the project expects before the RED gate, then substitute<test>/<coverage>everywherenpm testappears below.
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:
describe('Semantic Search', () => {
it('returns relevant markets for query', async () => {
// Test implementation
})
it('handles empty query gracefully', async () => {
// Test edge case
})
it('falls back to substring search when Redis unavailable', async () => {
// Test fallback behavior
})
it('sorts results by similarity score', async () => {
// Test sorting logic
})
})Step 3: Run Tests (They Should Fail)
<test>
# Tests should fail - we haven't implemented yetStep 4: Implement Code
Write minimal code to make tests pass:
// Implementation guided by tests
export async function searchMarkets(query: string) {
// Implementation here
}Step 5: Run Tests Again
<test>
# Tests should now passStep 6: Refactor
Improve code quality while keeping tests green:
- Remove duplication
- Improve naming
- Optimize performance
- Enhance readability
Step 7: Verify Coverage
<coverage>
# Verify 80%+ coverage achievedTesting Patterns
Unit Test Pattern (Jest/Vitest)
import { render, screen, fireEvent } from '@testing-library/react'
import { Button } from './Button'
describe('Button Component', () => {
it('renders with correct text', () => {
render(<Button>Click me</Button>)
expect(screen.getByText('Click me')).toBeInTheDocument()
})
it('calls onClick when clicked', () => {
const handleClick = jest.fn()
render(<Button onClick={handleClick}>Click</Button>)
fireEvent.click(screen.getByRole('button'))
expect(handleClick).toHaveBeenCalledTimes(1)
})
it('is disabled when disabled prop is true', () => {
render(<Button disabled>Click</Button>)
expect(screen.getByRole('button')).toBeDisabled()
})
})Bun Native Test Pattern (bun:test)
When the project uses Bun's built-in runner (see Step 0), import from bun:test and run with bun test — not bun run test. The API is Jest-like, so describe / it / expect and most matchers carry over. See the bun-runtime skill for runtime, install, and bundler details.
import { describe, it, expect, mock } from 'bun:test'
import { searchMarkets } from './search'
describe('searchMarkets', () => {
it('returns an empty list for an empty query', async () => {
expect(await searchMarkets('')).toEqual([])
})
it('sorts results by similarity score', async () => {
const results = await searchMarkets('election')
expect(results).toEqual([...results].sort((a, b) => b.score - a.score))
})
})bun test # run once (RED/GREEN gate)
bun test --watch # watch mode during development
bun test --coverage # coverage report- Mock modules with
mock.module(...)/mock(...)frombun:testinstead ofjest.mock(...). - Configure coverage thresholds in
bunfig.tomlunder[test](e.g.coverageThreshold) rather than the JestcoverageThresholdsconfig block.
API Integration Test Pattern
import { NextRequest } from 'next/server'
import { GET } from './route'
describe('GET /api/markets', () => {
it('returns markets successfully', async () => {
const request = new NextRequest('http://localhost/api/markets')
const response = await GET(request)
const data = await response.json()
expect(response.status).toBe(200)
expect(data.success).toBe(true)
expect(Array.isArray(data.data)).toBe(true)
})
it('validates query parameters', async () => {
const request = new NextRequest('http://localhost/api/markets?limit=invalid')
const response = await GET(request)
expect(response.status).toBe(400)
})
it('handles database errors gracefully', async () => {
// Mock database failure
const request = new NextRequest('http://localhost/api/markets')
// Test error handling
})
})E2E Test Pattern (Playwright)
import { test, expect } from '@playwright/test'
test('user can search and filter markets', async ({ page }) => {
// Navigate to markets page
await page.goto('/')
await page.click('a[href="/markets"]')
// Verify page loaded
await expect(page.locator('h1')).toContainText('Markets')
// Search for markets
await page.fill('input[placeholder="Search markets"]', 'election')
// Wait for debounce and results
await page.waitForTimeout(600)
// Verify search results displayed
const results = page.locator('[data-testid="market-card"]')
await expect(results).toHaveCount(5, { timeout: 5000 })
// Verify results contain search term
const firstResult = results.first()
await expect(firstResult).toContainText('election', { ignoreCase: true })
// Filter by status
await page.click('button:has-text("Active")')
// Verify filtered results
await expect(results).toHaveCount(3)
})
test('user can create a new market', async ({ page }) => {
// Login first
await page.goto('/creator-dashboard')
// Fill market creation form
await page.fill('input[name="name"]', 'Test Market')
await page.fill('textarea[name="description"]', 'Test description')
await page.fill('input[name="endDate"]', '2025-12-31')
// Submit form
await page.click('button[type="submit"]')
// Verify success message
await expect(page.locator('text=Market created successfully')).toBeVisible()
// Verify redirect to market page
await expect(page).toHaveURL(/\/markets\/test-market/)
})Test File Organization
src/
├── components/
│ ├── Button/
│ │ ├── Button.tsx
│ │ ├── Button.test.tsx # Unit tests
│ │ └── Button.stories.tsx # Storybook
│ └── MarketCard/
│ ├── MarketCard.tsx
│ └── MarketCard.test.tsx
├── app/
│ └── api/
│ └── markets/
│ ├── route.ts
│ └── route.test.ts # Integration tests
└── e2e/
├── markets.spec.ts # E2E tests
├── trading.spec.ts
└── auth.spec.tsMocking External Services
Supabase Mock
jest.mock('@/lib/supabase', () => ({
supabase: {
from: jest.fn(() => ({
select: jest.fn(() => ({
eq: jest.fn(() => Promise.resolve({
data: [{ id: 1, name: 'Test Market' }],
error: null
}))
}))
}))
}
}))Redis Mock
jest.mock('@/lib/redis', () => ({
searchMarketsByVector: jest.fn(() => Promise.resolve([
{ slug: 'test-market', similarity_score: 0.95 }
])),
checkRedisHealth: jest.fn(() => Promise.resolve({ connected: true }))
}))OpenAI Mock
jest.mock('@/lib/openai', () => ({
generateEmbedding: jest.fn(() => Promise.resolve(
new Array(1536).fill(0.1) // Mock 1536-dim embedding
))
}))Test Coverage Verification
Run Coverage Report
<coverage>Coverage Thresholds
{
"jest": {
"coverageThresholds": {
"global": {
"branches": 80,
"functions": 80,
"lines": 80,
"statements": 80
}
}
}
}Common Testing Mistakes to Avoid
FAIL: WRONG: Testing Implementation Details
// Don't test internal state
expect(component.state.count).toBe(5)PASS: CORRECT: Test User-Visible Behavior
// Test what users see
expect(screen.getByText('Count: 5')).toBeInTheDocument()FAIL: WRONG: Brittle Selectors
// Breaks easily
await page.click('.css-class-xyz')PASS: CORRECT: Semantic Selectors
// Resilient to changes
await page.click('button:has-text("Submit")')
await page.click('[data-testid="submit-button"]')FAIL: WRONG: No Test Isolation
// Tests depend on each other
test('creates user', () => { /* ... */ })
test('updates same user', () => { /* depends on previous test */ })PASS: CORRECT: Independent Tests
// Each test sets up its own data
test('creates user', () => {
const user = createTestUser()
// Test logic
})
test('updates user', () => {
const user = createTestUser()
// Update logic
})Continuous Testing
Watch Mode During Development
<test-watch>
# Tests run automatically on file changesPre-Commit Hook
# Runs before every commit
<test> && <lint>CI/CD Integration
# GitHub Actions
- name: Run Tests
run: <coverage>
- name: Upload Coverage
uses: codecov/codecov-action@v3Best Practices
- Write Tests First - Always TDD
- One Assert Per Test - Focus on single behavior
- Descriptive Test Names - Explain what's tested
- Arrange-Act-Assert - Clear test structure
- Mock External Dependencies - Isolate unit tests
- Test Edge Cases - Null, undefined, empty, large
- Test Error Paths - Not just happy paths
- Keep Tests Fast - Unit tests < 50ms each
- Clean Up After Tests - No side effects
- Review Coverage Reports - Identify gaps
Success Metrics
- 80%+ code coverage achieved
- 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
Remember: Tests are not optional. They are the safety net that enables confident refactoring, rapid development, and production reliability.
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
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.

