spike-investigation
This skill should be used when shaping work and needing to de-risk rabbit holes (technical unknowns, design gaps, interdependencies) by running timeboxed spikes, documenting proof, and updating the shaped concept with patches, cuts, and out-of-bounds so the work stays thin-tailed within the appetite.
Best use case
spike-investigation is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
This skill should be used when shaping work and needing to de-risk rabbit holes (technical unknowns, design gaps, interdependencies) by running timeboxed spikes, documenting proof, and updating the shaped concept with patches, cuts, and out-of-bounds so the work stays thin-tailed within the appetite.
Teams using spike-investigation should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/spike-investigation/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How spike-investigation Compares
| Feature / Agent | spike-investigation | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
This skill should be used when shaping work and needing to de-risk rabbit holes (technical unknowns, design gaps, interdependencies) by running timeboxed spikes, documenting proof, and updating the shaped concept with patches, cuts, and out-of-bounds so the work stays thin-tailed within the appetite.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Spike Investigation ## Purpose Turn uncertainty into proof fast. Based on Shape Up and Ryan Singer's work. Use spikes to answer “can this be done within the appetite?” with something more concrete than opinions: a small experiment, a thin slice, or a short code sketch that demonstrates the wiring. Spikes are not mini-projects. They exist to remove a tail of risk. ## When to use - A shaped concept looks plausible but contains **rabbit holes** (unknowns that could explode the schedule). - There are technical assumptions that need verification. - There is a misunderstood dependency or integration boundary. - A team would otherwise be asked to resolve a hard decision under deadline. ## Inputs to request or infer - Appetite / timebox for shaping and for the eventual build. - The current concept (breadboard, parts list, fit check). - The specific risk or question. - The environment constraints (stack, access, deployment rules). ## Workflow ### 1) Identify rabbit holes Slow down and review the concept critically. - Walk through the main use case in slow motion. - Look for gaps where “something” is assumed to happen. - Question each element: - require new technical work? - depend on a system that isn’t well understood? - assume a design solution exists? - hide a hard product/UX decision? Capture each rabbit hole in a risk list. Use `references/templates/risk-register-template.md`. ### 2) Choose the mitigation move For each rabbit hole, choose one primary action: - **Patch the hole**: dictate a compromise/trade-off that removes uncertainty. - **Declare out of bounds**: explicitly say what will *not* be supported. - **Cut back**: drop non-essential flavour that adds tail risk. - **Spike**: run an experiment to prove a “straight shot” exists. Write the decision and why. ### 3) Define the spike Specify the spike with tight edges: - Question: one sentence. - Success criteria: what proof looks like. - Timebox: a hard cap. - Scope: smallest possible slice. - Artefacts: what to keep (notes, tiny code snippet, diagrams), what to throw away. Use `references/templates/spike-plan-template.md`. ### 4) Execute the spike Keep it narrow. Typical spike shapes: - **Wiring spike**: show that A -> B -> C can be wired together (UI event, state, service call, render). - **Integration spike**: prove a third-party/system boundary behaves as assumed. - **Performance spike**: prove a query, indexing strategy, or paging approach meets the rough bar. - **State spike**: prove state can be persisted/restored (URL, storage, back button) without brittle hacks. Capture only what is needed to communicate the result: - Minimal reproduction steps. - Key code snippets or pseudocode. - Constraints discovered. - Red flags (tangles, hidden dependencies, unexpected side-effects). ### 5) Conclude: straight shot, tangle, or fog Classify the outcome: - **Straight shot**: few moving parts, clear stopping points. - **Tangle**: touches many parts, cascading changes, likely scope blow-up. - **Fog**: cannot see the end yet; needs more discovery or a different approach. Then decide: - proceed with current concept (and record the proof) - revise the concept (patch/cut/out-of-bounds) - drop the concept and explore a different one ### 6) Update the shaped work Immediately fold the results back into the artefacts so nobody has to remember context later. - Update breadboard/wiring diagram to match reality. - Update parts list (add/remove parts based on the proof). - Update fit check (convert ⚠️ unknowns to ✅/❌ or reframe requirements). - Add a “Rabbit holes” section that includes the spike outcome and the patch. ### 7) Produce a spike report Write a tight report that can be pasted into the pitch. Use `references/templates/spike-report-template.md`. ## Quality bar - Timebox honoured. - Proof beats opinions. - Output is legible to someone joining later. - Spike reduces risk *or* triggers a scope cut. ## Bundled resources - `references/shapeup-risks-rabbit-holes-notes.md` — summary of Shape Up Ch 5 concepts. - `references/templates/*` — spike plan/report and risk/rabbit-hole templates. - `references/examples/sample-spike.md` — example spike write-up.
Related Skills
skill-creator
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, update or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
modular-skills-architect
Map and refactor an agent context ecosystem: skills, commands/workflows, hooks, agent files, AGENTS.md templates, and docs. Output system map, module/dependency design, Register updates, and a concrete split/consolidate/rename/delete plan. Use when routing or ownership is messy.
heal-skill
This skill should be used when fixing incorrect SKILL.md files with outdated instructions or APIs.
create-agent-skills
Expert guidance for creating, writing, and refining Claude Code Skills. Use when working with SKILL.md files, authoring new skills, improving existing skills, or understanding skill structure and best practices.
agent-native-audit
Comprehensive agent-native architecture audit with scored principles and multi-slice review. Use for system-wide health checks or periodic audits.
write-judge-prompt
Design LLM-as-Judge evaluators for subjective criteria that code-based checks cannot handle. Use when a failure mode requires interpretation (tone, faithfulness, relevance, completeness). Do NOT use when the failure mode can be checked with code (regex, schema validation, execution tests). Do NOT use when you need to validate or calibrate the judge — use validate-evaluator instead.
validate-evaluator
Calibrate an LLM judge against human labels using data splits, TPR/TNR, and bias correction. Use after writing a judge prompt (write-judge-prompt) when you need to verify alignment before trusting its outputs. Do NOT use for code-based evaluators (those are deterministic; test with standard unit tests).
generate-synthetic-data
Create diverse synthetic test inputs for LLM pipeline evaluation using dimension-based tuple generation. Use when bootstrapping an eval dataset, when real user data is sparse, or when stress-testing specific failure hypotheses. Do NOT use when you already have 100+ representative real traces (use stratified sampling instead), or when the task is collecting production logs.
evaluate-rag
Guides evaluation of RAG pipeline retrieval and generation quality. Use when evaluating a retrieval-augmented generation system, measuring retrieval quality, assessing generation faithfulness or relevance, generating synthetic QA pairs for retrieval testing, or optimizing chunking strategies.
eval-audit
Audit an LLM eval pipeline and surface problems: missing error analysis, unvalidated judges, vanity metrics, etc. Use when inheriting an eval system, when unsure whether evals are trustworthy, or as a starting point when no eval infrastructure exists. Do NOT use when the goal is to build a new evaluator from scratch (use error-analysis, write-judge-prompt, or validate-evaluator instead).
error-analysis
Help the user systematically identify and categorize failure modes in an LLM pipeline by reading traces. Use when starting a new eval project, after significant pipeline changes (new features, model switches, prompt rewrites), when production metrics drop, or after incidents.
build-review-interface
Build a custom browser-based annotation interface tailored to your data for reviewing LLM traces and collecting structured feedback. Use when you need to build an annotation tool, review traces, or collect human labels.