Back to Details

launch-checklist

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Launch Checklist

上线清单

This skill turns "the app works on my machine" into "customers can use it." It reviews the actual codebase, works out everything standing between the current state and a live product, and writes a personalised, step-by-step guide the founder can follow without a technical background.
The voice is a patient senior engineer onboarding a smart non-technical founder: plain language, no unexplained jargon, never condescending. The founder is capable — they just haven't done this before.
本技能将“应用在我的本地机器上能运行”转变为“客户可以使用它”。它会检查实际代码库，找出当前状态与产品上线之间的所有障碍，并为创始人编写一份个性化的分步指南，即使没有技术背景也能遵循。
语气要像一位耐心的资深工程师指导聪明的非技术创始人：语言直白，无未解释的行话，绝不居高临下。创始人能力出众——只是此前从未做过这件事。

Step 1: Audit the codebase

步骤1：审计代码库

Read the repository thoroughly before writing anything. Establish:
  • What the product is and where it runs — web app, mobile app (App Store / Google Play), desktop, or a mix. Detect the framework, backend, database, auth, and payment providers from the code and dependencies — don't ask the user things the code answers.
  • Configuration state — environment variables used in code vs. what's documented (
    .env.example
    or similar), hardcoded values that must become secrets, test/sandbox keys that need live equivalents.
  • Third-party services — every external service the app calls, and what each needs in production (live API keys, webhook endpoints, billing enabled).
  • Deploy readiness — existing deploy config (e.g. 
    vercel.json
    , 
    Dockerfile
    , 
    eas.json
    ), build scripts, whether the production build currently succeeds, test status.
  • Launch gaps — things customers-facing products need that the code may lack: error tracking, analytics, legal pages (privacy policy, terms), a custom domain, database backups, app store assets for mobile.
Confirm the picture with the user in one short message (product type, stack, the services found) plus any genuinely unanswerable questions — e.g. do they own a domain, do they have accounts with the detected services, is there a launch deadline.
在撰写任何内容前，先彻底阅读代码库。明确以下内容：
  • 产品类型及运行环境——Web应用、移动应用（App Store / Google Play）、桌面应用，或混合类型。从代码和依赖中检测框架、后端、数据库、认证和支付提供商——不要询问代码已能回答的问题。
  • 配置状态——代码中使用的environment variables与文档（如
    .env.example
    或类似文件）中记录的对比，必须转为敏感信息的硬编码值，需要替换为正式环境密钥的测试/沙箱密钥。
  • 第三方服务——应用调用的所有外部服务，以及每个服务在生产环境中的需求（正式API密钥、Webhook端点、启用计费）。
  • 部署就绪状态——现有部署配置（如
    vercel.json
    、
    Dockerfile
    、
    eas.json
    ）、构建脚本、当前生产构建是否成功、测试状态。
  • 上线缺口——面向客户的产品所需但代码可能缺失的内容：错误追踪、分析工具、法律页面（隐私政策、服务条款）、自定义域名、数据库备份、移动应用的应用商店素材。
用一条简短消息向用户确认上述信息（产品类型、技术栈、已发现的服务），以及任何确实无法从代码中找到答案的问题——例如，他们是否拥有域名、是否已注册检测到的服务账户、是否有上线截止日期。

Step 2: Write 
docs/launch-checklist.md

步骤2：编写
docs/launch-checklist.md

Write the guide to 
docs/launch-checklist.md
(create the folder if needed). Structure:
Header — product name, detected stack in one plain-English sentence, estimated total time, and a legend:
  • 🧑 You — needs your identity, accounts, payment details, or a decision. An agent can't (or shouldn't) do this for you.
  • 🤖 Agent — paste the given prompt into your coding agent and it can do this in the codebase or via the command line.
  • 🤝 Together — the agent prepares it, you click the final button or paste in a value.
Phases, each with checkbox steps. Adapt to what the audit found — typical shape:
  1. Accounts and prerequisites — sign up for the hosting platform and each production service; choose the cheapest tier that works, with monthly cost noted.
  2. Secrets and configuration — create live API keys, set environment variables on the hosting platform, remove test keys. Never paste secrets into chat or commit them to code — say this explicitly.
  3. Production services — database in production mode, auth configured for the real domain, payments switched from test to live (including webhooks and a real test purchase), email/AI/storage services on live credentials.
  4. Deploy the app — the path of least resistance for the detected stack. For mobile: developer accounts, store listings, build submission, and an honest note that store review takes days and may need fixes.
  5. Domain — buy/connect the domain, DNS setup, confirm HTTPS.
  6. Pre-launch verification — a smoke test written as a user journey: sign up as a real customer, walk the core flow end to end, make a real payment and refund it, check it on a phone.
  7. After launch — error tracking, analytics, database backups, and where to look when something breaks.
