land

Guides spike experiments to an explicit toss, keep, or promote outcome.

Updated Apr 13, 2026
One-click install
npx skills add https://github.com/scoots31/engineering-playbook --skill land-scoots31
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: land
Source: https://github.com/scoots31/engineering-playbook/tree/main/skills/land
Command: npx skills add https://github.com/scoots31/engineering-playbook --skill land-scoots31

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Experimental spikes often drift silently into production without a deliberate decision, leaving prototype hacks in shipped code. This Skill forces every spike to end with an explicit landing decision so nothing becomes a product by accident. ## Core Features & Use Cases - Three exit outcomes: Toss (capture the learning, archive the code), Keep (one-pass hygiene for a personal tool), or Promote (prepare a handoff brief and enter the full build framework). - Honest challenge conversation: Pushes back when the stated outcome conflicts with the evidence, such as a "Keep" that mentions users or a "Promote" built on a shaky result. - Learning capture: Writes spike summaries and tool records to MemPalace so experiments are never repeated and personal tools stay discoverable. - Use Case: After a weekend prototype proves an idea works, run the landing conversation to decide whether to archive it, freeze it as a personal utility, or promote it into a proper discovery and build cycle. ## Quick Start Ask the assistant to land the current spike and walk through the toss, keep, or promote decision.

Frequently Asked Questions about land

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide what to do with a finished code spike?

Run a landing conversation that asks directly whether to toss, keep, or promote the spike. Toss archives the code and records the learning, keep freezes it as a personal tool after one hygiene pass, and promote hands it to the full build framework with a brief.

What should I do before promoting a prototype into a real product?

Stop treating the spike code as a foundation and prepare a handoff brief covering what it proved, what exists versus what is missing, scope signals from graduation triggers, and known hacks that must not survive promotion.

How do I keep a prototype as a personal tool without over-engineering it?

Do one hygiene pass: rename temp files, add a one-line header explaining what it does and how to run it, remove hardcoded secrets, and re-run it end-to-end. Then freeze it and resist further cleanup.

Why do side projects end up full of prototype hacks in production?

Spikes silently become shipped products when no explicit landing decision happens. The fix is a mandatory end-of-spike conversation that forces a toss, keep, or promote choice, with no deferral allowed.

When should I toss a spike instead of keeping it?

Toss when the spike did not work or worked but is not worth maintaining. The outcome is the learning: summarize what was tried, what happened, and what it means, record it as a spike memory, then archive or delete the code.