speclisted

# Technical Specification Produce a full technical specification before any implementation begins. No code is written during this skill. This is a design document, not a plan. ## Step 1: Understand the feature Read `$ARGUMENTS` carefully. Extract: - **What** — what capability does this add or change? - **Why** — what problem does it solve? What's the business/user motivation? - **Who** — which users, systems, or services are affected? - **Scope** — what is explicitly in scope vs. out of scope? If any of these are unclear → ask one clarifying question before exploring. ## Step 2: Explore the codebase — spawn the `explorer` agent Spawn the `explorer` agent to map the current state. Pass: ``` Feature being specced: <feature name and description from Step 1> Find: - Existing data models relevant to this feature - Existing API endpoints or service interfaces that will change - Authentication and authorization patterns in use - Error handling conventions - Test patterns and existing coverage in the affected area - Any prior attempts at this feature (git log, TODOs, comments, feature flags) ``` **Constraint inventory:** use the explorer's findings to note existing constraints the spec must respect — existing API contracts, database schema limitations, third-party integrations, performance SLAs. ## Step 3: Produce the specification --- ### 🎯 Feature Overview **Name:** `<feature name>` **Motivation:** Why is this being built? What problem does it solve? **Success criteria: