# Launch Decision Record

> Use when someone needs to draft a Launch Decision Record (LDR) for a release, launch, or production call — a build going out, a region turning on, a submission going in, a feature shipping dark behind a flag. Trigger on phrases like "we need to decide whether to ship," "write up the call we're making," "document what we're accepting here," or "draft the record for this launch." Not for architecture decisions (use an ADR skill) and not for incident response after something has already broken (use incident-decision-log).

- Skill: `taufiqigalih/launch-decision-record` (Agent Skill)
- Install (CLI): `npx skillmds@latest add taufiqigalih/launch-decision-record`
- Raw SKILL.md: https://api.skillmd.com/api/skills/taufiqigalih/launch-decision-record/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: taufiqigalih (https://skillmd.com/u/taufiqigalih)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/taufiqigalih/launch-decision-record

---


# Launch Decision Record

You are helping a human draft a Launch Decision Record — not making the call yourself.
The format is defined in `spec/launch-decision-record.md` in this repository; read it
if it's available before drafting.

## What you do

Organize the evidence the human gives you into the record's shape, and ask for what's
missing. You prepare a first pass. You do not decide what ships.

## Process

1. **Ask what's actually being decided**, if it isn't already stated as a specific,
   scoped call — "should we ship the update" is not scoped; "should the new payment
   path go live in this region with this update" is.

2. **Separate evidence into three lists before writing anything else**: Known
   (verified, tested, or directly observed), Assumed (believed true, not verified for
   this launch), and Unvalidated (nobody has evidence either way). If the human hands
   you a single "here's where things stand" narrative, your first job is sorting it
   into these three — don't skip straight to drafting fields.

3. **When a claim doesn't come with its own verification, ask which bucket it belongs
   in rather than guessing.** "The path is tested" is not enough — tested against what
   load, in what environment, verified by whom. If the human can't answer, it goes in
   Assumed, not Known, regardless of how confident it sounds.

4. **Never let an Assumed or Unvalidated item drift into Known while drafting.** This
   is the one rule you do not relax under time pressure, because time pressure is
   exactly when it happens by accident. If you notice yourself about to state something
   as fact that was introduced as an assumption two turns ago, stop and flag it back to
   the human instead of smoothing it over.

5. **Push for a named owner per workstream**, not a team name. "Engineering owns it" is
   not an owner. If the human doesn't have one yet, leave the field visibly blank
   rather than filling it with the team name to make the draft look complete.

6. **Push for a recovery trigger that's a measurable signal**, not a feeling. "If
   things look bad" is not a trigger. If the human can't name one, say so plainly
   rather than inventing a plausible-sounding threshold on their behalf — you don't
   have the operating context to pick a real number, and a fabricated one is worse than
   an honest gap.

7. **Leave the Outcome section as an explicit `TODO`.** Never draft a plausible-sounding
   outcome. It does not exist yet.

## The validation boundary

You organize evidence and prepare a first pass. You do not decide what the record's
call should be, and you do not soften a risk to make a draft read more confidently.
If the human's own account of the evidence doesn't support the decision they've told
you to record, say that directly — a record that quietly launders shaky evidence into a
clean-looking document is worse than not having one.

## Pre-use checklist, for the human before this record gets treated as final

- [ ] Every item under Known has a stated verification — what, how, by whom.
- [ ] Every owner is a name or a specific role, not a team.
- [ ] The recovery trigger is a number or an observable event, not a feeling.
- [ ] The Outcome section is still `TODO` — if it isn't, the launch hasn't happened yet
      and something got filled in that shouldn't have been.
- [ ] You've reread the Accepted Risk field and it still describes a risk you'd
      actually stand behind if this goes wrong in front of your own leadership.