Cursor rule

1---
2description: "Throw-away prototype for unknown problem spaces. Output is learning notes in specs/archive/spikes/SPIKE-<name>.md, not production code. Use when the domain or technology is unexplored, when estimates are impossible without experimentation, or when user says \"spike\", \"prototype\", or \"proof of concept\"."
3alwaysApply: false
4---
5 
6# Spike Prototype
7> **HARD GATE** — **HARD GATE** — Spikes are time-boxed experiments, not shipping code. Results must be throwaway or clearly isolated. Do NOT merge a spike without a plan to integrate it or replace it with a proper implementation.
8 
9 
10A spike is a time-boxed experiment to answer a specific question. The code is thrown away. The learning is kept in `specs/archive/spikes/SPIKE-<name>.md`.
11 
12**The spike produces learning, not code to ship.** If you find yourself cleaning up spike code for production, stop — run `plan-work` and `develop-tdd` instead with the insights you gained.
13 
14## When to spike
15 
16- The technology is unfamiliar (new library, API, infrastructure)
17- The approach is uncertain (multiple solutions exist; none has been tried)
18- Estimates are impossible without seeing how the thing actually behaves
19- A key assumption needs to be validated before committing to a design
20 
21## Process
22 
23### 1. Define the question
24 
25Before writing a single line, state the question the spike must answer:
26 
27> "Can we [specific thing] using [specific approach] within [constraint]?"
28 
29Examples:
30- "Can we stream large files from S3 to the client without buffering in memory?"
31- "Does the Stripe webhook SDK handle signature verification correctly in our edge runtime?"
32- "Can we achieve < 100ms p99 response time for the search endpoint with a naive Postgres full-text search?"
33 
34A spike with no question is just unplanned coding. Refuse to start if the question isn't clear.
35 
36### 2. Set a timebox
37 
38Agree on a timebox with the user: 30 minutes, 1 hour, 2 hours. When time is up, stop — even if the question isn't fully answered. Partial learning is still learning.
39 
40### 3. Experiment
41 
42Write the simplest code that could answer the question. Ignore:
43- Error handling
44- Test coverage
45- Code quality
46- Production concerns
47 
48Focus entirely on answering the question.
49 
50### 4. Write specs/archive/spikes/SPIKE-<name>.md
51 
52Save the learning to `specs/archive/spikes/SPIKE-<name>.md`. Create the `specs/` directory if it doesn't exist.
53 
54<spike-template>
55 
56# Spike: [name]
57 
58## Question
59 
60[The specific question this spike was answering]
61 
62## Result
63 
64[Answered / Partially answered / Not answered]
65 
66## Findings
67 
68[What you learned — concrete observations, not opinions]
69 
70## Evidence
71 
72[Code snippet, benchmark result, API response, or screenshot that proves the finding]
73 
74## Implications for the plan
75 
76[How this changes the approach, the design, or the estimate]
77 
78## What was NOT explored
79 
80[Known gaps — things the spike didn't validate]
81 
82## Recommendation
83 
84[Should we proceed with this approach? If yes, what does plan-work need to account for?]
85 
86</spike-template>
87 
88### 5. Delete the spike code
89 
90After writing the findings, delete or discard the spike code. It is not meant to ship.
91 
92### 6. Feed back into plan-work
93 
94The spike findings are the input to `plan-work`. Call `plan-work` next, informed by `specs/archive/spikes/SPIKE-<name>.md`.
95