feature-spike

name	feature-spike
description	Build the smallest decision-producing slice that validates a feature's value or technical feasibility before production investment. Use when a user asks for a feature spike, proof of concept, capability probe, or bounded experiment to decide whether or how to proceed. Do not use for comparing multiple UI directions, delivering an already-approved production feature, general research that needs no runnable evidence, production hardening, or experiments inside an established implementation.
license	MIT

Feature Spike

Produce evidence for a decision, not a miniature production feature.

Route the request

Use this skill when one important uncertainty stands between an idea and a production commitment, and a runnable slice can resolve it.

• Use code-native-ui-ideation when the decision is between multiple interface directions.
• Use feature-delivery when the product behavior is approved and the goal is production implementation and rollout.
• Handle an explicit hardening-only request directly under the repository's production instructions or a separately requested release-readiness capability.
• Use ordinary research or investigation when documentation, source inspection, or analysis can answer the question without building a probe.
• Use the project's existing experiment harness for parameter tuning inside an already-approved system unless the experiment determines whether the feature or architecture should exist at all.

Establish the decision contract

Inspect the repository, its instructions, and relevant current behavior before choosing the spike shape. Record a lightweight contract before implementation:

1. Decision: What commitment will this evidence inform?
2. Unknown: What value, capability, integration, performance, cost, or compatibility claim is uncertain?
3. Options: What would continue, change, stop, defer, or inconclusive mean?
4. Evidence: What observation would distinguish those options?
5. Validity: Under which conditions is the test conclusive, and which conditions make it invalid or inconclusive?
6. Decision rule: What accepted baseline or user-approved threshold supports each result?
7. Budget: What approved effort, time, data, sample, and external access may the spike consume?
8. Non-goals: What production behavior is deliberately excluded?
9. Disposition: Is the code throwaway, salvageable, or intended only as a contract fixture?

Do not invent a success threshold because one would be convenient. Derive it from current behavior, economics, platform constraints, or an explicit user decision. If a threshold is unknown, make establishing it part of the spike or report the result as directional.

Do not present an arbitrary timebox, audience size, sample size, or cost cap as settled. Use an existing constraint or give the decision owner a reasoned proposal to approve. Mark unapproved values as provisional.

When several unknowns share one spike, label each as a hard blocker, a scope-or-architecture modifier, or a commercial or exposure gate. Do not aggregate mixed evidence into one all-or-nothing rule unless the decision contract says those questions are jointly required.

Use the feature spike brief when the decision needs a durable handoff.

Choose the smallest decisive slice

Minimize work while preserving the uncertainty under test. The smallest build is not useful when it creates a falsely easy test.

• For a capability or integration probe, exercise the risky boundary end to end against a representative environment and data shape. Include denied, failed, and invalid-test paths when they affect the decision.
• For an architecture or performance proof of concept, extract one representative seam, compare the same work before and after, separate build and execution costs, repeat noisy measurements, and record coupling or migration friction alongside speed.
• For a product-value slice, expose one coherent experience to the smallest appropriate audience, use safe representative inputs, and capture behavior or judgment that bears directly on the value claim. Do not build production infrastructure merely to make the experiment look real. Base audience, sample, and observation-window proposals on the signal and stakes, and leave them provisional until the decision owner accepts them.
• For a platform or tool feasibility test, use the real extension point or runtime far enough to expose its constraints. A mock of the risky boundary cannot validate it.

Read evidence strategies when selecting data, fidelity, measurements, or validity conditions.

Build proportionally

• Keep the spike isolated and easy to inspect.
• Build only the paths needed to produce decision evidence.
• Use tests where they protect the measurement, encode a discovered contract, or prevent a false result. Do not impose strict TDD, worktrees, agent teams, or production ceremony unless the user explicitly requests them.
• Prefer synthetic, anonymized, development, or local data. Never copy raw production data, credentials, tokens, or personal information into fixtures or findings.
• Keep credentials in the project's approved local mechanism.
• Identify the active environment before external calls. Require explicit approval before live deployment, privileged mutation, paid resource creation, or destructive cleanup.
• Record failed attempts and invalid observations when they change confidence. Do not hide them behind a final green result.

Do not silently turn a throwaway probe into production code. If the spike code starts accumulating unrelated architecture, polished UI, broad abstractions, or release machinery, stop and return to the decision contract.

Evaluate the evidence

For every unknown, record:

Field	Meaning
Observation	What actually happened
Validity	Whether the test conditions made the observation conclusive
Result	Supported, rejected, directional, or inconclusive
Confidence	What was repeated or corroborated
Limitation	What this test still cannot establish
Consequence	What changes in the product or technical plan

Use one of these overall decisions:

• Continue: The evidence supports production investment.
• Change: Preserve the objective but revise the scope, architecture, or assumption before investing.
• Stop: The evidence rejects the investment under the current premise.
• Defer: The approach is promising, but timing, dependencies, or opportunity cost make implementation premature.
• Inconclusive: The test conditions could not answer the question. State the smallest valid next test instead of converting uncertainty into a pass.

Mixed results are normal. A spike can remove one backend, platform, or migration path while leaving the overall product worth pursuing.

Consider all five outcomes explicitly. State why defer does or does not apply when implementation timing, dependencies, or opportunity cost are material.

Stop when the evidence can support the named decision. Do not fill the remaining budget with adjacent implementation.

Hand off the result

Return:

• the decision contract and scope;
• the runnable probe or bounded slice;
• measurements, observations, and invalid attempts;
• a continue, change, stop, defer, or inconclusive decision;
• the resulting product or architecture consequences;
• unresolved evidence and its smallest valid test;
• the code disposition and any cleanup owner.

If the decision is continue, hand the evidence to feature-delivery. Production implementation, cross-repository coordination, release gating, deployment, and user exposure begin there only when the user asks to proceed.