gtm-review

GTM 评审工作流

对项目阶段进行全面的上市规划与发布准备度评审。此技能会审查营销内容准确性、代码质量、性能、无障碍性、基础设施准备情况和业务定位，然后启用 GTM Council，汇总给出发布准备度结论。

范围

会做	不会做
全面的阶段准备度审计	编写应用程序代码或修复 Bug
审查营销内容准确性	推送到远程仓库或创建 PR
通过 Review Council 审查代码质量	修改项目看板计划
审计性能和无障碍性	重新规划功能（使用 /plan-feature）
业务与竞争分析	运行安全审计（使用 /security-audit）
在 docs/decisions/ 中生成 GTM 报告
更新 GTM issue 并记录发现

重要

此技能不能替代 /security-audit 阶段门。安全审计是独立的阶段门项目，在 GTM 评审之后运行。此技能会将安全问题交由该技能处理，而不会重复其工作。

步骤 0：确认工作区干净

此技能会在步骤 10 提交报告文件。开始前请确保工作区干净：

git status --porcelain

如果存在未提交的更改，请警告用户，并询问是将其暂存起来（git stash push -m "gtm-review: stash before review"）还是中止。

步骤 1：确定阶段范围

接受用户提供的输入：

• GTM issue 编号（例如，#132）——主要输入
• 阶段标识符（例如，M1）——备选输入

如果提供了 GTM issue 编号：

gh issue view <number> --json title,body,labels,milestone

如果提供了阶段标识符，则查找该阶段对应的 GTM issue：

gh issue list --state open --label "gtm-review" --json number,title,milestone

构建阶段清单

1. 列出里程碑中的所有 issue——已交付（已关闭）、进行中、未开始：

   gh issue list --milestone "<milestone-title>" --state all --json number,title,state,labels --limit 100
   

2. 对功能分类：

   • 已交付（已关闭的 issue）：已完成且可用的功能
   • 进行中（带有 in-progress 标签的 issue）：正在同步开发的功能
   • 已计划（未带 in-progress 标签的未关闭 issue）：尚未开始的功能

3. 构建能力矩阵：针对每项已交付功能，总结产品目前具备的能力。针对每项进行中的功能，注明它将带来的能力。此矩阵是内容审计的事实依据——每项营销声明都将据此进行验证。

4. 识别差距：找出 GTM issue 的阶段摘要中描述但尚未交付的功能。

步骤 2：运行自动化质量检查

并行运行所有检查：

pnpm lint
pnpm format:check
pnpm type-check
pnpm test --coverage
pnpm build

捕获并记录：

• Lint：通过/失败、警告数量
• Format：通过/失败、需要格式化的文件
• Type-check：通过/失败、错误数量
• 测试：通过/失败、测试总数、各软件包的覆盖率百分比
• 构建：通过/失败、构建输出中的包大小

这些结果将在后续步骤中使用。此处不要创建检查点。

步骤 3：性能审计

启用 Performance Analyst Agent。从 .claude/agents/performance-analyst.md 读取 Agent 定义，并使用 ## Model 部分中指定的模型。

调用以下插件以获取指导：

• application-performance：用于应用性能分析和优化模式
• performance-testing-review：用于性能测试方法和覆盖率分析

前端性能

使用第 2 步的构建输出：

• 包体积分析：总包体积、最大的代码块、代码拆分的机会
• 延迟加载：路由级组件是否采用延迟加载？大型库是否延后加载？
• 图像优化：图像是否以现代格式（WebP、AVIF）提供？尺寸是否恰当？
• 渲染性能：是否存在阻塞渲染的资源？初始负载是否过大？
• 核心 Web Vitals 风险评估（基于代码模式）：
  • LCP：大型 Hero 图像是否未预加载？字体是否造成阻塞？服务器响应模式是否缓慢？
  • INP：主线程上是否运行了大量 JavaScript？昂贵的渲染是否缺少 React.memo 或 useMemo？
  • CLS：动态插入内容时是否未预留空间？字体切换时是否未设置备用字体尺寸？

后端性能

• API 端点模式：是否有端点获取了过多数据？是否缺少分页？
• N+1 查询：检查 Prisma 查询中的 .include() 模式，找出可能导致 N+1 查询的情况
• 数据库索引覆盖率：频繁查询的字段是否建立了索引？
• 连接池：是否配置了数据库连接池？
• 缓存：是否针对频繁访问的数据制定了缓存策略？

记录所有发现，供评审委员会评估。此处不要创建检查点。

第 4 步：无障碍审计

调用以下插件：

• accessibility-compliance:wcag-audit-patterns，进行全面的 WCAG 2.1 AA 合规性审计
• accessibility-compliance:screen-reader-testing，检查与辅助技术的兼容性
• ui-design:accessibility-audit，检查组件级无障碍性

审计范围：

