# Tech Spec Guidelines > Tech Spec is a pre-development document that technically proposes how a feature will be implemented, serving not as a static record but as a medium for productive discussion. ## Purpose As a key collaboration tool, Tech Spec: - ✅ Reduces post-implementation rework and communication costs - ✅ Enables more robust designs through early peer feedback - ✅ Creates shared understanding before coding begins --- ## When to Write a Tech Spec Write a Tech Spec **before** implementing any feature that: - Takes more than 2 hours to build - Affects multiple files or components - Changes existing data structures or APIs - Requires coordination with advisors or collaborators --- ## Tech Spec Template ```markdown # [Feature Name] Tech Spec ## 1. Problem Statement What problem are we solving? Why now? ## 2. Proposed Solution High-level approach and key design decisions ## 3. Technical Design - Data structures - Algorithm/model specifications - File changes required - Dependencies ## 4. Implementation Plan Step-by-step breakdown with time estimates ## 5. Open Questions What needs discussion or advisor input? ## 6. Alternatives Considered What other approaches did we reject and why? ``` --- ## Best Practices 1. **Share early**: Circulate Tech Spec when it's 60% complete 2. **Request specific feedback**: "Does this model specification make sense?" vs "Any thoughts?" 3. **Update after discussion**: Tech Spec is a living document during pre-implementation 4. **Archive after completion**: Keep as reference but don't maintain post-implementation --- ## Examples - See `Front/On/strategic ambiguity/empirics/workflow(hypothesis, data, model).md` for data analysis Tech Spec - See `[future examples]` for code implementation Tech Specs --- **Questions?** Contact: amoon🐣