speclisted

Create or update a feature specification from a natural language feature description. Enforces brownfield-first discovery, traceability tags, research coordination, and incremental document creation. Use when starting design work on a new feature or enhancement.
matthull/my-skills · ★ 0 · AI & Automation · score 72

Install: claude install-skill matthull/my-skills

# Technical Specification Command Create a well-researched technical specification that defines WHAT to build, not HOW to build it. ## Input Feature description: `{{input}}` --- ## Core Principles ### 1. WHAT, Not HOW Specs define outcomes, contracts, and responsibilities - never implementation details. | SPECIFY | DON'T SPECIFY | |---------|---------------| | API endpoints & response shapes | Service class internals | | Data model fields & relationships | Helper method implementations | | Component responsibilities | File organization | | UI structure (wireframe-level) | CSS/styling details | | Test scenarios (behaviors to verify) | Test implementation | | Method signatures | Method bodies | ### 2. Code Shows Structure, Not Logic Code in specs shows signatures and flow - never implementation logic. **The Coordination Test** determines what to specify: - **Specify (contracts):** If changing it requires coordinating across modules → put it in the spec - **Don't specify (implementation):** If it can change without external impact → leave to implementor | Specify | Don't Specify | |---------|---------------| | Data structures used across modules | Internal helper methods | | Method signatures (entry points, contracts) | Method body logic | | API response shapes | Validation details | | Cross-cutting data shapes | Logging specifics | **Litmus Test:** Could you copy-paste the code and have it work? If yes, you over-specified. **Good - structure and flow:** ```ruby de