• 颜色对比度：所有文本与背景的组合是否符合 WCAG AA 比例（普通文本为 4.5:1，大号文本为 3:1）？
• 键盘导航：是否可以通过键盘访问并激活所有交互元素？
• ARIA 属性：ARIA 角色、标签和实时区域是否使用正确？
• 焦点管理：模态框中是否锁定焦点？焦点是否在各步骤间按逻辑顺序移动？
• 语义化 HTML：标题层级是否正确？表单标签是否已关联？是否包含地标？
• 触控目标：移动设备上的交互元素是否至少为 44x44px？
• 响应式设计：布局是否适用于常见断点？
• 动态效果/动画：是否遵循 prefers-reduced-motion 设置？

记录所有发现，供评审委员会评估。此处不要创建检查点。

第 5 步：内容与营销审计

激活 Content Reviewer Agent。从 .claude/agents/content-reviewer.md 中读取 Agent 定义，并使用 ## Model 部分指定的模型（Claude Opus 4.6）。

调用以下插件以获取指导：

• seo-technical-optimization，用于审计元标签、结构化数据和架构标记
• seo-content-creation，用于评估内容质量和 E-E-A-T

营销页面审计

针对落地页的每个部分（主视觉、功能、工作原理、定价、社会认同、常见问题、页脚）：

1. 阅读实际组件文件，查看用户将看到的确切文案
2. 将每项声明与第 1 步的功能矩阵进行对比
3. 标记所有不一致之处：提及但尚未上线的功能、夸大的描述、误导性的比较

内容一致性审计

比较所有渠道上的文案：

• 落地页与应用内文案（引导流程、仪表板、个人资料）
• 落地页与电子邮件模板（邀请、欢迎）
• 定价声明与实际计费实现
• “工作原理”流程与实际用户体验

SEO 审计

• 元标签：标题、描述和关键词是否准确反映产品当前状态？
• 结构化数据（JSON-LD）：是否与实际产品相符（类型、价格、功能）？
• Open Graph 标签：og:title、og:description、og:image 是否正确？
• 汇总评分：评分是真实的还是编造的？

法律链接验证

• /privacy、/terms、/contact（或等效链接）是否指向实际页面？
• 法律页面是否完整且准确？

内容风格合规性

根据 AGENTS.md 中的 面向用户的内容风格 规则，检查所有面向用户的文案：

• 不得使用破折号（— 或 —）
• 不得使用空洞的 AI 术语：深入探究、织锦、格局、利用、无缝、前沿、开创性等
• 不得使用空洞的过渡词：此外、而且、另外
• 不得夸大宣传：惊艳、令人叹为观止、世界一流、改变游戏规则
• 不得默认使用三项并列结构
• 不得以肤浅的 -ing 形式收尾

用户评价和社会认同审查

• 用户评价是真实内容还是占位内容？
• 规模相关的表述是否恰当？（例如，针对仅限受邀者参与的 Beta 版使用“加入数千人”是否会造成误导？）
• 星级评分是否有实际数据支撑？

请提供逐项内容准确性报告，列出具体文件路径、有问题的文本和建议的修正内容。

检查点：向用户展示步骤 2 至 5 的自动化检查结果摘要。

按以下结构整理：

1. 质量检查（步骤 2）：通过/失败状态、覆盖率数据、软件包大小
2. 性能（步骤 3）：主要发现、风险区域
3. 无障碍（步骤 4）：WCAG 合规状态、发现的问题
4. 内容准确性（步骤 5）：逐项准确性报告、SEO 审核结果、风格违规项

等待用户审核后再进行评审委员会评估。用户可能希望先解决关键问题，再提交给评审委员会。

步骤 6：代码质量审查

调用 code-review-ai:architect-review，对本阶段的代码库进行架构分析。

模型选择：有关 Agent 模型规格与 Task 工具参数的对应关系，请参阅 README.md 中的 模型选择 部分。

启用 评审委员会（从 .claude/councils/review-council.md 中选出 4 名成员）：

安全工程师（负责人）— 咨询：security-scanning

• 审查代码库的安全状况（这是高层级审查，不是完整的 /security-audit）
• 验证身份验证和授权模式
• 从表层检查 OWASP Top 10
• 标记可能阻碍发布的关键问题
• 投票：批准 / 有顾虑 / 阻止
• 评估：[发现和建议]

QA 负责人 — 咨询：unit-testing

• 根据本阶段代码 >80% 的目标评估测试覆盖率
• 找出关键用户路径（身份验证、引导流程、核心功能）中的缺口
• 评估测试质量（测试是否有实际意义，还是仅仅为了达到行数要求？）
• 投票：批准 / 有顾虑 / 阻止
• 评估：[发现和建议]

开发者体验工程师 — 咨询：documentation-generation

