# Launch runbook Human Guide

## What This Is For
Plan and execute the launch of a website, product, or major release. It gives the agent a clearer input/output frame for growth marketing: what context to ask for, what decisions to make, and what usable artifact to return.

Use this as a human-readable version of the Launch runbook agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions.

## When To Use This
- Use this when you need a repeatable process for launch runbook.
- Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt.
- Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact.

## When Not To Use This
- Do not use this when you only need a quick factual answer.
- Do not use this when the work depends on private data you cannot share with the assistant.
- Do not use this as a replacement for legal, compliance, financial, or medical review.

## What You Need Before Starting
- The goal or business outcome you want.
- The audience, customer segment, or market context.
- Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance.
- Constraints such as tone, length, channel, deadline, region, or approval requirements.
- A clear definition of what a good final answer should look like.

## Step-By-Step Workflow
1. State the job clearly: "Use the Launch runbook guide to help me with..."
2. Add context: audience, goal, offer, channel, source material, and constraints.
3. Ask the assistant to identify missing inputs before producing the final output.
4. Have the assistant follow the skill-specific guidance below.
5. Review the result against the final checklist and ask for revisions where needed.

## Skill-Specific Guidance
- Launching a new website or major redesign
- Migrating from one platform to another
- Releasing a major product or feature
- Coordinating cross-team launches
- Building a runbook for a recurring deploy
- Pre-launch testing (use `qa-testing`)
- Post-launch incident response (use `incident-response`)
- After-launch retrospective (use `after-action-report`)
- The launch scope (what's being launched)
- The launch window (date, time, duration)
- The team (roles, on-call rotation)
- The rollback criteria (when to abort)

## Decision Points And Nuance
The original skill emphasizes: When to use, When NOT to use, Required inputs, The framework: 4 phases, Phase 1: Pre-launch (T-30 days to T-1 hour), Phase 2: Cutover (T-0), Phase 3: Verification (T+0 to T+24 hours), Phase 4: Stabilization (T+24 hours to T+7 days), Roles and responsibilities, Rollback criteria.

Use these questions to steer the work:
- What is the intended audience or buyer?
- What source material must be preserved?
- What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion?
- What examples represent the desired quality bar?
- What should the assistant avoid?

## Common Mistakes
- **No on-call for first 24 hours.** Someone must be reachable.
- **Maintenance window required:** [Yes / No, and if yes, expected duration]
- [ ] All required tools and access verified
- **Pre-condition:** What must be true to start

## Copy-And-Paste Prompt
```text
Use the Launch runbook human guide.

My goal:
[Describe the business outcome]

Audience:
[Describe who this is for]

Context and source material:
[Paste notes, examples, links, or existing copy]

Constraints:
[Tone, length, channel, timeline, must-include items, must-avoid items]

Before producing the final output, ask me for any missing information that would materially improve the result.
```

## Final Checklist
- [ ] The output matches the original goal.
- [ ] The audience and context are reflected in the answer.
- [ ] Important constraints and source material were preserved.
- [ ] The assistant made the relevant decisions explicit.
- [ ] The final artifact is ready to use, review, or hand to the next person.

## Source
This guide was generated from the rampstackco/claude-skills skill entry for `launch-runbook`.

## Source Skill Notes
These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic.

# Launch Runbook

Plan and execute the launch of a website, product, or major release. The runbook is the document everyone uses on launch day. Stack-agnostic.

This skill is for the launch event. For pre-launch QA, use `qa-testing`. For post-launch incident handling, use `incident-response`.

---

## When to use

- Launching a new website or major redesign
- Migrating from one platform to another
- Releasing a major product or feature
- Coordinating cross-team launches
- Building a runbook for a recurring deploy

## When NOT to use

- Pre-launch testing (use `qa-testing`)
- Post-launch incident response (use `incident-response`)
- After-launch retrospective (use `after-action-report`)

---

## Required inputs

- The launch scope (what's being launched)
- The launch window (date, time, duration)
- The team (roles, on-call rotation)
- The rollback criteria (when to abort)
- The communication plan (who tells whom what, when)

---

## The framework: 4 phases

A launch has four phases. The runbook covers all four.

### Phase 1: Pre-launch (T-30 days to T-1 hour)

Verify everything is ready before the launch window.

**T-30 days:**
- Final scope locked
- Cross-team commitments confirmed
- Pre-launch QA scheduled
- Comms plan drafted

**T-7 days:**
- Pre-launch QA complete
- All critical and major issues resolved
- Performance baseline measured
- Rollback procedures documented and tested
- DNS TTL lowered (if DNS change is part of launch)

**T-1 day:**
- Final go/no-go meeting
- Roles confirmed
- Communication channels set up
- Backup of current production state

**T-1 hour:**
- Team assembled in shared communication channel
- Tools and access verified
- Final smoke test on staging

### Phase 2: Cutover (T-0)

The actual launch. Sequenced steps with owners and verifications.

**Standard cutover steps:**

1. Announce start to internal team
2. Enable maintenance mode (if applicable)
3. Run final database migrations (if applicable)
4. Deploy code to production
5. Verify deploy completed without errors
6. Run smoke tests on production
7. DNS cutover (if applicable)
8. Verify DNS propagation