tdd
Test-Driven Development
Philosophy
Core principle: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.
Good tests are integration-style: they exercise real code paths through public APIs. They describe what the system does, not how it does it. A good test reads like a specification - "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.
Bad tests are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.
See tests.md for examples and mocking.md for mocking guidelines.
Anti-Pattern: Horizontal Slices
DO NOT write all tests first, then all implementation. This is "horizontal slicing" - treating RED as "write all tests" and GREEN as "write all code."
This produces crap tests:
More from maxmurr/agents-skills
submit-pr
Submit implementation as a pull request. Runs tests, creates a PR with the Linear issue linked, and posts the PR URL as a comment on the Linear issue. Use when implementation is complete and user wants to open a PR, submit work, or create a pull request.
2index-knowledge
Generate hierarchical AGENTS.md + CLAUDE.md knowledge base for a codebase. Creates root + complexity-scored subdirectory documentation with both file types.
2atdd
Outside-in TDD with double-loop (acceptance + unit). Use when user wants acceptance-test-driven development, outside-in TDD, London-school TDD, GOOS-style development, or wants to drive design from user-facing behavior inward.
1prd-to-issues
Break a PRD into independently-grabbable Linear issues using tracer-bullet vertical slices. Use when user wants to convert a PRD to issues, create implementation tickets, or break down a PRD into work items.
1write-a-prd
Create a PRD through user interview, codebase exploration, and module design, then submit as a Linear issue. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.
1start-issue
Kick off implementation of a Linear issue. Fetches the issue and its parent PRD, creates a git branch using Linear's suggested branch name, and presents a consolidated context summary ready for development. Use when starting work on a Linear issue, picking up a ticket, or when user says "start issue TEAM-123", "work on TEAM-123", or "pick up TEAM-123".
1