Menu
Classify releases into launch tiers and plan go-to-market. Based on Lauchengco's Loved framework.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use to evaluate the current state of a diamond. Checks theory gates, confidence levels, and recommends next action.
Use when building anything USER-FACING (or with persuasion/retention/cancellation/consent/pricing flows, or that touches vulnerable people) to surface design-level harm the security/privacy/compliance gates miss: dark/deceptive patterns and foreseeable misuse. Assumes the product works as designed and asks who it could harm and whether it is Happier-negative. NUDGE, not a block.
Lint canvas files for staleness, missing fields, inconsistent evidence types, and orphaned references. Run periodically or before major transitions.
Accessibility audit against WCAG 2.1 AA. Checks semantic HTML, ARIA, keyboard navigation, color contrast, screen reader compatibility.
Design the smallest viable test to validate or invalidate a critical assumption. Based on Torres's assumption testing framework, organized by Gilad's AFTER model (Assessment → Fact-Finding → Tests → Experiments → Release Results).
Use before any research activity or significant decision. Reviews cognitive biases relevant to the current stage.
| 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."} |
Every release gets classified before planning begins. Source: Lauchengco (Loved).
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 "^ - id: <prefix>-" .claude/canvas/<file>.yml | sort -u
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. validate_canvas.py has a duplicate-ID check (lines 230-239) 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 — see roadmap-repo corrections.md 2026-05-15 "Duplicate canvas ID created in landscape.yml" for the worked example.
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-pattern #8 (Stale State Read).
If this skill writes to multiple canvas files, register each one first (limit:1 for Edit-only paths; full Read for Write paths) AND ID-scan any prefix you intend to assign.
See CLAUDE.md Canvas writes — Read before Write for the canonical rule.
| Tier | Type | Effort | Examples |
|---|---|---|---|
| 1 | Major | Full cross-functional | New product, major pivot, category-defining |
| 2 | Significant | Targeted campaigns | Feature launch, positioning reinforcement |
| 3 | Incremental | Lightweight | Bug fixes, minor improvements, release notes |
Tier 1: Press, events, campaigns, sales enablement, analyst briefings, customer advisory Tier 2: Blog post, targeted campaigns, sales enablement update, in-product announcement Tier 3: Release notes, changelog, in-product notification, knowledge base update
Tier 1: Platform launch (new course on marketplace), PR/media coverage, launch webinar, guest appearances Tier 2: New module/section, cross-promotion, community announcement, guest post Tier 3: Content update, errata fix, supplementary material, minor revision
Tier 1: Public launch, ProductHunt/HackerNews, documentation site, demo video Tier 2: New capability/model, integration partnership, case study Tier 3: Prompt improvement, model update, bug fix, eval result improvement
Tier 1: New service line launch, case study PR, conference talk, partnership announcement Tier 2: New package/tier, testimonial campaign, process improvement announcement Tier 3: Pricing update, workflow refinement, expanded availability
Use biases ETHICALLY to help users understand value:
Update .claude/canvas/go-to-market.yml with tier classification and launch plan.
Eyal's work spans two complementary books: Hooked (2014) provides the Hook Model for building habit-forming products; Indistractable (2019) provides the user-side framework for managing attention. The Manipulation Matrix below bridges both — ethical engagement design means building hooks that users would choose even with full information.
The Hook Model is most relevant at L3 (Solution design) for engagement architecture, not just L5 (Market). Apply during solution design when the product requires recurring usage.
For products that need user retention, design engagement ethically using the Hook Canvas:
Map the four components of habit formation:
Before implementing engagement design, answer honestly:
| User Benefits | User Doesn't Benefit | |
|---|---|---|
| Maker Uses It | Facilitator (ethical) | Entertainer (proceed with caution) |
| Maker Doesn't Use It | Peddler (risky) | Dealer (unethical — do not build) |
Only Facilitator products should be built without reservation. Entertainers need honest self-assessment. Peddlers and Dealers trigger anti-pattern #10 (Dark Pattern Marketing).
Update .claude/canvas/go-to-market.yml engagement_design section with Hook Canvas results.
Source: Eyal (Hooked), with ethical framework from the Manipulation Matrix
Before classifying a launch tier, run /mycelium:bias-check for L5-specific biases:
If /mycelium:bias-check reveals significant biases, address them before finalizing the launch tier.
This is critical. After launch, market feedback must flow back into discovery:
Capture market signals (within 2-4 weeks post-launch).
Check the product-type-appropriate metrics canvas via /mycelium:dora-check:
Software: feature usage, retention, conversion, support tickets, NPS/CSAT Content: refund rate, completion rate, drop-off points, return rate, reviews, NPS AI tool: task success rate, retention, DAU, refund rate, user feedback Service: client satisfaction (NPS/CSAT), referral rate, retention, delivery lead time feedback
Validate scenarios against reality (Hoskins):
.claude/canvas/scenarios.yml linked to this launch: did the persona's story play out?lifecycle.validated_in_market: confirmed, partial, or invalidatedEvaluate against L2 assumptions:
.claude/canvas/scenarios.yml?Feed back into discovery:
validated, celebrate validated learninginvalidated, update corrections.mdThis closes the full Mycelium loop: Purpose -> Strategy -> Discovery -> Solution -> Delivery -> Market -> Discovery.
After launch feedback is captured (L5 → L2 loop), update the cycle record in .claude/canvas/cycle-history.yml:
/mycelium:retrospective at delivery completion)/mycelium:metrics-pull where possible (v0.14): 24-48h after launch to capture the bump, then weekly for the first month. Snapshots live at .claude/evals/metrics/<source>/*.json. This replaces manual "I checked the dashboard" reports with timestamped evidence..claude/jit-tooling/active-metrics.yml has no configured source for the relevant channel, run /mycelium:metrics-detect first.If no cycle record exists yet (leaf went directly to market without retrospective), create one now.
This closes the data loop: predicted ICE → actual delivery metrics → actual market outcomes → calibration for future scoring.
APPEND a ### Launch Tier Classification entry to .claude/harness/decision-log.md with: tier assigned, positioning rationale, key risks, go-to-market approach.
Before finalizing the launch tier classification AND before drafting any positioning copy, draft a one-line counter-argument: "What's the strongest case that this is a smaller tier than I'm claiming? That this positioning is overstating impact? That market readiness is weaker than the evidence suggests?" If you can't articulate one, run /mycelium:devils-advocate before proceeding.
This addresses the bias cluster documented in corrections.md (L5 sycophancy 2026-04-20 — promotional language in decision logs at L5 — explicitly named this skill's domain; eval overfitting 2026-04-30; sharper-framing-isn't-righter 2026-05-03). L5 work is the highest-risk context for bias because the framing pressure is explicit ("we're going to market"). G-M1 catches the WORST language, but bias appears in subtler tier-classification and positioning choices that G-M1 doesn't see. The counter-argument is the upstream check.
Hard rule (per CLAUDE.md Communication Rules, anti-pattern #7 write-narration-verification — mechanism Check 42, graduated v0.39.18; enforced surface expanded to this skill v0.44.0). This skill mandates multi-field canvas updates. Before narrating "updated / wrote / refreshed [canvas]" in any user-facing summary, RE-READ the value fields this skill's MANDATORY says to update and confirm they actually changed — not just _meta.last_validated or a freshness stamp. Each field you claim to have updated must reflect its new value. The symmetric half of the Read-before-Write Preflight: that one protects what gets read before a write; this one protects that the write matches the claim. Worked failures: 2026-06-05 #18 (/dora-check narrated "updated" with value fields unchanged) + #19 (/retrospective left a cycle-history aggregate un-propagated).