• README.md 是否准确描述了新开发者的初始设置流程？
• docs/DEVELOPMENT.md 是否与当前设置步骤一致？
• docs/INDEX.md 是否包含所有文档文件且保持最新？
• API 端点是否有文档说明？
• 投票：批准 / 有顾虑 / 阻止
• 评估：[发现和建议]

前端专家和/或后端专家 — 咨询：frontend-mobile-development 或 backend-development

根据本阶段涉及的内容：

• 检查领域特定代码质量和模式一致性
• 检查架构遵循情况（文件夹结构、模块组织）
• 检查组件复用和 DRY 原则
• 投票：批准 / 有顾虑 / 阻止
• 评估：[发现和建议]

记录评审委员会的投票结果和任何阻止事项。此处不要设置检查点，评审结果将提交给 GTM 委员会。

步骤 7：基础设施和文档就绪情况

调用以下插件获取指导：

• 使用 deployment-validation 进行部署前配置检查
• 使用 observability-monitoring 检查监控和可观测性就绪情况

平台工程师 — 咨询：cloud-infrastructure

阅读 .claude/agents/platform-engineer.md 中的 Agent 定义，并使用指定的模型。

• Docker：对全新克隆的代码运行 docker compose up，能否启动可正常工作的环境？
• CI/CD：主分支上的所有检查是否都通过？
• 环境变量：.env.example 是否完整、准确？是否记录了所有必需的变量？
• 数据库：所有 Prisma 迁移是否都已成功应用？种子脚本是否为最新版本？
• 监控：是否已配置错误跟踪或日志记录？
• 健康检查：API 是否提供用于验证依赖项的健康检查端点？

DevX 工程师 — 咨询：documentation-generation

阅读 .claude/agents/devx-engineer.md 中的 Agent 定义，并使用指定的模型。

• 对于全新克隆的代码，从克隆到运行的开发者体验来说，README.md 是否准确？
• docs/DEVELOPMENT.md 是否包含最新的所有先决条件和设置步骤？
• docs/INDEX.md 是否已更新，包含所有文档文件？
• 本阶段新增的所有文档文件是否都已编入索引？

记录所有发现，供 GTM 委员会审阅。此处不要创建检查点。

第 8 步：启动 GTM 委员会

邀请以下插件提供意见：

• business-analytics：提供 KPI 框架、指标指导和财务分析模式
• content-marketing：提供内容策略和竞争研究

模型选择：请参阅 README.md 中的 模型选择 部分，了解如何将 Agent 模型规格映射到 Task 工具参数。

启动 GTM 委员会（成员共 5 人，见 .claude/councils/gtm-council.md）。将第 2 至第 7 步的所有发现作为输入提供给每位委员。

产品策略师（负责人）— 咨询：content-marketing

• 本阶段功能的市场定位是否准确
• 信息传达是否有效、清晰
• 发布策略：渠道、时机、顺序
• 基于当前功能集的竞争差异化
• 投票：批准 / 有顾虑 / 阻止
• 理由：[说明]

业务运营负责人 — 咨询：business-analytics

• 定价验证：当前功能集是否足以支撑定价？
• 收入影响：有哪些转化路径？
• 竞争定位：定价与竞品相比如何？
• 风险评估：发布时可能出现哪些问题？
• 投票：批准 / 有顾虑 / 阻止
• 理由：[说明]

内容审核员 — 咨询：seo-technical-optimization、seo-content-creation

• 根据第 5 步的发现，对最终内容准确性作出判断
• SEO 就绪度评分
• 风格规范遵循情况总结
• 是否存在可能损害用户信任的声明？
• 投票：批准 / 有顾虑 / 阻止
• 理由：[说明]

设计负责人 — 咨询：ui-design

• 所有界面（营销内容、应用、邮件）的品牌一致性
• 视觉打磨：UI 是否已达到生产就绪状态？
• UX 连贯性：产品体验是否符合营销承诺？
• 投票：批准 / 有顾虑 / 阻止
• 理由：[说明]

精益交付负责人

• MVP 完整度：本阶段计划的所有功能是否都已交付？
• 功能开关：未完成的功能是否已妥善设置开关？
• 已交付与已承诺：分析营销承诺与实际情况之间的差距
• 发布计划：时机是否现实？
• 投票：批准 / 有顾虑 / 阻止
• 理由：[说明]

委员会结论

根据 .claude/councils/gtm-council.md 中的共识规则统计投票并给出综合结论：

• 已批准：所有成员投票为“批准”或“有顾虑”（没有“阻止”票）
• 需要修改：存在一票或多票针对阻碍事项的“有顾虑”票；落实相关建议
• 已阻止：存在一票或多票“阻止”票；发布前必须解决根本问题

列出委员会识别出的所有阻碍事项。

检查点：向用户展示 GTM Council 的评审结果。

展示：

