From jlindley-skills
Create spike definitions with canonical names and numbered approaches for parallel exploratory implementation. Use when partner has an underdefined feature idea and wants to explore multiple implementation approaches in parallel, when uncertain which technical approach is best, or when comparing alternatives before committing to implementation
How this skill is triggered — by the user, by Claude, or both
Slash command
/jlindley-skills:defining-spikesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Transform underdefined feature requests into structured spike definitions that multiple agents can execute in parallel, each exploring a different approach.
Transform underdefined feature requests into structured spike definitions that multiple agents can execute in parallel, each exploring a different approach.
Core principle: Define once, execute many times. The definition creates a contract for parallel exploration.
Announce at start: "I'm using the Defining Spikes skill to create a spike definition."
A spike definition is NOT implementation. It's a structured exploration plan containing:
You are defining what to explore, not exploring it yourself.
Copy this checklist to track progress:
Defining Spikes Progress:
- [ ] Phase 1: Understanding Desired Outcome (goal and success criteria gathered)
- [ ] Phase 2: Implementation Constraints (must-haves/must-nots identified or skipped)
- [ ] Phase 3: Choose Canonical Name (kebab-case identifier confirmed with partner)
- [ ] Phase 4: Generate Approaches (2-3 genuinely different approaches listed)
- [ ] Phase 5: Create Spike Infrastructure (branch, notes file committed)
Ask 1-4 questions focused on WHAT, not HOW:
Ask about:
Don NOT ask about:
One round only. Get enough to understand the goal, then move forward.
Only ask if there are unclear must-haves or must-nots:
If partner didn't mention constraints, assume none. Move to Phase 3.
Create short kebab-case identifier. Examples:
replace-3d-vectorsadd-graphql-apiimprove-test-perfmigrate-to-postgresAsk partner to confirm the name. This name will be used for all branches and files.
List 2-3 numbered, high-level approaches that are genuinely different.
Genuinely different means:
Examples:
✅ Good - Genuinely Different:
1. Incremental migration with parallel APIs
2. Gateway/facade pattern wrapping existing system
3. Full rewrite with shared business logic
❌ Bad - Too Similar:
1. Use date-fns library
2. Use Day.js library
3. Use Luxon library
(These are all "adopt a library" - same strategy)
If no obvious different approaches exist, say so:
Approaches:
- Only one obvious approach: [describe it]
Create branch: spike-[canonical-name]
Determine spike notes location (use bash test -d docs to check):
docs/ directory exists: create docs/spike-notes-[canonical-name].mddocs/ does not exist: use AskUserQuestion tool to ask partner:
docs/ directory and use itspike-notes-[canonical-name].md to project rootDO NOT:
.spikes/, spikes/, etc.docs/spikes/Use ONLY docs/ (if exists or created) OR project root.
Create file: spike-notes-[canonical-name].md (in determined location) with this structure:
# Spike: [Canonical Name]
## Goal
[What we're trying to achieve]
## Success Criteria
- [ ] [Measurable outcome 1]
- [ ] [Measurable outcome 2]
- [ ] [Measurable outcome 3]
## Constraints
[Must-haves and must-nots, or "None"]
## Approaches
### Approach 1: [Name]
[High-level description]
### Approach 2: [Name]
[High-level description]
### Approach 3: [Name]
[High-level description - if applicable]
## Effort Limit
[e.g., "~2-3 hours of exploration per approach"]
## Notes
[Any additional context]
spike-[canonical-name]-1, spike-[canonical-name]-2, etc.".spikes/, spikes/, etc.) → Use docs/ or project root onlyAll of these mean: You're not following the defining-spikes process.
| Excuse | Reality |
|---|---|
| "Too open-ended to define" | That's what spikes are for - reducing ambiguity |
| "I need to explore the codebase first" | That's execution, not definition |
| "This is too simple for multiple approaches" | Then say so explicitly - don't assume |
| "Time pressure - skip the git setup" | Git infrastructure is mandatory, even under pressure |
| "Let me just implement it" | You're defining, not executing |
Don't use for:
Ask partner: "This seems well-defined. Do you actually want a spike, or should we plan the implementation directly?"
Your job is done. Partner will either:
Do NOT start implementing. Definition and execution are separate roles.
npx claudepluginhub jlindley/jlindley-marketplace --plugin jlindley-skillsDesign research spikes to investigate technical uncertainty before committing to large implementation efforts. Use when feasibility is unclear or approach is unproven.
Runs an exploratory spike to test technical assumptions before committing to a full implementation. Works with or without an existing Implan plan. Produces a spike report for the user or implementing agent.
Brainstorms features or improvements through collaborative dialogue, surfacing gray areas and breaking vision into implementation phases. Precedes design work.