---
name: loom-prototype-and-spike
description: "Use when the next step is building a disposable prototype/spike to answer a specific design, state-model, UI, interface, or integration question before committing production implementation."
---

# loom-prototype-and-spike

Prototype and spike is an exploration playbook.

It builds the smallest disposable artifact that answers a question, records the
answer, and then deletes, absorbs, or routes the result.

## Core Dependency

Use `loom-core` first. This playbook composes `loom-research`, `loom-evidence`,
`loom-specs`, `loom-constitution`, `loom-knowledge`, `loom-tickets`, and
`loom-audit`.

Prototype code is not production work unless a later ticket deliberately absorbs
it.

## Use This Playbook When

Use this playbook when:

- the operator asks to prototype, spike, sanity-check, or try options
- a state machine or data model is hard to reason about on paper
- UI direction needs visible alternatives before implementation
- interface shape is uncertain and examples would clarify it
- an integration assumption needs fast proof before planning
- a design decision would be expensive to reverse after full implementation

Skip it when existing source, specs, or tests can answer the question cheaply.

## Route

Use this route:

```text
question -> branch -> build throwaway -> observe -> decide -> preserve answer -> delete or absorb
```

## Question

Name the question before building.

Good prototype questions are specific:

- Does this state model produce understandable transitions?
- Which UI direction communicates the workflow best?
- Can this API shape express the common case simply?
- Does this library support the required integration path?

If the question is broad or vague, route to `loom-idea-refine`,
`loom-domain-language-and-decisions`, or `loom-research` first.

## Branch

Choose the prototype shape that answers the question.

Common branches:

- logic prototype: tiny runnable CLI, script, fixture, reducer, or state-machine
  harness for behavior and data questions
- UI prototype: several visibly different variants, reachable from one temporary
  route or switcher, for layout and interaction questions
- interface prototype: sample caller code and type shape for contract questions
- integration spike: minimal request, adapter, or fixture for source compatibility

State assumptions at the top of the prototype when the operator is not available
to choose.

## Build Throwaway

Keep the artifact disposable from the start.

Rules:

- mark prototype files clearly as temporary
- place them near the relevant area only when that improves context
- provide one command or route to run it
- avoid persistence unless persistence is the question
- skip polish, broad error handling, and reusable abstractions
- surface state after each action or variant switch
- do not add production tests unless the prototype is being absorbed deliberately

Keep the prototype out of ticket scope unless the ticket explicitly asks for a
prototype.

## Observe

Capture the observation that answers the question.

Useful evidence:

- command output
- screenshot or browser observation
- state transition transcript
- variant comparison
- source behavior or compatibility note
- operator verdict

Use `loom-evidence` when the observation supports a later spec, decision, ticket,
or audit claim.

## Decide

Turn the observation into a route:

- update a spec when intended behavior or interface becomes clear
- update research when the answer is exploratory or source-grounded
- create a constitution decision when the result is hard to reverse and precedent
  setting
- create or update knowledge when the learning should be reused
- create a ticket when the prototype should be absorbed into production work
- abandon when the prototype invalidated the idea

## Delete Or Absorb

Do not leave prototype code rotting.

Choose one:

- delete after the answer is recorded
- absorb through a scoped ticket with production-quality tests and review
- keep temporarily with a ticketed expiration or cleanup owner

If absorption happens, treat it as implementation work. Prototype code does not get
grandfathered into production quality.

## Done Means

The prototype pass is done when:

- the question was explicit
- the artifact was scoped and marked as disposable
- the observation or operator verdict was captured
- durable learning moved to the right Core record
- prototype code was deleted, absorbed through a ticket, or given an explicit
  cleanup route