Skip to content
Development
Skill

/prototype

Executes a rapid prototyping workflow that skips normal standards to quickly validate a product concept or core mechanic, producing throwaway code and a prototype report. Use when the user wants to quickly test an idea or mentions prototyping, proof of concept, or MVP spike.

From plugin
software-development-department
72116 skills28 agents1 MCP
Install
$ npx -y skills add tranhieutt/software_development_department --skill prototype --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/prototype

Context preview

The summary Claude sees to decide when to auto-load this skill.

Executes a rapid prototyping workflow that skips normal standards to quickly validate a product concept or core mechanic, producing throwaway code and a prototype report. Use when the user wants to quickly test an idea or mentions prototyping, proof of concept, or MVP spike.

SKILL.md

prototype.SKILL.md
name: prototype
type: workflow
description: "Executes a rapid prototyping workflow that skips normal standards to quickly validate a product concept or core mechanic, producing throwaway code and a prototype report. Use when the user wants to quickly test an idea or mentions prototyping, proof of concept, or MVP spike."
argument-hint: "[concept-description]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Bash
effort: 3
when_to_use: "Use when the user wants to quickly validate a product concept or core mechanic before committing to full implementation, or mentions prototyping, proof of concept, or MVP spike."

When this skill is invoked:

1. **Read the concept description** from the argument. Identify the core question this prototype must answer. If the concept is vague, state the question explicitly before proceeding.

2. **Read CLAUDE.md** for project context and the current tech stack. Understand what engine, language, and frameworks are in use so the prototype is built with compatible tooling.

3. **Create a prototype plan**: Define in 3-5 bullet points what the minimum viable prototype looks like. What is the core question? What is the absolute minimum code needed to answer it? What can be skipped?

4. **Create the prototype directory**: `prototypes/[concept-name]/` where `[concept-name]` is a short, kebab-case identifier derived from the concept.

5. **Implement the prototype** in the isolated directory. Every file must begin with:

   // PROTOTYPE - NOT FOR PRODUCTION
   // Question: [Core question being tested]
   // Date: [Current date]

Standards are intentionally relaxed:

  • Hardcode values freely
  • Use placeholder assets
  • Skip error handling
  • Use the simplest approach that works
  • Copy code rather than importing from production

6. **Test the concept**: Run the prototype. Observe behavior. Collect any measurable data (frame times, interaction counts, feel assessments).

7. **Generate the Prototype Report** and save it to `prototypes/[concept-name]/REPORT.md`:

## Prototype Report: [Concept Name]

### Hypothesis
[What we expected to be true -- the question we set out to answer]

### Approach
[What we built, how long it took, what shortcuts we took]

### Result
[What actually happened -- specific observations, not opinions]

### Metrics
[Any measurable data collected during testing]
- Frame time: [if relevant]
- Feel assessment: [subjective but specific -- "response felt sluggish at
  200ms delay" not "felt bad"]
- User action counts: [if relevant]
- Iteration count: [how many attempts to get it working]

### Recommendation: [PROCEED / PIVOT / KILL]

[One paragraph explaining the recommendation with evidence]

### If Proceeding
[What needs to change for a production-quality implementation]
- Architecture requirements
- Performance targets
- Scope adjustments from the original design
- Estimated production effort

### If Pivoting
[What alternative direction the results suggest]

### If Killing
[Why this concept does not work and what we should do instead]

### Lessons Learned
[Discoveries that affect other systems or future work]

8. **Output a summary** to the user with: the core question, the result, and the recommendation. Link to the full report at `prototypes/[concept-name]/REPORT.md`.

Important Constraints

  • Prototype code must NEVER import from production source files
  • Production code must NEVER import from prototype directories
  • If the recommendation is PROCEED, the production implementation must be

written from scratch -- prototype code is not refactored into production

  • Total prototype effort should be timeboxed to 1-3 days equivalent of work
  • If the prototype scope starts growing, stop and reassess whether the

question can be simplified

Protocol

  • **Question**: Reads concept from argument; if vague, states the core hypothesis explicitly before proceeding
  • **Options**: Skip
  • **Decision**: Prototype plan (3-5 bullets) shown and confirmed before implementation begins
  • **Draft**: REPORT.md summary shown before saving
  • **Approval**: "May I create `prototypes/[concept-name]/` and implement the prototype?"

Output

Deliver exactly:

  • **Prototype code** in `prototypes/[concept-name]/` (throwaway — never imported by `src/`)
  • **Report** saved to `prototypes/[concept-name]/REPORT.md`
  • **Hypothesis verdict**: `VALIDATED` / `INVALIDATED` / `INCONCLUSIVE`
  • **Recommendation**: `PROCEED` (rewrite from scratch in `src/`) / `PIVOT` / `ABANDON`
Read more
Ships withsoftware-development-department

Software Development Department

Get the whole plugin