Spike
Use when the user wants to test an idea before committing to a real build: "spike this", "quick prototype", "is this possible", "compare A/B", "before we build".
Do not use when reading docs/code can answer the question, or when the user clearly asked for production implementation.
Loop
- Question: state the concrete feasibility question.
- Research: read enough docs/source to choose credible approach.
- Build: create the smallest runnable artifact that validates or invalidates the idea.
- Stress: try one edge case or failure mode.
- Verdict:
VALIDATED, PARTIAL, or INVALIDATED.
Output shape
- Default workspace:
.tmp/openclaw-spikes/<slug> unless user asks for a tracked repo-local path.
- Repo-local option:
spikes/<NNN-slug>/ with README.md and minimal code.
- Prefer runnable CLI, tiny HTML, one endpoint, or focused test.
- Avoid package sprawl, Docker, env files, app frameworks, and production cleanup.
Multi-spike ideas
- Split into 2-5 independent questions.
- Run the riskiest question first.
- For A/B comparisons, keep inputs equal and measure the same dimensions.
- Ask before building all variants if the work is more than a small prototype.
Verdict format
## Verdict: VALIDATED | PARTIAL | INVALIDATED
Question: ...
Evidence: exact command/output/measurement.
What worked: ...
What failed or surprised us: ...
Recommendation: ship / adjust / avoid, with the next production step.
Rules
- An invalidated spike is useful when it rules out a path with evidence.
- Do not merge spike code into production without rewriting it normally.
- If external dependencies are evaluated, check health: recent release/commit, docs, license, install friction.
1---2name: spike3description: Run throwaway prototypes to validate feasibility, compare approaches, and report a verdict.4---56# Spike78Use when the user wants to test an idea before committing to a real build: "spike this", "quick prototype", "is this possible", "compare A/B", "before we build".910Do not use when reading docs/code can answer the question, or when the user clearly asked for production implementation.1112Loop13141. Question: state the concrete feasibility question.152. Research: read enough docs/source to choose credible approach.163. Build: create the smallest runnable artifact that validates or invalidates the idea.174. Stress: try one edge case or failure mode.185. Verdict: `VALIDATED`, `PARTIAL`, or `INVALIDATED`.1920Output shape2122- Default workspace: `.tmp/openclaw-spikes/<slug>` unless user asks for a tracked repo-local path.23- Repo-local option: `spikes/<NNN-slug>/` with `README.md` and minimal code.24- Prefer runnable CLI, tiny HTML, one endpoint, or focused test.25- Avoid package sprawl, Docker, env files, app frameworks, and production cleanup.2627Multi-spike ideas2829- Split into 2-5 independent questions.30- Run the riskiest question first.31- For A/B comparisons, keep inputs equal and measure the same dimensions.32- Ask before building all variants if the work is more than a small prototype.3334Verdict format3536```markdown37## Verdict: VALIDATED | PARTIAL | INVALIDATED3839Question: ...40Evidence: exact command/output/measurement.41What worked: ...42What failed or surprised us: ...43Recommendation: ship / adjust / avoid, with the next production step.44```4546Rules4748- An invalidated spike is useful when it rules out a path with evidence.49- Do not merge spike code into production without rewriting it normally.50- If external dependencies are evaluated, check health: recent release/commit, docs, license, install friction.
aniruddhaadak80