Skip to main content
tdd This skill should be used when implementing features with TDD, writing tests first, or refactoring with test coverage. Applies disciplined Red-Green-Refactor cycles with TypeScript/Bun and Rust tooling.
Ir a la instalación Skills Marketplace Descubre y explora habilidades de IA creadas por la comunidad.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Mostrar detalles del prompt Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.
npx skills add https://github.com/outfitter-dev/agents --skill tddEl comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.
¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.
Descargar Zip Descargando... Más de este repositorio gitbutler-complete-branch This skill should be used when the user asks to "complete a branch", "merge to main", "finish my feature", "ship this branch", "integrate to main", "create a PR from GitButler", or when `--complete-branch` flag is mentioned. Guides completion of GitButler virtual branches with safety snapshots, integration workflows, and cleanup.
This skill should be used when coordinating multiple AI agents working concurrently, handling agent handoffs, transferring commits between agents, or when "multi-agent", "concurrent agents", "parallel agents", "agent collaboration", or "parallel execution" are mentioned with GitButler. Provides virtual branch patterns for parallel execution without coordination overhead.
This skill should be used when creating stacks, dependent branches, or when "stack", "stacked branches", "anchor", "--anchor", "but branch new -a", "create dependent branch", or "break feature into PRs" are mentioned with GitButler. Covers anchor-based stacking for dependent features and reviewable PR breakdown.
Explorador de archivos
5 archivos Ocupaciones relacionadas SOC
Basado en la clasificación ocupacional SOC
name tdd description This skill should be used when implementing features with TDD, writing tests first, or refactoring with test coverage. Applies disciplined Red-Green-Refactor cycles with TypeScript/Bun and Rust tooling. metadata {"version":"2.1.0"}
Test-Driven Development
Write tests first, implement minimal code to pass, refactor systematically.
<when_to_use>
New features with TDD methodology
Complex business logic requiring coverage
Critical paths: auth, payments, data integrity
Bug fixes: reproduce with test, fix, verify
Refactoring: ensure behavior preservation
API design: tests define the interface
NOT for: exploratory coding, UI prototypes, static config, trivial glue code
</when_to_use>
Load the maintain-tasks skill for stage tracking. Advance through RED-GREEN-REFACTOR cycle.
Stage Trigger activeForm Red Session start / cycle restart "Writing failing test" Green Test written and failing "Implementing code" Refactor Tests passing "Refactoring code" Verify Refactor complete "Verifying implementation"
Task format:
- Write failing test for { feature }
- Implement { feature } to pass tests
- Refactor { aspect }
- Verify { what's being checked }
Start: Create "Red" stage in_progress
Transition: Mark current completed, add next in_progress
After each stage: Run tests before advancing
Multiple cycles: Return to "Red" for next feature
Good existing tests: Start at "Refactor" after confirming pass
Bug fix: Start at "Red" with failing test reproducing bug
No regression: Tests must continue passing through all stages
RED --> GREEN --> REFACTOR --> RED --> ...
| | |
Test Impl Improve
Fails Passes Quality
Each cycle: 5-15 min. Longer = step too large, decompose.
Red-Green-Refactor as primary workflow
Test quality over quantity - behavior, not implementation
Incremental progress - small focused cycles
Type safety throughout - tests as type-safe as production
Write tests defining desired behavior before implementation exists.
3-5 related tests fully specifying one feature
Type system makes invalid states unrepresentable
Each test = one specific behavior
Run tests, verify fail for right reason
Descriptive names forming sentences
import { describe, test, expect } from 'bun:test'
describe ('UserAuthentication' , () => {
test ('authenticates with valid credentials' , async () => {
const result = await authenticate ({ email : 'user@example.com' , password : 'SecurePass123!' })
expect (result).toMatchObject ({ type : 'success' , user : expect.objectContaining ({ email : 'user@example.com' }) })
})
test ('rejects invalid credentials' , async () => {
const result = await authenticate ({ email : 'wrong@example.com' , password : 'wrong' })
expect (result).toMatchObject ({ type : 'error' , code : 'INVALID_CREDENTIALS' })
})
test.todo ('implements rate limiting after failed attempts' )
})
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn authenticates_with_valid_credentials () {
let creds = Credentials { email: "user@example.com" .into (), password: "SecurePass123!" .into () };
assert! (matches!(authenticate (&creds), Ok (AuthResult::Success { .. })));
}
#[test]
fn rejects_invalid_credentials () {
let creds = Credentials { email: "wrong@example.com" .into (), password: "wrong" .into () };
assert! (matches!(authenticate (&creds), Err (AuthError::InvalidCredentials)));
}
}
Commit: test: add failing tests for [feature]
Transition: Mark "Red" completed, create "Green" in_progress
Implement minimum code to make tests pass.
Focus on passing tests, not perfect code
Explicit types where aids clarity
Straightforward solutions first
Hardcode if passes test - refactor generalizes
Run tests frequently
type AuthResult = { type : 'success' ; user : User } | { type : 'error' ; code : string }
async function authenticate (creds : { email: string ; password: string }Promise <AuthResult > {
if (!creds.password ) return { type : 'error' , code : 'MISSING_PASSWORD' }
const user = await findUserByEmail (creds.email )
if (!user) return { type : 'error' , code : 'INVALID_CREDENTIALS' }
const match = await comparePassword (creds.password , user.passwordHash )
if (!match) return { type : 'error' , code : 'INVALID_CREDENTIALS' }
return { type : 'success' , user }
}
pub fn authenticate (creds: &Credentials) -> Result <AuthResult, AuthError> {
if creds.password.is_empty () { return Err (AuthError::MissingPassword); }
let user = find_user_by_email (&creds.email).ok_or (AuthError::InvalidCredentials)?;
if !compare_password (&creds.password, &user.password_hash) {
return Err (AuthError::InvalidCredentials);
}
Ok (AuthResult::Success { user })
}
Verify: bun test / cargo test
Commit: feat: implement [feature] to pass tests
Transition: Mark "Green" completed, create "Refactor" in_progress
Enhance code quality without changing behavior. Tests must continue passing.
Extract common patterns into well-named functions
Apply SOLID principles where appropriate
Improve types: discriminated unions, branded types
No test behavior changes
Run tests after each step
function validateCredentials (creds : { email: string ; password: string }AuthResult | null {
if (!creds.password ) return { type : 'error' , code : 'MISSING_PASSWORD' }
if (!isValidEmail (creds.email )) return { type : 'error' , code : 'INVALID_EMAIL' }
return null
}
type Email = string & { readonly __brand : 'Email' }
fn validate_credentials (creds: &Credentials) -> Result <(), AuthError> {
if creds.password.is_empty () { return Err (AuthError::MissingPassword); }
if !is_valid_email (&creds.email) { return Err (AuthError::InvalidEmail); }
Ok (())
}
pub struct Email (String );
Verify: bun test / cargo test
Commit: refactor: [improvement description]
Transition: Mark "Refactor" completed, create "Verify" in_progress
Final: Run full suite. Mark "Verify" completed when all checks pass.
Follow project conventions, defaulting to:
src/{module}/{name}.ts # Implementation
src/{module}/{name}.test.ts # Unit tests colocated
src/{module}/__fixtures__/ # Test data
tests/integration/ # Integration tests
tests/e2e/ # End-to-end tests
src/{module}/mod.rs # #[cfg(test)] mod tests { ... }
tests/integration/ # Integration tests
tests/fixtures/ # Test data
Metric Target Line coverage >=80% (90% critical paths) Mutation score >=75% Unit test time <5s
Single clear assertion per test
No execution order dependencies
Descriptive names forming sentences
Behavior focus, not implementation
Setup longer than test
Multiple unrelated assertions
Coupling to implementation details
Flaky tests
Write failing test reproducing bug (Start "Red" in_progress)
Verify fails for right reason
Fix with minimal code (Transition to "Green")
Verify passes, all others still pass
Refactor if needed (Transition to "Refactor" or skip to "Verify")
Commit: fix: [bug description] with test coverage
test ('handles division by zero gracefully' , () => {
expect (divide (10 , 0 )).toMatchObject ({ type : 'error' , code : 'DIVISION_BY_ZERO' })
})
function divide (a : number , b : number Result {
if (b === 0 ) return { type : 'error' , code : 'DIVISION_BY_ZERO' }
return { type : 'success' , value : a / b }
}
Track progress with Tasks (load maintain-tasks skill)
Write tests before implementation (RED first)
Run tests after each stage
Verify tests fail for right reason in RED
Keep cycles 5-15 min max
Descriptive test names forming sentences
Test behavior, not implementation
Each test = one reason to fail
Skip to implementation without tests
Change test behavior during refactoring
Test implementation details or private methods
Allow tests to depend on execution order
Write flaky tests
Mark stage complete without running tests
Multiple unrelated assertions per test
bun test
bun test --watch
bun test --coverage
bun test --only
bun x stryker run
cargo test
cargo test --test NAME
cargo tarpaulin
cargo mutants
cargo test -- --nocapture
