cto-review

cto-review skill 概览

cto-review 的作用

cto-review 是一个面向战略工程评审的 skill，用来在架构、扩展性、技术债、招聘，以及 build-vs-buy 决策变成高成本承诺之前，先进行压力测试。它围绕命令模式 /cs:cto-review <plan> 设计，会提出 CTO 视角的追问：系统会在哪里被压垮，哪些技术债正在变成阻塞项，团队是否能支撑这个计划扩张，以及购买现成方案是否比自研更理性。

最适合 Strategic Planning 类决策

cto-review skill 最适合在你已经有明确计划，而不是只有模糊想法时使用。典型场景包括：审批新的数据库方案、为 10 倍流量增长做规划、判断是否重建遗留系统、评估平台迁移，或为管理层准备技术战略评审。它尤其适用于 Strategic Planning，因为这类场景中的工程选择会直接影响预算、招聘、可靠性和长期执行风险。

它和通用 prompt 有什么不同

通用 AI prompt 可能会给出宽泛的架构建议。cto-review 会把讨论聚焦在六个决策问题上，用来暴露扩展性断崖、技术债的每周成本、团队 ramp 约束，以及三年总拥有成本。这种结构比开放式头脑风暴更适合高管评审、架构审批和承诺前风险分析。

采用前需要注意的事项

该 skill 的仓库路径下只有一个 SKILL.md，skill 文件夹内没有本地 README.md、metadata.json、rules、resources 或随附的辅助脚本。源文件会通过相对路径引用更大的 cto-advisor 区域下的分析脚本，因此在把这些命令纳入工作流之前，需要先确认你的安装环境中这些脚本是否可用。cto-review 的核心价值在于评审框架；自动化能力可能需要额外配置。

如何使用 cto-review skill

cto-review 安装与仓库检查

使用你的 skill manager 从 GitHub skill collection 安装，例如：

npx skills add alirezarezvani/claude-skills --skill cto-review

安装后打开：

c-level-advisor/c-level-agents/skills/cto-review/SKILL.md

先阅读这个文件，因为它包含命令、触发条件和六个 CTO 问题。如果你的 agent 环境会保留相对路径，也建议检查周边仓库内容，因为该 skill 会引用本地文件夹之外的脚本，例如 cto-advisor/scripts/tech_debt_analyzer.py 和 cto-advisor/scripts/team_scaling_calculator.py。

这个 skill 需要哪些输入

要让 cto-review 发挥更强效果，需要提供足够具体的运营细节，让它能挑战你的假设。建议包含：

• 当前规模：用户数、每秒请求数、数据量、租户数、区域数量或交易量
• 目标规模：预期增长、10 倍场景、发布活动、企业客户扩张或迁移截止时间
• 架构：服务、datastore 选择、队列、依赖、部署模型和可靠性目标
• 约束：预算、团队规模、招聘计划、合规要求、供应商限制、截止日期和 SLOs
• 正在评审的决策：批准、延期、购买、自建、重建、迁移或先做实验

较弱的输入：“Review our new architecture.”

更强的输入：“Use cto-review for Strategic Planning. We are moving from a monolith on PostgreSQL to event-driven services before expanding from 50k to 500k monthly active users. Current p95 API latency is 700ms during peak, writes are concentrated on one primary DB, the team has 8 engineers and plans to hire 4 more. Review scaling cliffs, tech debt cost, team ramp risk, and whether managed event streaming is better than building our own platform.”

实用的 cto-review 使用流程

先按照该 skill 使用的命令风格，把计划粘贴在后面：

/cs:cto-review <your plan>

要求它输出面向决策的结果，而不是泛泛而谈的长文。比较有用的输出格式包括：

• “List the top 5 approval blockers.”
• “Identify the first scaling cliff and the evidence needed to confirm it.”
• “Compare build vs buy over three years.”
• “Separate reversible experiments from irreversible commitments.”
• “Give the questions I should ask the engineering lead before approval.”

如果第一次回答过于猜测，不要只是让模型 “try again”，而是补充缺失事实。这个 skill 的设计目标是审视一个计划；当你提供真实负载数据、成本估算、人员假设和事故历史时，它的价值会明显提升。

需要先核验的文件和命令

唯一已确认的 skill 文件是 SKILL.md。它包含脚本调用示例，但这个具体的 skill 文件夹内并不包含本地脚本。在把这些脚本纳入你的工作流之前，请先检查安装后以下路径是否存在：

../../../skills/cto-advisor/scripts/tech_debt_analyzer.py

../../../skills/cto-advisor/scripts/team_scaling_calculator.py

如果这些文件缺失，你仍然可以手动使用 cto-review 指南：在 prompt 中提供自己的技术债清单和团队 ramp 假设即可。

cto-review skill 常见问题

cto-review 适合初学者吗？

适合，前提是用户有一个具体的工程决策需要评审。它不是系统设计、云架构或数据库选型的入门教程。初创公司创始人或产品负责人即使工程经验不深，也可以通过提供业务目标，并要求 agent 将技术风险转化为决策问题来有效使用它；但最终判断仍应让有经验的工程师参与。

什么时候不应该使用 cto-review？

不要把 cto-review 用在很小的实现选择、日常 code review、ticket 梳理，或定位某个狭窄缺陷上。如果还没有任何计划，它也不适合使用。它适合用于“判断错误会带来实际重大成本”的场景：平台迁移、高成本供应商决策、扩展性投入、可靠性重设计、招聘计划或重建提案。

它和架构评审 prompt 相比如何？

架构评审 prompt 通常会检查设计模式、组件和取舍。cto-review skill 会额外施加高管视角的压力：技术债每周成本、团队可扩展性、故障阈值，以及 build-vs-buy 的经济性。因此它更适合做 go/no-go 评审，而不是从零生成一套完整参考架构。

cto-review 必须依赖引用的脚本吗？

不需要。核心 cto-review skill 是 SKILL.md 中的一套结构化评审方法。如果引用的脚本可用，可能会增强分析，但只通过 prompt 也可以运行这个 skill。在确认本地安装中确实存在这些文件之前，应把脚本支持视为可选能力。

如何改进 cto-review skill

在要求判断前，先改进 cto-review 输入

最常见的失败模式，是在没有数字的情况下要求做 CTO review。即使是粗略范围也很有价值，例如：“current write rate is 2k/min”、“expected peak is 10x after launch”、“vendor quote is $180k/year”，或 “team has two backend engineers with no Kafka experience”。这些细节能让 cto-review 识别真实的扩展性断崖，而不是只列出泛泛的风险。

要求指出证据缺口，而不只是给建议

好的 cto-review 指南应该告诉你，批准之前必须先测量什么。可以追问：“What evidence is missing?” 或 “Which assumptions need a load test, cost model, prototype, or vendor reference call?” 这样输出会变成行动计划，也能降低看似合理但未经验证的架构建议带来的虚假信心。

带着决策约束迭代

第一次评审后，进一步收窄决策范围。例如：“Assume we cannot hire until Q3”、“Assume downtime must stay under 30 minutes”，或 “Assume build-vs-buy must be justified over three years.” 约束会迫使该 skill 优先处理管理层真正关心的取舍，而不是罗列所有可能的技术问题。

为你的组织扩展这个 skill

如果要在团队环境中改进 cto-review，可以加入内部 checklist，覆盖 SLOs、事故历史、云成本阈值、已批准供应商、安全要求和架构决策记录模板。如果你使用引用的分析脚本，请在 skill 附近记录它们的路径和预期输入，避免后续用户被缺失的相对路径文件卡住。