/rota-spike

Try one risky idea on a throwaway branch and keep only the finding.

When to use

Use when X must be tried before committing to it (“can we use SSE?”, “does this library handle our scale?”) and the answer is a finding, not shipped code.

Reach for another skill when

the question is which design to pick, not whether something works: /rota-brainstorm
the result should be shipped code, not a finding: /rota-work

Usually before/rota-vision/rota-brainstorm

/rota-spike

Usually after/rota-plan

Example

/rota-spike will a single-currency schema survive a later move to multi-currency?

Question: can a single-currency schema migrate to multi-currency without data loss? Named it sqlite-schema.
Created branch spike/sqlite-schema and .rota/spikes/sqlite-schema.md.
The question is recorded. Experiment on the branch; fill in Findings and Decision when done.

What changes

a spike/<name> branch that is never merged
.rota/spikes/<name>.md with the question, findings and decision

Where this example comes from

Flags and modes

done <name>: close the spike with a verdict (viable, not viable, depends-on-X, inconclusive)

Details

Throwaway feasibility experiment on a dedicated spike/<name> branch that is never merged. It answers a specific yes/no/conditional question and records the question, what was tried, the findings and the decision in .rota/spikes/<name>.md. See spikes.