From spike-workflow
Run a structured Agile/XP spike investigation from start to finish. Use this skill whenever the user provides a spike question or asks Claude to "do a spike on X", "investigate X", "explore whether X is feasible", or "run a spike". Also trigger when the user mentions spike types (technical spike, functional spike, risk spike) or says things like "we need to validate before committing", "time-boxed research", or "proof of concept for X". The skill produces all required spike deliverables: findings document, recommendation, refined estimates, and a functional archived prototype where applicable.
How this skill is triggered — by the user, by Claude, or both
Slash command
/spike-workflow:spikeThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Executes a full spike investigation and produces all required deliverables in compliance
Executes a full spike investigation and produces all required deliverables in compliance with the accepted Agile/XP definition of a spike.
Claude must have the required inputs before starting. If any are missing, ask before proceeding.
| Input | Required | Description |
|---|---|---|
question | ✅ | The single question the spike must answer |
type | ✅ | technical | functional | risk |
timebox | ✅ | Duration agreed by the team (e.g. "2 days", "1 sprint") |
context | ✅ | Project, stack, and constraints relevant to the investigation |
code_context | Optional | Relevant code snippets: existing implementations, interfaces, state shapes, or patterns the spike must be compatible with |
If type is not given, infer it from the question and confirm with the user.
If timebox is not given, default to 1 day and state this assumption explicitly.
When code_context is provided:
| Deliverable | Destination |
|---|---|
| Findings document | Azure DevOps Wiki — format as a wiki page (see references/deliverables.md) |
| Recommendation statement | Inline in the findings wiki page — stakeholder paragraph first, then technical detail |
| Refined estimate | Inline in the findings wiki page |
| Prototype | Standalone project folder (spike-<slug>/) — archived in the repository or designated spike archive |
Phase 1 requires deep reasoning. Apply the following:
| Setting | Value | Rationale |
|---|---|---|
| Model | claude-opus-4 (or strongest available) | Spike questions are often ambiguous; deep reasoning reduces missed failure modes |
| Extended thinking | On | Surfaces non-obvious constraints and design trade-offs |
| Web search | On | External docs, package changelogs, known issues, community reports |
Environment notes:
Output a Spike Brief before doing any investigation:
## Spike Brief
- **Question:** <exact question being answered>
- **Type:** <technical | functional | risk>
- **Timebox:** <agreed duration>
- **Success criteria:** <how we'll know the question is answered>
- **Out of scope:** <explicit exclusions>
Ask the user to confirm before proceeding to Phase 1.
Read the relevant reference file for investigation guidance:
references/technical.md § Investigationreferences/functional.md § Investigationreferences/risk.md § InvestigationPerform the investigation. Document what you tried, what you read, what you ran, and what you observed. Be explicit about dead ends — they are findings too.
If code_context was provided, analyse it before investigating externally:
identify the patterns, constraints, and conventions the solution must respect.
A prototype is required when:
A prototype is not required for purely functional spikes (unless the question involves a UI/UX flow that must be validated visually).
Read references/technical.md § Implementation Notes (or the relevant type file)
before building — this section contains known patterns and pitfalls for the stack.
If building a prototype:
src/, tests/, config files)pubspec.yaml, package.json, requirements.txt, etc.).gitignore appropriate for the stackcode_context was provided, match its state shapes, naming conventions, and layer boundariesREADME.md with: what it demonstrates, prerequisites, run instructions, test instructions, expected output, and explicit scope exclusions// SPIKE PROTOTYPE — ARCHIVED — NOT FOR PRODUCTIONspike-<slug>/Gate before Phase 3 — do not proceed until:
flutter test, npm test, pytest, etc.)Publish the prototype to GitHub:
Once the gate passes:
git init inside the prototype foldergit branch -M maingit add .
git commit -m "chore: spike prototype — archived, not for production"
gh repo create spike-<slug> --private --source=. --remote=origin --push
gh repo view spike-<slug> --json url -q .urlAlways produce all of the following. Use references/deliverables.md for templates.
Full Azure DevOps Wiki page. See references/deliverables.md for the complete template.
Always produce two layers:
Layer 1 — Stakeholder paragraph (always first): A plain-language paragraph, max 5 sentences, suitable for a product owner or non-technical stakeholder. No code, no jargon. Structure: what was investigated → what was found → what is recommended → what happens next.
Layer 2 — Technical recommendation (immediately after):
Go / No-Go — use when the question is binary:
Recommendation: GO ✅ | NO-GO ❌
Rationale: <2-3 sentences>
Conditions: <conditions that must hold, or "None">
Ranked Comparison — use when multiple approaches were investigated:
Recommendation: Approach <X> over <Y> [over <Z>]
| Criterion | Approach A | Approach B | Approach C |
|---|---|---|---|
| <criterion 1> | ... | ... | ... |
Rationale: <why the winner prevails on the criteria that matter most>
Trade-offs accepted: <what we give up>
Never produce a vague "it depends" — commit to a recommendation with documented rationale.
If the spike unblocks a specific implementation task:
## Spike Closed
- **Question answered:** Yes / Partially / No
- **If partially/no:** reason and recommended follow-up spike
- **Prototype archived:** Yes / N/A
- **Next action:** <specific next step for the team>
If you discover important unknowns or tangential questions during investigation, log them in a Parking Lot section at the end of the findings document. These become candidates for future spikes or tickets.
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub theocarranza/spike-workflow-marketplace --plugin spike-workflow