Launchpad - Feature Delivery as a Four-Step Flow Inside Claude Code

TL;DR

Launchpad is a Claude Code plugin that was built to make feature delivery a repeatable, four-step flow instead of a fresh round of prompt roulette. You type /launchpad-brain and the plugin walks you through Q&A, design, implementation, and testing - in that order - while persisting everything to disk so a feature survives a /clear, a new session, or coming back next week.

It’s an opinionated, narrow agentic SDLC, packaged as a single installable Claude Code plugin - the same packaging idea behind Claude Sauce, applied to one tight workflow.

Repo: github.com/Formartha/launchpad.

Why it was built

The same problem keeps biting every team that uses Claude Code seriously:

• Each feature starts from a blank prompt
• Context drifts mid-feature, then /clear wipes the conclusions
• The next person (or the next day’s you) has no idea what was decided, what was rejected, or what’s half-built
• Everyone re-invents their own prompt rituals for “plan -> design -> code -> test”

Three problems, all solvable by structure: a fixed workflow, persistent artifacts, and skills that know which phase they’re in. That’s Launchpad.

The four slash commands

The whole user-facing surface is four commands. Each one corresponds to a phase. Each one writes its output to disk before handing off.

The contract between phases is files, not conversation. /launchpad-architect reads REFERENCE.md and emits FEATURE.md. /launchpad-implement reads FEATURE.md and starts cutting code. The model never has to remember what was decided three sessions ago; the files do.

Between each phase there’s an explicit “continue or resume later?” gate. Stop anywhere, come back next week, type the same slash command, and the plugin picks up where it left off.

What gets persisted

Launchpad creates a .launchpad/ directory at the repo root:

.launchpad/
├── PROJECT.md                  project knowledge base
├── features/
│   └── [feature-name]/
│       ├── STATE.md            phase tracking (managed by launchpad-state only)
│       ├── REFERENCE.md        what to build (from your answers)
│       └── FEATURE.md          how to build it (from architect)
└── completed/
    └── [feature-name]/         archived features (not scanned)

Two things matter here:

1. STATE.md is the source of truth for “where are we in this feature.” Only one internal skill (launchpad-state) is allowed to touch it. Every other skill reads it. That single-writer rule is what keeps the workflow honest across sessions.
2. completed/ is intentionally not scanned. When a feature ships, it moves out of features/. Tomorrow’s session doesn’t pay tokens to re-read finished work - the same context-frugality mindset I cover in Claude Code on a token diet.

The two internal skills (the part most people skip)

There are two non-user-facing skills doing the unsexy load-bearing work:

• launchpad-state owns the lifecycle of STATE.md. Read protocol, write protocol, what counts as a valid phase transition. Nobody else writes that file. That’s the entire reason the four phases don’t collide.
• launchpad-elicit is a shared Q&A protocol. Ask, reflect, confirm, adjust. Every elicitation phase uses it - whether you’re in brain gathering requirements or in architect clarifying a design call. One discipline, four phases.

These are the parts that, if you tried to vibe-code this kind of workflow yourself, you’d skip - and then wonder six weeks later why your “plan -> build -> test” agent feels chaotic.

Install and try it

Inside any Claude Code session:

/plugin marketplace add Formartha/launchpad
/plugin install launchpad@launchpad
/reload-plugins

Then in any repo:

/launchpad-brain

It scans the project, asks the questions, writes PROJECT.md and REFERENCE.md, and offers to continue to /launchpad-architect. You can stop at any gate.

What it does, what it doesn’t

Does well:

• Turning a vague “add X somewhere” wish into a structured REFERENCE.md + FEATURE.md worth attaching to a PR
• Surviving context resets - features live on disk, not in the conversation buffer
• Making the design phase visible and editable instead of buried in chat scrollback
• Keeping completed features out of the active context (cheaper sessions)
• Handling epics as a set of independent slices. Each slice gets its own folder under features/. Slices aren’t bound to a fixed sequence - build and test them in any order, archive them as they ship, and the rest of the epic stays unaffected.

Doesn’t pretend to:

• Replace your judgment. The gates between phases exist because you should still read what was decided before saying “continue.”
• Run headless. The phases are conversational by design; you’re meant to look at the questions and answer them.

If you try it on a real feature, the moment it earns its keep is usually phase 2 - /launchpad-architect produces a FEATURE.md you’d be happy to attach to a PR description. That alone is worth the install.

Status

Launchpad is under active development. Commands, file layout, and phase boundaries can change as the workflow tightens up - pin a commit if your team relies on a specific behavior.

Contributions are welcome: issues, PRs, and proposals for new phases or templates. The repo lives at github.com/Formartha/launchpad. If something breaks or feels wrong on real-world use, that’s exactly the feedback worth opening a ticket for.