spike

Build throwaway prototypes to validate technical feasibility before committing to a real build.

Updated Aug 19, 2026
One-click install
npx skills add https://github.com/jakubbartnik/honey-barrel-finale --skill spike-jakubbartnik
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spike
Source: https://github.com/jakubbartnik/honey-barrel-finale/tree/main/honey-barrel-finale/workspace/hermes/skills/software-development/spike
Command: npx skills add https://github.com/jakubbartnik/honey-barrel-finale --skill spike-jakubbartnik

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often commit to architectures or libraries before knowing whether they actually work, wasting weeks on dead-end implementations. This Skill structures quick, disposable experiments that answer feasibility questions with real evidence before any production code is written. ## Core Features & Use Cases - Structured Decomposition: Breaks a vague idea into 2-5 independent feasibility questions framed as Given/When/Then statements, ordered by risk so the idea-killing question runs first. - Comparison Spikes: Builds competing approaches side by side (e.g., pdfjs vs camelot for PDF parsing) and produces a head-to-head verdict table with a clear winner recommendation. - Evidence-Based Verdicts: Every spike closes with a VALIDATED, PARTIAL, or INVALIDATED verdict documenting what worked, what failed, and surprises found. - Use Case: Before building a real-time chat feature, spike whether WebSocket streaming delivers LLM tokens to the client under 100ms, then throw the prototype away and start the real build with confidence. ## Quick Start Ask the agent to spike whether your chosen library or approach actually works for your use case before you commit to building the real feature.

Frequently Asked Questions about spike

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I validate a technical idea before building it?▼

Decompose the idea into 2-5 independent feasibility questions, build a minimal throwaway prototype for each in its own directory, and record a verdict. Order spikes by risk so the question most likely to kill the idea gets tested first.

What is a spike in software development?▼

A spike is a disposable experiment that answers a specific feasibility question with working code. It is thrown away after producing a verdict, so it avoids production concerns like configuration systems, build tools, and cleanup.

How do I compare two libraries or approaches for the same problem?▼

Build comparison spikes with a shared number and letter suffix, such as 002a and 002b, testing each approach against the same question. Finish with a head-to-head table covering quality, setup complexity, and performance, then declare a winner.

When should I not use a spike?▼

Skip spiking when the answer is knowable from documentation or reading existing code, when the work is on the production path and needs real planning, or when the idea is already validated and ready for implementation.

What makes a good spike question?▼

A good spike question targets specific feasibility with observable output, such as whether a WebSocket delivers streamed tokens under 100ms. Avoid questions that are too broad, have no observable output, or could be answered by reading docs.