Prototype spike
Skill stark-ai-de/agent-skills/incubator/skills/engineering-workflows/prototype-spike
Public Agent Skills for Codex operations, Cursor operations, Claude operations, repo maintenance, skill maintenance, productivity, and engineering workflows.
npx -y skills add stark-ai-de/agent-skills --skill prototype-spikeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 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.
What its author says it does
Copied from the file, not written here
Build or plan an explicitly throwaway prototype to answer a design, API, UX, performance, or integration question, then capture findings and cleanup. Use when the user asks for a spike, prototype, proof of concept, or experiment before committing to production design.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.9 KB, as published. Nobody here has run it
Prototype Spike
Goal
Answer a specific uncertainty with a deliberately bounded prototype, then either discard it or convert only the proven idea into production work.
When to use
- The user asks for a spike, proof of concept, prototype, or throwaway experiment.
- A design choice needs evidence before production implementation.
- An integration, API, performance assumption, or UI interaction is uncertain.
When not to use
- The user needs production-ready implementation now.
- The uncertainty can be answered by reading docs or existing code.
- The prototype would require secrets, real customer data, or irreversible operations.
Inputs to inspect
- The exact question the prototype must answer.
- Existing architecture, ADRs, validation commands, and domain docs.
- Constraints on where prototype files may live and how they should be cleaned up.
Workflow
- State the hypothesis or design question.
- Define the prototype boundary, timebox, and throwaway location.
- Ask before adding dependencies, new services, or files outside an agreed scratch area.
- Build the smallest experiment that answers the question.
- Record findings, limitations, and production implications.
- Clean up throwaway files or clearly mark what should remain.
- Recommend whether to proceed, revise, or abandon the production approach.
Safety rules
- Do not ship prototype code as production code without a review step.
- Do not add persistent dependencies or config unless approved.
- Do not use live credentials, customer data, or destructive operations in a spike.
- Do not leave scratch files unmarked or unexplained.
References
No bundled references. Use local ADRs and domain docs when the spike tests an architectural assumption.
Scripts
No bundled scripts.
Output format
Return:
- Question or hypothesis
- Prototype boundary and files touched
- Evidence gathered
- Decision recommendation
- Cleanup performed or remaining
- Production follow-up tasks
Completion criteria
- The prototype answers the stated question or explains why it could not.
- Throwaway work is cleaned up or explicitly marked.
- The production recommendation is separated from experimental code.
- Risks and follow-up tasks are documented.
Failure modes
- If the question is not measurable, refine it before coding.
- If the prototype starts becoming production work, stop and ask for scope confirmation.
- If cleanup cannot be completed, report exact files and next action.