tdd
Pragmatic Test-Driven Development
Implement features using vertical tracer bullets: one test → one implementation → repeat. Tests describe WHAT the system does, not HOW it does it.
Philosophy
Good tests exercise real code paths through public interfaces. They read like specifications: "visitor is bucketed consistently across sessions" tells you exactly what capability exists. These tests survive refactors because they don't care about internals.
Bad tests mock internal collaborators, test private methods, or verify implementation details. Warning sign: test breaks when you refactor, but behavior hasn't changed.
Pragmatic mode (default): test-first for core logic and boundary contracts. Implementation-first for UI and glue code, but still write tests for complex state management. Always write tests — the question is only whether they come before or after the code.
Process
1. Discover project context
Read domain documentation relevant to the work:
More from agentivestack/skills
holistic
Zoom out to see how code, features, or plans fit into the bigger picture. Maps bounded contexts, traces cross-cutting concerns, surfaces hidden dependencies, and identifies systemic risks. Use when you're lost in details, unfamiliar with an area, or need to understand the full impact of a change.
14domain
Cook a plan against the project's domain model. Stress-tests terminology, surfaces contradictions with code, and updates CONTEXT.md, UBIQUITOUS_LANGUAGE.md, and ADRs inline as decisions crystallize. Use when planning a feature, refactoring, or any work that touches domain boundaries.
14architect
Surface architectural friction in the codebase and design better module interfaces. Uses parallel sub-agents to explore radically different interface designs. Based on "deep modules" philosophy — small interfaces hiding significant complexity. Use when code feels tangled, hard to test, or hard to navigate.
14slice
Break a spec, plan, or feature into independently-implementable vertical slices (tracer bullets). Each slice cuts through all layers end-to-end. Outputs a task list or GitHub issues. Use after /spec to plan implementation order.
13qa
Interactive QA session where you describe bugs conversationally and the agent files durable GitHub issues using the project's domain language. Explores the codebase in the background for context. Use when reporting bugs, doing QA testing, or filing issues from observations.
13spec
Interview the user to produce a feature spec (PRD), grounded in the project's domain model, context map, and ubiquitous language. Outputs a structured spec document. Use when starting a new feature, enhancement, or significant change.
13