prototype-spikelisted

# Prototype Spike ## Goal Answer a specific uncertainty with a deliberately bounded prototype, then either discard it or convert only the proven idea into production work. ## When to use - The user asks for a spike, proof of concept, prototype, or throwaway experiment. - A design choice needs evidence before production implementation. - An integration, API, performance assumption, or UI interaction is uncertain. ## When not to use - The user needs production-ready implementation now. - The uncertainty can be answered by reading docs or existing code. - The prototype would require secrets, real customer data, or irreversible operations. ## Inputs to inspect - The exact question the prototype must answer. - Existing architecture, ADRs, validation commands, and domain docs. - Constraints on where prototype files may live and how they should be cleaned up. ## Workflow 1. State the hypothesis or design question. 2. Define the prototype boundary, timebox, and throwaway location. 3. Ask before adding dependencies, new services, or files outside an agreed scratch area. 4. Build the smallest experiment that answers the question. 5. Record findings, limitations, and production implications. 6. Clean up throwaway files or clearly mark what should remain. 7. Recommend whether to proceed, revise, or abandon the production approach. ## Safety rules - Do not ship prototype code as production code without a review step. - Do not add persistent dependencies or config unless approv