cto-review

cto-review skill 概覽

cto-review 的用途

cto-review 是一個用於策略性工程審查的 skill，適合在架構、擴展性、技術債、招募，以及自建或採購等決策變成高成本承諾之前，先進行壓力測試。它以 /cs:cto-review <plan> 這種指令模式為核心，會提出 CTO 角度的關鍵追問：系統會在哪裡撐不住、哪些債務正在變成阻塞、團隊是否有能力支撐這個計畫，以及採購是否比自建更合理。

最適合用於 Strategic Planning 決策

cto-review skill 最適合用在你已經有一份具體計畫，而不只是模糊想法的情境。常見使用案例包括：核准新的資料庫、規劃 10 倍流量成長、決定是否重建舊系統、評估平台遷移，或準備提交給管理層的技術策略審查。它特別適合 Strategic Planning，因為這類工程選擇會影響預算、招募、可靠性，以及長期執行風險。

與一般 prompt 的差異

一般 AI prompt 可能會產出寬泛的架構建議。cto-review 則會把討論集中在六個決策問題上，用來揭露擴展瓶頸、技術債每週成本、團隊 ramp-up 限制，以及三年總持有成本。這種結構讓它比開放式腦力激盪更適合用於高階審查、架構核准，以及承諾前的風險分析。

採用前的重要注意事項

這個 skill 的 repository path 內只有單一 SKILL.md，skill 資料夾中沒有本機 README.md、metadata.json、rules、resources，或隨附的 helper scripts。原始內容會透過相對路徑參照較大的 cto-advisor 區域底下的 analyzer scripts，因此在把這些指令納入流程前，請先確認你的安裝環境中是否真的有這些 script。cto-review 的核心價值在於審查框架；自動化可能需要額外設定。

如何使用 cto-review skill

cto-review 安裝與 repository 檢查

使用你的 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 環境會保留相對路徑，也建議檢查周邊 repository，因為這個 skill 會參照本機資料夾外的 scripts，例如 cto-advisor/scripts/tech_debt_analyzer.py 和 cto-advisor/scripts/team_scaling_calculator.py。

cto-review 需要的輸入

若要有效使用 cto-review，請提供一份具備足夠營運細節的計畫，讓 skill 能挑戰其中的假設。建議包含：

• 目前規模：使用者數、每秒請求數、資料量、租戶數、區域，或交易量
• 目標規模：預期成長、10 倍情境、上線活動、企業客戶擴張，或遷移期限
• 架構：服務、datastore 選擇、queues、dependencies、部署模型，以及可靠性目標
• 限制條件：預算、團隊規模、招募計畫、合規要求、vendor 限制、期限，以及 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.」

如果第一版回答太偏推測，請補上缺漏事實，而不是只要求模型「再試一次」。這個 skill 的設計目的是審問一份計畫；當你提供真實負載資料、成本估算、人力假設，以及 incident 歷史時，它的價值會更高。

先確認的檔案與指令

唯一已確認的 skill 檔案是 SKILL.md。它包含 script call 範例，但這個特定 skill 資料夾並沒有本機 scripts。在把 scripts 納入你的工作流程之前，請先檢查安裝後是否存在以下路徑：

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

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

如果這些檔案不存在，你仍然可以手動使用 cto-review 指南：在 prompt 中提供你自己的技術債清單與團隊 ramp-up 假設即可。

cto-review skill 常見問題

cto-review 適合初學者嗎？

可以，前提是使用者有一個具體的工程決策要審查。它不是系統設計、雲端架構或資料庫選型的入門教學。資淺創辦人或產品負責人也能有效使用它：提供商業目標，並請 agent 把技術風險轉成決策問題。不過，最終判斷仍應有經驗豐富的工程師參與。

什麼時候不該使用 cto-review？

不要把 cto-review 用在小型實作選擇、例行 code review、ticket grooming，或單一狹窄缺陷的 debugging。若目前根本還沒有計畫，它也不適合。當判斷錯誤的成本很高時才使用它，例如平台遷移、高成本 vendor 決策、擴展性投資、可靠性重新設計、招募計畫，或重建提案。

它和架構審查 prompt 有什麼不同？

架構審查 prompt 通常會檢查設計模式、元件與取捨。cto-review skill 會加入高階管理壓力：技術債每週成本、團隊可擴展性、失效門檻，以及自建與採購的經濟性。因此，它更適合用於 go/no-go 審查，而不是從零產出完整 reference architecture。

cto-review 一定需要參照的 scripts 嗎？

不需要。cto-review skill 的核心是在 SKILL.md 中定義的結構化審查方法。若參照的 scripts 可用，可能會提升分析品質，但即使只透過 prompt 也能執行。請把 script support 視為選配，直到你確認本機安裝中真的存在這些檔案。

如何改進 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、incident history、cloud cost thresholds、approved vendors、security requirements，以及 architecture decision record templates。如果你使用參照的 analyzer scripts，請在 skill 附近記錄它們的路徑與預期輸入，避免未來使用者因為缺少相對路徑檔案而卡住。