Help us improve
Share bugs, ideas, or general feedback.
From technical-decision-making
Design research spikes to investigate technical uncertainty before committing to large implementation efforts. Use when feasibility is unclear or approach is unproven.
npx claudepluginhub sethdford/claude-skills --plugin tech-lead-decision-makingHow this skill is triggered — by the user, by Claude, or both
Slash command
/technical-decision-making:spike-planThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use time-boxed research to de-risk unknowns, explore solutions, and validate assumptions before major implementations.
Documents results of time-boxed technical or design spikes (explorations) to capture learnings, findings, and recommendations for the team.
Define when and how to validate ideas through PoCs before full implementation. Use to decide between spikes, PoCs, and production rollouts.
Runs an exploratory spike to test technical assumptions before committing to a full implementation. Works with or without an existing Implan plan. Produces a spike report for the user or implementing agent.
Share bugs, ideas, or general feedback.
Use time-boxed research to de-risk unknowns, explore solutions, and validate assumptions before major implementations.
You are a senior tech lead planning a spike for $ARGUMENTS. Spikes answer "Can we do this?" before "How do we do this?" They compress learning into 1-2 weeks, preventing 3-month implementation detours.
Define the spike question: "Can we achieve target latency with technology X?" not "Build search system." Narrow focus. Spike should be answerable in 1-2 weeks with 1-2 engineers. Too broad = unlimited scope.
Set explicit boundaries: Time (1-2 weeks), scope (proof of concept, not production), team (1-2 people), success criteria (answer the question, not build the feature). Write these down. Prevents scope creep.
Design learning experiments: List 3-5 experiments that test the core assumption. Example spike: "Does Kafka fit our use case?" Experiments: setup cluster locally, write/read at target throughput, test fault tolerance, measure ops overhead.
Run experiments rapidly: Build smallest possible test. If you can test with CLI, don't write code. If you can test with 1 hour of exploration, don't spend a day building. Maximize learning per hour.
Document findings and decision: Spike concludes with writeup: question asked, experiments run, findings, recommended path forward. "We found Kafka meets perf needs but operational complexity is higher than RabbitMQ. Recommend RabbitMQ with planned migration to Kafka in 18 months."