1. 每位成员的投票及理由
2. 综合结论（已批准 / 需要修改 / 已阻止）
3. 阻止事项列表
4. 非阻止性建议

等待用户批准评估结果后，再生成最终报告。

第 9 步：生成综合报告

将第 2–8 步的所有发现汇总成一份完整的 GTM 报告文档。

报告文件

使用 .claude/skills/gtm-review/GTM-REPORT-TEMPLATE.md 中的模板作为报告结构。使用下一个可用的决策编号，将已完成的报告写入 docs/decisions/：

1. 确定下一个决策编号：读取 docs/decisions/INDEX.md，找到现有的最大决策编号。加 1，并将编号补齐为 3 位，前面补零。

2. 文件名：docs/decisions/NNN-<phase>-gtm-review.md（例如，021-m1-gtm-review.md）

3. 填写模板中的所有章节，使用第 2–8 步的实际数据替换所有占位文本。删除不适用于此阶段的章节，但保留整体结构。

4. Frontmatter：更新 description 字段，以概述该阶段和评审结论：

   ---
   type: reference
   description: GTM launch readiness report for M1 -- [Approved/Needs Changes/Blocked]. Covers marketing, code quality, performance, accessibility, infrastructure, and business positioning.
   ---
   

报告章节

模板涵盖了所有必需章节。确保每一节都填入相应步骤的发现：

• 执行摘要 — 阶段概述和 Council 投票统计
• 阶段清单 — 第 1 步中的能力矩阵和差距分析
• 阻止 / 高 / 中 / 低优先级问题 — 汇总所有步骤中的分类发现
• 自动化质量检查 — 第 2 步的结果
• 性能就绪情况 — 第 3 步的前端和后端发现
• 无障碍合规性 — 第 4 步的 WCAG 审核结果
• 内容与营销审核 — 第 5 步中的内容准确性、SEO 和风格合规性
• 代码质量摘要 — 第 6 步的 Review Council 投票
• 基础设施就绪情况 — 第 7 步的平台和文档发现
• GTM Council 投票 — 第 8 步中每位成员的投票、理由和战略建议
• 成功指标 — 对 GTM 问题指标的验证
• 行动项和后续步骤 — 汇总所有发现

检查点：向用户展示完整的综合报告。等待用户批准后，再写入文件并发布到 GitHub。

第 10 步：撰写报告、更新 GTM 问题并移交

撰写报告文件并提交

将已完成的报告写入 docs/decisions/NNN-<phase>-gtm-review.md。

撰写报告文件并更新决策索引（见下文）后，提交这些文件：

git add docs/decisions/
git commit -m "docs(gtm): add GTM review report for <phase>"

更新决策索引

按照现有格式，在 docs/decisions/INDEX.md 的决策表格中添加一行。将新行插入表格顶部（表头之后）：

| NNN | [Phase GTM Review](NNN-<phase>-gtm-review.md) | YYYY-MM-DD | Review + GTM | Approved / Needs Changes / Blocked | gtm, launch readiness, <phase>, marketing, performance, accessibility |

将评审结论作为 Status 列的值（例如，“已批准”、“需要修改”、“已阻止”）。

将报告发布到 GitHub

将综合报告作为评论发布到 GTM 问题：

gh issue comment <issue-number> --body "<report>"

提示

使用 HEREDOC 作为报告正文，以保留格式：

gh issue comment <number> --body "$(cat <<'EOF'
## GTM Review Results
...report content...
EOF
)"

更新检查清单项

如果 GTM 问题正文包含检查清单，请根据发现更新：

• 对通过的项目勾选：- [x] Item
• 为需要处理的项目添加备注：- [ ] Item -- [GTM Review: needs attention because...]

如有需要，使用 gh issue edit 更新正文。

关闭 GTM 问题（有条件）

如果 GTM 评审结论为 已批准，且用户已批准报告：

1. 检查点：询问用户是否要在评审完成后关闭 GTM 问题。提供问题编号和标题供用户确认。
2. 如果用户批准，则关闭问题：

   gh issue close <number> --reason completed
   

如果评审结论为 需要修改 或 已阻止，则不要提议关闭问题。

交接

重要

此技能不能替代 /security-audit 门槛项。安全审计是每个里程碑的最终门槛，必须在 GTM 评审后单独运行。

向用户展示：

• GTM Issue：更新后 Issue 的链接
• 报告文件：决策记录的路径（例如，docs/decisions/021-m1-gtm-review.md）
• 结论：汇总后的就绪结论
• 阻塞问题数：剩余必须修复项的数量
• 后续步骤：
  • 如果仍有阻塞问题："修复阻塞问题，然后重新运行 /gtm-review"
  • 如果已就绪："运行 /security-audit，完成此阶段的最终门槛项"

停止——不要自动继续进行安全审计或任何其他技能。