Research spike

Skill dennisonbertram/developer-skill-pack/skills/research-spike

Time-boxed research before adopting a library, API, architecture, or provider. Use when asked to 'research', 'compare options', 'evaluate a library', 'spike on', 'investigate a tool', 'should we use X', or 'what are our options for'. Produces structured findings in docs/research/ with no production code changes.From its SKILL.md

Install

npx -y skills add dennisonbertram/developer-skill-pack --skill research-spike

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.9 KB, as published. Nobody here has run it

Research Spike

Execute a structured, time-boxed research spike. Produces a recommendation with tradeoffs, captured in docs/research/, with no production code changes.

Usage

/research-spike <question> [--options "A, B, C"] [--time-box 2h]

Process

Phase 1: Frame the Question

Restate the research question in one sentence
List the options to compare (at minimum 2)
Define the decision criteria (cost, complexity, maintenance, performance, security, compatibility)
Identify documentation sources:
- Use Context7 for libraries, frameworks, SDKs, APIs, CLI tools, and cloud services
- Link vendor docs
- Reference existing repo docs or decisions

Phase 2: Research

Spawn read-only Explore subagents in parallel (one per option or topic area):

Fetch current documentation via Context7:

npx ctx7@latest library "<library name>" "<research question>"
npx ctx7@latest docs <libraryId> "<specific question>"

Read official docs, source code, examples
Identify: capabilities, limitations, failure modes, maintenance status, community health
Note expectation gaps between docs and reality

Phase 3: Compare and Recommend

Build a comparison matrix against the decision criteria
State a clear recommendation with rationale
List tradeoffs and risks for each option
Identify follow-up implementation issues if adopting

Phase 4: Write Findings

Write to docs/research/<date>-<slug>.md:

# Research: <Question>

**Date**: <ISO date>
**Decision**: <Recommended option>
**Status**: <recommended | needs-discussion | blocked>

## Question
<Restatement>

## Options Compared

### Option A: <name>
- **Pros**: ...
- **Cons**: ...
- **Risks**: ...

### Option B: <name>
- **Pros**: ...
- **Cons**: ...
- **Risks**: ...

## Comparison Matrix

| Criterion | Option A | Option B |
|-----------|----------|----------|
| ...       | ...      | ...      |

## Recommendation
<Clear recommendation with rationale>

## Follow-up
- [ ] Implementation issue if adopting
- [ ] Migration plan if replacing existing

## Sources
- Context7: <library IDs used>
- Vendor docs: <URLs>
- Repo docs: <paths>

Rules

No production code changes. Research only.
Always use Context7 for library/framework/SDK questions — do not rely on training data.
Capture findings even if the recommendation is "don't adopt."
File follow-up implementation issues for adopted recommendations.
Time-box the research. If a question cannot be answered within the time box, document what is known and what remains unknown.