agentleFS
Sign inStart free
carlkiblercarlkibler/agent-skills/skills/launch-sequence/SKILL.md

launch-sequence

Skill6 starsChanged 4 months agoMITView on GitHub

Run first-contact, support-storm, trust-audit, and pre-mortem for a launch verdict.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before any public launch, beta, or major feature release

    line 19
  2. Distinctive:

    When you want one command instead of four

    line 20
  3. Distinctive:

    When you need a board-ready risk summary

    line 21
  4. Distinctive:

    When you've already run all four constituent skills recently

    line 27
  5. Distinctive:

    Ask (or infer from context) the minimum needed to run the gauntlet:

    line 35
  6. Distinctive:

    If all four are clear from context, proceed immediately without asking.

    line 42
  7. Distinctive:

    After all four subagents complete, synthesize their findings:

    line 72
  8. Distinctive:

    If an analysis could not be run or came back thin, say so in the report and cap the verdict at CAUTION.

    line 90

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Launch Sequence

The pre-launch gauntlet. Chains four analysis skills into a single synthesized verdict so you can't accidentally skip one.

When to Use

  • Before any public launch, beta, or major feature release
  • When you want one command instead of four
  • When you need a board-ready risk summary

When NOT to Use

  • Bug fixes or small incremental changes
  • Pure internal tools with no new user-facing behavior
  • When you've already run all four constituent skills recently
<process>

Phase 1: Context Capture

Ask (or infer from context) the minimum needed to run the gauntlet:

  1. What — the product, feature, or launch being evaluated
  2. Who — the target user and how they discover/install it
  3. When — launch timeline (hard date? soft launch? beta?)
  4. Success — what does a good first week look like?

If all four are clear from context, proceed immediately without asking.

Phase 2: Parallel Analysis

Launch all four constituent analysis passes in parallel as in-session subagents (no external CLIs; nothing leaves the session). Each gets the same context brief plus its specific mandate. If the matching skill (first-contact, support-storm, trust-audit, pre-mortem) is installed, tell the subagent to follow it; otherwise the mandate below is enough. Ask each to return at most 7 findings, each tagged catastrophic / serious / minor with the evidence (file, screen, or flow) behind it, and to say what it could not check.

Context Brief (inject into each subagent)

PRODUCT: [product name and one-line description]
AUDIENCE: [who this is for]
LAUNCH: [when and how]
SUCCESS: [what good looks like]

Subagent Mandates

Subagent 1 — First-Run Red-Team (mandate of first-contact skill) Simulate the experience of a brand-new user encountering this product for the first time. Find every place they get confused, think it's broken, fail to understand the value, or abandon setup. Look for: unclear onboarding, missing zero-state guidance, confusing first action, misleading UI text, setup friction that filters out valid users.

Subagent 2 — Support Load Forecast (mandate of support-storm skill) Simulate the first 2 weeks of support emails, 1-star reviews, Reddit posts, and bug reports this launch will generate. Generate 10-15 realistic examples. Identify which signal a product bug vs. user confusion vs. unmet expectation. Find the 3 changes that would eliminate the most tickets.

Subagent 3 — Trust Surface Audit (mandate of trust-audit skill) Audit this product for everything that could make a user feel unsafe, surveilled, surprised, or deceived. Cover: permissions requested vs. permissions needed, data retention and deletion, billing surprises, silent mutations to user files or state, anything that "feels creepy" even if technically legal.

Subagent 4 — Pre-Mortem (mandate of pre-mortem skill) Assume it is 6 months after launch and the product failed. Write the postmortem. What were the actual causes? Find the top 5-7 failure modes most specific to THIS product and audience. For each: estimated probability, user impact, recovery path. Rank by (probability × impact).

Phase 3: Synthesis and Verdict

After all four subagents complete, synthesize their findings:

Blocking Issues (must fix before launch)

Issues that appear in 2+ analyses, or any finding tagged catastrophic (data loss, security/privacy breach, billing harm, unrecoverable user state). Dedupe by root cause, not wording.

Non-Blocking Issues (fix post-launch)

Single-analysis findings that are real but survivable.

Verdict

Choose one:

🟢 GO — No blocking issues. Non-blocking issues are documented. Launch when ready.

🟡 CAUTION — 1-2 blocking issues with clear, fast fixes. Launch after addressing.

🔴 NO-GO — 3+ blocking issues or one catastrophic finding. Fix before launching.

If an analysis could not be run or came back thin, say so in the report and cap the verdict at CAUTION; never issue GO on partial evidence.

Output Format

## Launch Sequence Report

**Verdict: [🟢 GO / 🟡 CAUTION / 🔴 NO-GO]**

### Blocking Issues
- [Issue from which analysis] [description] [suggested fix]

### Non-Blocking Issues
- [Issue] [suggested fix]

### Key Themes
[2-3 sentences on the most common cross-analysis patterns]

### What to Do Next
[Numbered list of immediate actions, ordered by priority]

### Coverage
[Which of the four analyses ran, and what each could not check]
</process>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free