spike

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

Updated Sep 9, 2026
One-click install
npx skills add https://github.com/luckybbjason1/trading --skill spike-luckybbjason1
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spike
Source: https://github.com/luckybbjason1/trading/tree/main/.hermes/skills/software-development/spike
Command: npx skills add https://github.com/luckybbjason1/trading --skill spike-luckybbjason1

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 Spike Loop: Decompose an idea into 2-5 independent feasibility questions framed as Given/When/Then, ordered by risk so the idea-killing question runs first. - Comparison Spikes: Build competing approaches side by side (e.g., pdfjs vs camelot for PDF parsing) with head-to-head verdict tables covering quality, setup complexity, and performance. - Evidence-Based Verdicts: Every spike closes with a VALIDATED, PARTIAL, or INVALIDATED verdict documenting what worked, what failed, and recommendations for the real build. - Use Case: Before building a real-time chat feature, spike websocket streaming to confirm the LLM token stream reaches the client in under 100ms, then throw the prototype away. ## Quick Start Ask the agent to spike whether your chosen library can handle your core use case before you commit to the full implementation.

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?

Run a spike: decompose the idea into 2-5 independent feasibility questions framed as Given/When/Then, order them by risk, then build a minimal throwaway prototype for each. Close each spike with a VALIDATED, PARTIAL, or INVALIDATED verdict backed by observed evidence.

How do I compare two libraries for the same task?

Build comparison spikes with a shared number and letter suffixes (e.g., 002a and 002b), one per approach, then write a head-to-head table covering extraction quality, setup complexity, and performance. Pick a winner based on your specific use case, not general popularity.

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. Spikes exist only for questions research cannot answer.

What makes a good spike question?

A good spike question targets specific feasibility with observable output, such as whether a websocket delivers chunks under 100ms. Bad questions are too broad, produce no observable output, or amount to just reading documentation.

Should spike code be production quality?

No. Spikes are disposable by design: hardcode values, avoid build tools, Docker, and config systems, and keep each spike in its own standalone directory. A spike that takes days to clean up for production was a bad spike.