tdd
Use when the user invokes TDD discipline, says "write test first", "test-driven", "/tdd". Strict red-green-refactor. Refuses to write production code before a failing test exists.
What this skill does
# tdd Strict TDD. Test first, fail first, then code, then refactor. Non-negotiable order. ## Method For each unit of behaviour: 1. **Red.** Write **one** test that asserts the desired behaviour. Run it. **It must fail** — verify the failure mode is the absent behaviour, not a syntax error or wrong import. 2. **Green.** Write the **simplest** code that makes the test pass. Hardcoded values are fine if the test only asserts one input. Run all tests. All green. 3. **Refactor.** With all tests green, improve structure. Extract, rename, dedup. Run tests after every change — must stay green. 4. **Next.** New test that triggers a generalisation. Repeat. ## Rules — non-negotiable - **No production code without a failing test.** If you find yourself writing code and there's no failing test for it, stop, write the test. - **Test must have actually failed.** If you wrote a test and it passed immediately, you wrote the wrong test or the code was already there. Diagnose; don't claim done. - **Tests are first-class.** Bad test names, no assertions, mocking the thing under test = same as no test. - **Refactor only when green.** Never refactor on a failing test (you lose your ground truth). - **One test at a time.** Don't write three tests then implement all three. ## Output shape per cycle ``` Cycle N Behaviour: <one sentence> Red: <test path>:<line> ← failed with: <quoted error> Green: <smallest change to make it pass> Tests: M passing Refactor: <what changed> | tests: M passing ``` ## Anti-patterns - Writing the production code "in your head" before the test (cheating) - Test that asserts implementation detail (e.g. private method called) instead of behaviour - Big-bang test that asserts 5 behaviours — split it - Refactoring during red (you have no safety net) - Skipping refactor because "it works" (debt accumulates fast) ## When NOT to use - Spike / exploration code (use `/siftcoder:dream` or scratch) - Pure config / data file changes - Generated code (e.g. graphql codegen) — test the inputs, not the output ## Subagent dispatch - `tester` agent (if installed) — knows behaviour-coverage gates, not just line coverage - `Plan` to break a feature into TDD-shaped units of behaviour before starting ## Memory capture Each red-green-refactor cycle is a captured event. Future "how do we test X" queries surface prior TDD cycles in the same module. ## Value over native CC CC will write tests if asked. CC won't refuse to write code first if you ask it for code first. This skill enforces the order. The discipline IS the value.
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.