How do I install the Spike skill?

Run npx skillmds@latest add morgs32/spike in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Spike safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Spike?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Spike free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

morgs32 (@morgs32) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Spike by morgs32 — Agent Skill

Name: Spike
Rating: 4.666666666666667 (3 reviews)
Author: morgs32

Spike

Explores ideas with pseudocode, stubs, and comments only—no architecture ownership, no compile-fixing, temporary broken state OK. Use when the user says spike, /spike, sketch, rough pass, explore options, or wants a first pass before they decide design.

morgs32 Updated Sep 10, 2026

File contents

Spike mode

The user drives architecture. This pass is for orientation and options, not a shippable implementation.

Defaults (do these unless they say otherwise)

Shells and pseudocode — Write the obvious shape (function signatures, empty bodies, // TODO, placeholder returns). Prefer readable stubs over complete logic.
Minimal surface — Only what maps directly to the stated problem. No new abstractions, helpers, or “while we’re here” refactors.
Broken is OK — Do not spend effort making the project typecheck or build. No import fixing, no exhaustive types, no wiring every call site, unless the user explicitly asks for a compiling spike.
Reuse via pointers, not copies — If something already exists almost identically elsewhere, do not duplicate a big block. Add a short comment with the repo-relative path (and symbol name if helpful), e.g. // Same pattern as packages/core/src/session/makeSession.ts (stage + Effect.gen).
Comments carry the design — For non-obvious gaps, use block comments: intent, tradeoffs in one line each, and “would pull from X” or “would call Y”. The code is a skeleton; the comments are the spike.

Optional small step

If—and only if—a pattern is already established in this codebase and copying it is a few lines with a clear file reference, you may add that tiny slice. Otherwise leave a comment and stop.

How to finish the turn

After the stubbed code:

List numbered comment anchors (or map to line ranges) for each place you left a real decision.
Prompt one decision at a time — e.g. “For (1): option A vs B; which direction?” Wait for an answer before assuming the next.

Do not dump a long questionnaire; one focused question per ambiguous comment unless the user asks for a batch.

Anti-patterns for spikes

Choosing frameworks, folder layout, or new types “for cleanliness.”
Filling in error handling, tests, or production edge cases.
“Making it compile” across the monorepo when the user wanted exploration only.

If scope is unclear, spike the smallest file or function they pointed at and ask one clarifying question.

---name: spikedescription: Explores ideas with pseudocode, stubs, and comments only—no architecture ownership, no compile-fixing, temporary broken state OK. Use when the user says spike, /spike, sketch, rough pass, explore options, or wants a first pass before they decide design.---# Spike modeThe user drives architecture. This pass is for **orientation and options**, not a shippable implementation.## Defaults (do these unless they say otherwise)1. **Shells and pseudocode** — Write the obvious shape (function signatures, empty bodies, `// TODO`, placeholder returns). Prefer readable stubs over complete logic.2. **Minimal surface** — Only what maps directly to the stated problem. No new abstractions, helpers, or “while we’re here” refactors.3. **Broken is OK** — Do **not** spend effort making the project typecheck or build. No import fixing, no exhaustive types, no wiring every call site, unless the user explicitly asks for a compiling spike.4. **Reuse via pointers, not copies** — If something already exists almost identically elsewhere, **do not duplicate** a big block. Add a short comment with the repo-relative path (and symbol name if helpful), e.g. `// Same pattern as packages/core/src/session/makeSession.ts (stage + Effect.gen).`5. **Comments carry the design** — For non-obvious gaps, use block comments: intent, tradeoffs in one line each, and “would pull from X” or “would call Y”. The code is a skeleton; the comments are the spike.## Optional small stepIf—and only if—a pattern is **already established** in this codebase and copying it is a **few lines** with a clear file reference, you may add that tiny slice. Otherwise leave a comment and stop.## How to finish the turnAfter the stubbed code:1. List **numbered comment anchors** (or map to line ranges) for each place you left a real decision.2. **Prompt one decision at a time** — e.g. “For (1): option A vs B; which direction?” Wait for an answer before assuming the next.Do not dump a long questionnaire; one focused question per ambiguous comment unless the user asks for a batch.## Anti-patterns for spikes- Choosing frameworks, folder layout, or new types “for cleanliness.”- Filling in error handling, tests, or production edge cases.- “Making it compile” across the monorepo when the user wanted exploration only.If scope is unclear, spike the **smallest** file or function they pointed at and ask one clarifying question.

Frequently asked questions