Spike
Structured technical investigation to reduce uncertainty. Answer specific questions, not "explore X."
Key Principles
- Every spike answers a specific, measurable question
- Strict time-box (default 4h) — produce a decision at the end, even if incomplete
- Output is a decision (GO/NO-GO/PIVOT/MORE-INFO), not a general exploration
- Create follow-up tasks from findings, not just a report
When NOT to Use
- Multi-day evaluations — Use
deep-researchfor comprehensive technology evaluations with stakeholder reports - Already know what to build — Skip straight to implementation; spikes are for reducing uncertainty, not planning known work
- Bug investigation — Use
error-handlingor/fix; bugs have reproduction steps, spikes have open questions
Quick Start Checklist
- Define the question clearly (what are we trying to learn?)
- Set a time-box (hours, not days — use deep-research for multi-day)
- Identify evaluation criteria upfront
- Investigate with focused experiments or prototypes
- Checkpoint at 50% — assess progress, decide if pivoting
- Produce mandatory conclusion: GO / NO-GO / PIVOT / MORE-INFO
Mandatory Outputs
- Decision: GO, NO-GO, PIVOT, or MORE-INFO
- Evidence: What was tested, results observed
- Follow-up tasks: Created in ohno if GO
- Report: Saved to
.claude/spikes/[name]-[date].md
References
| Reference | Description |
|---|---|
| spike-types.md | Feasibility, architecture, integration, performance spikes |
| question-patterns.md | How to frame good spike questions |
| output-templates.md | Spike report templates and examples |