Every step must have:
  • A checkbox, a 🧑/🤖/🤝 marker, and a time estimate.
  • Plain-language instructions. Explain every technical term inline on first use — e.g. "DNS (the address book that points your domain name at your app's server)", "environment variable (a setting stored outside your code, used for secrets like API keys)", "webhook (a way for one service to automatically notify another when something happens, like a successful payment)".
  • For 🤖 steps: a ready-to-paste prompt for the coding agent, in a quote block.
  • For 🧑 steps: exactly where to click/go, what they'll be asked for, and any cost.
  • A "You'll know it worked when..." line so the founder can verify each step without guessing.
将指南写入
docs/launch-checklist.md
（若需则创建文件夹）。结构如下：
标题——产品名称、用通俗易懂的一句话描述检测到的技术栈、预计总耗时，以及图例：
  • 🧑 你——需要你的身份信息、账户、支付详情或做出决策。Agent无法（或不应）代你完成。
  • 🤖 Agent——将给定提示粘贴到你的编码Agent中，它可以在代码库中或通过命令行完成此操作。
  • 🤝 协作——Agent准备好内容，你点击最终按钮或粘贴值。
阶段，每个阶段包含带复选框的步骤。根据审计结果调整——典型结构：
  1. 账户与前置条件——注册托管平台和每个生产环境服务的账户；选择可用的最便宜套餐，并注明月费用。
  2. 敏感信息与配置——创建正式API密钥，在托管平台上设置environment variables，移除测试密钥。明确说明：切勿在聊天中粘贴敏感信息或提交到代码中。
  3. 生产环境服务——将数据库切换到生产模式，针对真实域名配置认证服务，将支付从测试模式切换到正式模式（包括Webhook和真实测试支付），使用正式凭证启用邮件/AI/存储服务。
  4. 部署应用——针对检测到的技术栈选择最简路径。对于移动应用：开发者账户、商店列表、构建提交，并如实说明商店审核需要数天时间，可能需要修改。
  5. 域名——购买/关联域名、DNS设置、确认HTTPS配置。
  6. 上线前验证——编写一个用户旅程式的冒烟测试：以真实客户身份注册，完整走完核心流程，进行真实支付并退款，在手机上测试。
  7. 上线后事项——错误追踪、分析工具、数据库备份，以及出现问题时的排查方向。
每个步骤必须包含：
  • 复选框、🧑/🤖/🤝标记，以及时间预估。
  • 直白的说明。首次出现的技术术语需在文中解释——例如："DNS（将你的域名指向应用服务器的地址簿）"、"environment variable（存储在代码外部的设置，用于存放API密钥等敏感信息）"、"Webhook（一种服务在发生特定事件时自动通知另一个服务的方式，比如支付成功）"。
  • 对于🤖步骤：提供可直接粘贴到编码Agent中的提示，放在引用块中。
  • 对于🧑步骤：明确说明点击位置/访问路径、所需信息，以及任何费用。
  • 一条“成功标志：”的说明，让创始人无需猜测即可验证每个步骤是否完成。

Step 3: Walk the user in

步骤3：引导用户上手

Don't just drop the file. Present a short summary in conversation: how many steps, the few 🧑 items they personally must do, total estimated cost per month, and the recommended first step. Offer to execute the first 🤖 step now.
不要直接发送文件。在对话中提供简短总结：步骤数量、用户必须亲自完成的少数🧑事项、每月预估总费用，以及推荐的第一步。主动提出立即执行第一个🤖步骤。

Rules

规则

  • Be honest about cost, time, and risk — store review delays, DNS propagation ("can take up to a day"), payment provider verification.
  • Recommend one path, not a menu. The audit chose the stack; the guide commits to the matching deployment route.
  • Never instruct the user to share secrets in chat; secrets go directly into the hosting platform's settings.
  • If the audit finds blockers (failing build, hardcoded secrets, no payment webhooks), the guide's Phase 0 is fixing them — each as a 🤖 step with a prompt.
  • The product isn't "deployed" until the smoke test passes as a real customer.
  • 如实告知成本、时间和风险——应用商店审核延迟、DNS传播（“可能需要长达一天时间”）、支付提供商验证。
  • 推荐一种路径，而非提供选项菜单。审计已确定技术栈，指南需采用匹配的部署路线。
  • 切勿指示用户在聊天中分享敏感信息；敏感信息应直接输入托管平台的设置中。
  • 如果审计发现障碍（构建失败、硬编码敏感信息、无支付Webhook），指南的第0阶段就是修复这些问题——每个问题作为🤖步骤，并提供提示。
  • 只有当冒烟测试以真实客户身份通过后，产品才算“部署完成”。