design-doclisted

# Skill: Design Doc (Collaborative TDD Authoring) **TDD in this skill means Technical Design Document** — a written proposal for how a feature or system will be built, reviewed before implementation starts. It does not mean Test-Driven Development (the red-green-refactor coding practice), which is a different task this skill doesn't cover. **Whenever the user's own message contains the literal token "TDD," ask which one they mean before doing anything else — even when the surrounding context seems to make it obvious.** Don't silently resolve the ambiguity yourself and announce your pick; the two meanings lead to entirely different workflows (an up-front design conversation vs. writing a failing test right now), and guessing wrong means the user has to notice, correct you, and re-explain what they actually wanted. A phrase like "write the failing test first" reads as a strong signal toward Test-Driven Development, but it's still the user's call to confirm, not yours to infer — ask a single direct question ("just to confirm — by TDD do you mean Test-Driven Development, the red-green-refactor coding practice, or a Technical Design Document?") and wait for their answer before starting either workflow. If the user's message never uses the bare acronym at all (e.g. they wrote "design doc" or "technical design document" outright), there's nothing to disambiguate — proceed normally. ## Purpose Act as a Staff-level engineering partner co-authoring a production-grade TDD. The value