Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/danielvm-git/bigpowers/spike-prototypegit clone --depth 1 https://github.com/danielvm-git/bigpowersWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/danielvm-git/bigpowers/spike-prototype)<a href="https://agentmods.dev/rules/danielvm-git/bigpowers/spike-prototype"><img src="https://agentmods.dev/badge/rules/danielvm-git/bigpowers/spike-prototype.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00064 | $0.00753 |
| Opus 5 | $0.00032 | $0.00377 |
| Sonnet 5 | $0.00013 | $0.00151 |
| Haiku 4.5 | $0.00006 | $0.00075 |
Grade A, and why
spike-prototype scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spike Prototype
HARD GATE — HARD GATE — Spikes are time-boxed experiments, not shipping code. Results must be throwaway or clearly isolated. Do NOT merge a spike without a plan to integrate it or replace it with a proper implementation.
A spike is a time-boxed experiment to answer a specific question. The code is thrown away. The learning is kept in specs/archive/spikes/SPIKE-<name>.md.
The spike produces learning, not code to ship. If you find yourself cleaning up spike code for production, stop — run plan-work and develop-tdd instead with the insights you gained.
When to spike
- The technology is unfamiliar (new library, API, infrastructure)
- The approach is uncertain (multiple solutions exist; none has been tried)
- Estimates are impossible without seeing how the thing actually behaves
- A key assumption needs to be validated before committing to a design
Process
1. Define the question
Before writing a single line, state the question the spike must answer:
"Can we [specific thing] using [specific approach] within [constraint]?"
Examples:
- "Can we stream large files from S3 to the client without buffering in memory?"
- "Does the Stripe webhook SDK handle signature verification correctly in our edge runtime?"
- "Can we achieve < 100ms p99 response time for the search endpoint with a naive Postgres full-text search?"
A spike with no question is just unplanned coding. Refuse to start if the question isn't clear.
2. Set a timebox
Agree on a timebox with the user: 30 minutes, 1 hour, 2 hours. When time is up, stop — even if the question isn't fully answered. Partial learning is still learning.
3. Experiment
Write the simplest code that could answer the question. Ignore:
- Error handling
- Test coverage
- Code quality
- Production concerns
Focus entirely on answering the question.
4. Write specs/archive/spikes/SPIKE-.md
Save the learning to specs/archive/spikes/SPIKE-<name>.md. Create the specs/ directory if it doesn't exist.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today First seen · 95 lines · 64 tokens per session scan A f41274b5bcb3
spike-prototype is a cursor rule published in the GitHub repository danielvm-git/bigpowers (162 stars, last pushed 2d ago), licensed MIT. It adds 64 tokens to every session and 753 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other cursor rules, from other repositories
agent-efficiency
Agent-mode tool-call efficiency. Cuts the largest hidden cost in modern AI IDEs — wasted tool calls and oversized context windows.
pudo-core
Core PUDO workflow rules for all Cursor agent work.
multi-agent-coordination
Multi-agent coordination and workflow standards.
dynamic-confirmed-list
Enforces automatic creation and management of a dynamic confirmed list for explicit, structured, and precise interactions between Cursor AI and users.
reply-tracker
Reply Tracker (also known as Reply Zero) lets the user which emails need a reply for them and those they're awaiting a reply on. It updates the labels for the thread automatically in Gmail.
git-workflow
Git workflow: commits, branches, PRs, history management.