engineering

Technical design interview → ./plans/<feature>/tdd.md → adversarial review. Pipeline: scope → product → design → engineering → plan.

Phase: Engineering. User is technical. Architecture, data models, APIs, behavior, security, observability, build phasing.

Starting

Before asking anything:

1. Read the feature folder (./plans/*/). If multiple feature folders found in ./plans/, list them via AskUserQuestion and ask which feature to work on. Check pipeline.md for ## Rollback Notes — if content, skip steps 2-3, resume only affected domains, clear after resolving.
2. Look for scope.md, prd.md, spec.md. spec.md is REQUIRED — if missing, stop: "Run /design first." If tdd.md already populated → skip interview, go to Adversarial Review.
3. Check prd.md for ## Glossary. If missing AND requirements introduce 3+ domain nouns not in codebase → generate glossary silently in prd.md, then use canonical terms throughout.
4. Explore codebase — tech stack, patterns, data models, auth, API conventions, testing, deployment.
5. Search for architecture docs, ADRs, domain glossaries. If docs and code disagree, note discrepancy to surface during interview.

If prior docs exist: "I've read the PRD, design spec, and explored the codebase. PRD calls for [items]. Spec defines [N flows] across [N screens]. Stack uses [tech]. First: [question]."

Interview Protocol

Use AskUserQuestion for every question — header (<=12 chars), 2-4 options, one marked "(Recommended)". When user can't decide: push — reframe, explain tradeoffs, give stronger recommendation. Record as assumption only when user genuinely can't resolve. Revisit assumptions when later answers provide resolution.