spike

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

5|2|Updated May 26, 2026
One-click install
npx skills add https://github.com/perasyudha/Nyxora --skill spike-perasyudha
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spike
Source: https://github.com/perasyudha/Nyxora/tree/main/packages/core/playbooks/software-development/spike
Command: npx skills add https://github.com/perasyudha/Nyxora --skill spike-perasyudha

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often commit to architectures or libraries before knowing whether they actually work. This Skill structures quick, disposable experiments that answer feasibility questions with real evidence instead of assumptions. ## Core Features & Use Cases - Structured Spike Loop: Decompose an idea into 2-5 feasibility questions, research approaches, build minimal prototypes, and record a VALIDATED / PARTIAL / INVALIDATED verdict per spike. - Comparison Spikes: Run competing approaches (e.g., pdfjs vs camelot) side by side and produce a head-to-head comparison table with a clear winner recommendation. - Frontier Mode: Analyze existing spikes to surface integration risks, unproven data handoffs, and gaps worth spiking next. - 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 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 specific feasibility questions, build a minimal throwaway prototype for each, and record a verdict of VALIDATED, PARTIAL, or INVALIDATED. Order spikes by risk so the assumption most likely to kill the idea gets tested first.

How do I compare two libraries or approaches 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 dimensions like output quality, setup complexity, and performance. Close with a clear winner recommendation for your use case.

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 (use a planning workflow instead), or when the idea is already validated and you can jump straight to implementation.

What makes a good spike question?

A good spike question targets specific feasibility with observable output, framed as Given/When/Then. Bad spike questions are too broad, produce no observable output, or amount to just reading documentation about a topic.

What should a spike prototype include?

Each spike lives in its own directory with a README and minimal code, biased toward something interactive like a runnable CLI, a small HTML page, or a single-endpoint server. Avoid build tools, Docker, and config systems; hardcode everything since the code is disposable.