关于 launch-checklist
Launch Checklist 是面向创始人的技能，可审查代码库并制定产品上线指南。它将技术任务拆解为分步说明，标注执行者、时间估算和验收标准，并为编码 Agent 提供提示词。
主要功能
- 01审查代码、配置与服务
- 02发现部署和上线缺口
- 03生成定制上线清单
- 04标注任务执行者
- 05提供时间估算与验收标准
- 06为编码 Agent 提供提示词
适用场景
- 01为生产环境准备代码库
- 02指导非技术创始人完成部署
- 03识别上线阻碍并安排验证步骤
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/launch-checklist确认已加载。
详细介绍
上线清单
这项技能将“应用在我的机器上能运行”变成“客户可以使用它”。它会检查实际的代码库，梳理从当前状态到产品上线之间的所有待办事项，并编写一份个性化的分步指南，让没有技术背景的创始人也能照着操作。
语气应像一位耐心的资深工程师在帮助一位聪明的非技术背景创始人熟悉工作：语言浅显，不使用未经解释的术语，也绝不居高临下。创始人很有能力——只是以前没做过这些事。
第 1 步：审查代码库
先彻底阅读代码库，再着手编写内容。确认以下事项：
- 产品是什么，以及在哪里运行——Web 应用、移动应用（App Store / Google Play）、桌面应用，或多种形式。根据代码和依赖项识别框架、后端、数据库、身份验证和支付服务提供商——代码能回答的问题，不要问用户。
- 配置状态——代码中使用的环境变量与文档（
.env.example或类似文件）中记录的变量是否一致；必须改为机密信息的硬编码值；需要替换为正式环境版本的测试／沙盒密钥。 - 第三方服务——应用调用的每一项外部服务，以及它们在生产环境中各自需要的配置（正式环境 API 密钥、Webhook 端点、启用计费功能）。
- 部署就绪情况——现有部署配置（例如
vercel.json、Dockerfile、eas.json）、构建脚本、当前生产构建是否成功，以及测试状态。 - 上线缺口——面向客户的产品需要、但代码中可能缺少的内容：错误跟踪、分析、法律页面（隐私政策、服务条款）、自定义域名、数据库备份，以及移动应用的应用商店素材。
用一条简短消息向用户确认整体情况（产品类型、技术栈、发现的服务），并提出任何确实无法从代码中得知的问题——例如，他们是否拥有域名、是否已注册所识别服务的账号，以及是否有上线期限。
步骤 2：编写 docs/launch-checklist.md
将指南写入 docs/launch-checklist.md（如有需要，请创建该文件夹）。结构如下：
标题 — 产品名称、用一句通俗易懂的英文描述检测到的技术栈、预计总耗时，以及图例：
- 🧑 你 — 需要你的身份信息、账户、付款详情，或需要你做决定。Agent 无法（或不应）代你完成。
- 🤖 Agent — 将给出的提示词粘贴到编码 Agent 中，它就能在代码库中或通过命令行完成这项工作。
- 🤝 一起完成 — Agent 负责准备，你点击最后的按钮或粘贴一项值。
各阶段，每个阶段都包含带复选框的步骤。 根据审查结果调整内容，典型结构如下：
- 账户和前置条件 — 注册托管平台和每项生产服务；选择可用的最低价套餐，并注明月费。
- 密钥和配置 — 创建正式 API 密钥，在托管平台上设置环境变量，移除测试密钥。明确说明：绝不要将密钥粘贴到聊天中，也不要将其提交到代码库。
- 生产服务 — 数据库切换到生产模式；将身份验证配置为适用于真实域名；付款从测试模式切换到正式模式（包括 Webhook 和真实测试购买）；电子邮件、AI 和存储服务使用正式凭据。
- 部署应用 — 针对检测到的技术栈，选择最简单直接的部署方案。对于移动应用：说明开发者账户、应用商店页面、提交构建版本，并如实说明商店审核需要数天，也可能需要修复问题。
- 域名 — 购买或连接域名、设置 DNS，并确认 HTTPS 正常。
- 上线前验证 — 编写一份以用户旅程为线索的冒烟测试：以真实客户身份注册，端到端走完核心流程，进行真实付款并退款，然后在手机上检查。
- 上线后 — 错误跟踪、分析、数据库备份，以及出现问题时该去哪里排查。
每个步骤都必须包含：
- 一个复选框、一个 🧑/🤖/🤝 标记，以及预计耗时。
- 通俗易懂的说明。首次出现时，须在行内解释每个技术术语，例如 “DNS（将域名指向应用服务器的地址簿）”、“环境变量（存储在代码之外的设置，用于保存 API 密钥等密钥信息）”、“Webhook（一种服务间自动通知的方式，例如在付款成功时通知另一项服务）”。
- 对于 🤖 步骤：提供可直接粘贴给编码 Agent 的提示词，放在引用块中。
- 对于 🧑 步骤：准确说明点击或前往哪里、系统会要求提供什么，以及任何费用。
- 一行“确认成功的方法……”，让创始人无需猜测就能验证每个步骤。
步骤 3：引导用户
不要只交付文件。请在对话中提供简短摘要：步骤数量、用户必须亲自完成的少数 🧑 项目、每月预计总费用，以及建议从哪一步开始。主动提出现在就执行第一个 🤖 步骤。
规则
- 如实说明费用、耗时和风险，包括商店审核延迟、DNS 传播时间（“最长可能需要一天”）以及支付服务商的验证流程。
- 推荐一条路径，不要列出多个选项。审查已经选定技术栈，指南应采用与之匹配的部署方式。
- 绝不要指示用户在聊天中分享密钥；密钥应直接填入托管平台的设置中。
- 如果审查发现阻塞问题（构建失败、密钥硬编码、缺少支付 Webhook），指南的阶段 0 应负责修复这些问题——每个问题都作为一个 🤖 步骤，并附上提示词。
- 只有真实客户成功通过冒烟测试后，产品才算“已部署”。
评论
支持 Markdown