spike

# Spike

Structured technical investigation to reduce uncertainty. Answer specific questions, not "explore X."

**Integrates with:**
- `ohno` — Creates spike task, tracks time-box, logs findings
- `project-harness` — Works within session workflow
- All domain skills — May invoke for specialized investigation

## Core Philosophy

```
┌─────────────────────────────────────────────────────────────────┐
│                   SPIKE = BOUNDED UNCERTAINTY                    │
├─────────────────────────────────────────────────────────────────┤
│  INPUT: Vague concern or unknown → "Can we use GraphQL?"        │
│  OUTPUT: Decision + evidence    → "Yes, with caveats. Here's    │
│                                    the proof-of-concept."       │
├─────────────────────────────────────────────────────────────────┤
│  TIME-BOXED: 2-4 hours default, never >1 day                    │
│  QUESTION-FOCUSED: Answer ONE specific question                 │
│  OUTPUT-DRIVEN: End with decision, not more questions           │
│  DOCUMENTED: Learnings captured even if answer is "no"          │
└─────────────────────────────────────────────────────────────────┘
```

## Quick Start

### 1. Frame the Question

Transform vague concerns into spike-able questions:

| Vague | Spike Question |
|-------|----------------|
| "Look into caching" | "Can Redis reduce our API latency to <100ms for user lookups?" |
| "Explore auth options" | "Can we use OAuth2 with Google for our auth flow?" |
| "Check if X is possible" | "Can library X handle 10k concurrent connections?" |

**Good spike questions have:**
- A yes/no or A/B answer
- Measurable success criteria
- Clear scope boundaries

### 2. Define Time Box & Success Criteria

```markdown
## Spike Definition

**Question**: Can we use Cloudflare D1 for our multi-tenant data model?

**Time Box**: 3 hours
**Type**: Feasibility

**Success Criteria**:
- [ ] Row-level security works for tenant isolation
- [ ] Query performance acceptable (<50ms for typical queries