Windsurf rules

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