spike-close

To close a GitHub spike issue after a technical investigation, you must disposition it by either promoting the findings into a new production-shaped [Feature] ticket or discarding the spike with a lasting memo artifact. This prevents half-shipped exploration from lingering in the main workflow.

The best way to document learnings from a discarded engineering spike is to generate a disposition memo. The system derives a stable slug from your concise summary and writes a durable memo artifact to `docs/spike-memos/<slug>.md`, then closes the spike with a cross-link to the memo.

To promote a spike into a production feature ticket, the workflow collects a feature title, scope, and explicitly what is not carried over. It then creates a new [Feature] issue, cross-references the original spike, and closes the investigation ticket safely.

Yes, the spike closure workflow validates GitHub issue metadata before processing. It confirms the target issue is actually a spike by checking for the `[Spike]` title prefix or the `spike` label, and warns the operator if the issue is already closed.

Engineering spikes need a formal disposition process in the SDLC to avoid leaving confirmed-but-untracked exploration in the main workflow. Forcing a clear PROMOTE or DISCARD decision ensures production work is launched or learnings are locked in a memo.

You should discard a spike instead of promoting it when the time-boxed technical investigation proves an approach is unviable or out of scope. Discarding captures the learnings in a durable memo artifact to prevent re-running the same exploration later.