/launch-tier

name: launch-tier
description: "Classify releases into launch tiers and plan go-to-market. Based on Lauchengco's Loved framework."
metadata:
  instruction_budget: "62"
  framework_dependency: "mycelium"
  framework_dependency_note: "This skill is designed to run within the Mycelium framework (https://github.com/haabe/mycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: /plugin install mycelium@haabe-mycelium."

Launch Tier Classification

**The instrument is Lauchengco's RELEASE SCALE, and this skill had it wrong until 2026-09-20.** Corrected after reading *LOVED* chapter 12 directly. What the book actually says:

> *"Developing a shared understanding of how a release should be categorized and what go-to-market > activities will get done is the purpose of a Release Scale. It's a simple tool whose **sole purpose > is to create shared vocabulary and expectations** between the product and go-to-market teams."* > *"**This is different from a detailed organizational plan** for every action needed for a product > launch."*

**Three consequences for how this skill is used.**

1. **THE SCALE IS BUILT, NOT ADOPTED.** Her step 1: *"Decide on the calibration scale. **Be it levels, grades, names, numbers, or tiers**, I encourage using something that doesn't require a legend for people to understand."* Tiers are one of five options **the user picks** — not the instrument. Her worked example runs to **Level 5** (*"it's important for the company to have one or two Level 5 releases a year"*), not three. 2. **CALIBRATE ON YOUR OWN PAST RELEASES — she flags this as the most-skipped step.** Step 2: *"Use known past releases as examples to define the levels. **This is an important and often missed step. Don't make this an academic exercise of a potential future release.** By using known reference points, people have a known comparison to calibrate from."* **So a project with no release history cannot build a release scale yet, and a generic table handed to it is precisely the academic exercise she forbids.** Say so rather than filling one in. 3. **IT IS AN ALIGNMENT TOOL, NOT A GATE.** Its job is shared vocabulary between functions. A solo builder has no second function to align with; the honest reduced form is the *customer-impact* and *marketing-objective* questions (her steps 3 and 4), which one person can answer, without the resourcing, lead-time and planning-meeting steps (5–7) that assume a company.

**Her definitions, which this skill did not carry** — *"A **release** makes public a new product or combination of features that provides value to customers"*; *"For go-to-market teams, a **launch** is a major, cross-functionally supported release that the entire company gets behind. It's usually oriented around a set date… **Most companies won't attempt more than one to two major launches a year**."*

The table below is **an example calibration, not the scale** — use it to see the shape, then build your own from your own history. Source: Lauchengco (*Loved*, ch. 12).

Preflight: Read target canvas file(s) before any Write/Edit

**Hard rule.** Before issuing `Write` or `Edit` against any `.claude/canvas/*.yml`, use the **Read tool** on that file in this session. Claude Code's Read-before-Write check requires the `Read` tool specifically — `cat`/`head`/`grep` via Bash do NOT satisfy it.

**Edit vs Write — different cost profiles** (verified 2026-05-14):

• **`Edit`** (exact-string replacement): `Read` with `limit: 1` satisfies the check at ~50 tokens. State-tracking is per-file, not per-byte — subsequent `Edit` calls work anywhere in the file. Use this for partial updates against large canvas files (e.g., `purpose.yml` at 800+ lines).
• **`Write`** (full replacement): do a **full Read** first. Write obliterates the file; you should see what you're about to replace. The `limit:1` shortcut is *not* appropriate here.

**ID-bearing entries — scan the ID space before assigning** (added 2026-05-15, v0.23.19): When adding a new component, opportunity, solution, or any other ID-bearing entry to a canvas file, run a Bash grep first to confirm the next ID in your prefix sequence is actually free:

grep -o "<prefix>-[0-9][0-9]*" .claude/canvas/<file>.yml | sort -u -t- -k2 -n | tail -3

Replace `<prefix>` with the canvas's ID prefix (`comp` for landscape, `opp` for opportunities, `sol` for solutions, `ht` for human-tasks, etc.). Then pick the next free integer, **matching the zero-padding already used in that file**. The sort is NUMERIC (`-t- -k2 -n`) rather than lexical, and that is not pedantry: a plain `sort -u` orders `ht-1` after `ht-080`, so on a canvas with inconsistent padding it reports the wrong maximum and the next ID collides. Verified on the dogfood repo 2026-08-13, where lexical sort returned `ht-1` as the highest human-task ID against an actual `ht-080`. `grep -o` is also deliberate: it matches IDs wherever they appear, including cross-references and prose, so an ID that was promised somewhere but not yet defined is not handed out twice. `validate_canvas.py` has a per-file duplicate-ID check (it reports `duplicate id '<id>'`) that catches the failure on CI, but a duplicate can persist in the working tree for days if CI isn't run between edit and discovery; that happened on 2026-05-15, when a duplicate ID was created in `landscape.yml`.

Original failure mode: anti-pattern #7 instance #5, 2026-05-09 — agent conflated Bash `head` with the Read tool, lost ~14k tokens to a Write-fail → remedial-full-Read → re-Write loop. The `limit:1` discipline (graduated 2026-05-14, v0.23.18) prevents the second-order cost where the agent *correctly* follows the rule but full-Reads every time. The ID-scan discipline (graduated 2026-05-15, v0.23.19) prevents the related class where the agent reads enough of the file to satisfy the Edit check but not enough to see existing ID assignments — kin to anti-patt