cto-review

cto-review skill の概要

cto-review ができること

cto-review は、アーキテクチャ、スケーリング、技術的負債、採用、内製か購入かといった意思決定を、高額なコミットメントになる前に検証するための戦略的エンジニアリングレビュー skill です。コマンドパターン /cs:cto-review <plan> を前提に設計されており、「どこでシステムが破綻するのか」「どの負債がブロッカーになりつつあるのか」「チームはこの計画に合わせてスケールできるのか」「内製より購入のほうが合理的ではないか」といった、CTO 目線の厳しい問いを投げかけます。

Strategic Planning の意思決定に向いているケース

cto-review skill が最も効果を発揮するのは、漠然としたアイデアではなく、すでに具体的な計画がある場合です。たとえば、新しいデータベースの採用可否、トラフィック 10 倍への備え、レガシーシステムを再構築すべきかの判断、プラットフォーム移行の評価、経営層向けの技術戦略レビュー準備などに適しています。特に、エンジニアリング上の選択が予算、採用、信頼性、長期的な実行リスクに影響する Strategic Planning で有用です。

汎用プロンプトとの違い

一般的な AI プロンプトでも、広めのアーキテクチャ助言は得られるかもしれません。cto-review は、スケーリングの崖、技術的負債の週次コスト、チーム立ち上がりの制約、3 年間の総所有コストをあぶり出す 6 つの意思決定質問に会話を絞り込みます。その構造により、自由なブレインストーミングよりも、経営レビュー、アーキテクチャ承認、コミット前のリスク分析に向いています。

導入前に知っておくべき注意点

この skill のリポジトリパスには単一の SKILL.md が含まれており、skill フォルダ内にローカルの README.md、metadata.json、rules、resources、同梱ヘルパースクリプトはありません。ソースでは、より広い cto-advisor 領域配下の相対パスで analyzer scripts を参照しているため、それらのコマンドに依存する前に、インストール済み環境でスクリプトが利用できるか確認してください。cto-review の中核的な価値はレビューの枠組みにあります。自動化には追加セットアップが必要になる場合があります。

cto-review skill の使い方

cto-review のインストールとリポジトリ確認

GitHub の skill collection から、使用している skill manager でインストールします。例:

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

インストール後、次のファイルを開きます。

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

このファイルにはコマンド、トリガー条件、6 つの CTO 質問が書かれているため、最初に読むべきです。また、エージェント環境が相対パスを保持する場合は、周辺のリポジトリ構成も確認してください。この skill は、cto-advisor/scripts/tech_debt_analyzer.py や cto-advisor/scripts/team_scaling_calculator.py など、ローカルフォルダ外のスクリプトを参照しています。

skill に渡すべき入力

cto-review を有効に使うには、前提を突けるだけの運用上の具体性を持った計画を渡してください。含めるべき情報は次のとおりです。

• 現在のスケール: ユーザー数、requests per second、データ量、テナント数、リージョン数、トランザクション数
• 目標スケール: 想定成長、10 倍シナリオ、ローンチイベント、エンタープライズ展開、移行期限
• アーキテクチャ: サービス構成、datastore の選択、queues、依存関係、デプロイモデル、信頼性目標
• 制約: 予算、チーム規模、採用計画、コンプライアンス、ベンダー制約、期限、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 のガイドを手動で活用できます。

cto-review skill FAQ

cto-review は初心者にも向いていますか？

はい。レビューしたい具体的なエンジニアリング上の意思決定があるなら有用です。ただし、システム設計、クラウドアーキテクチャ、データベース選定を基礎から学ぶ初心者向けチュートリアルではありません。ジュニアな創業者やプロダクトリーダーでも、事業目標を提示し、技術リスクを意思決定上の問いに翻訳するようエージェントに依頼すれば効果的に使えます。ただし、最終判断には経験豊富なエンジニアを関与させるべきです。

cto-review を使わないほうがよい場面は？

小さな実装判断、通常のコードレビュー、チケット整理、狭い範囲の不具合調査には cto-review を使うべきではありません。また、そもそも計画が存在しない段階にも向きません。間違った場合のコストが大きいとき、つまりプラットフォーム移行、高額なベンダー選定、スケーリング投資、信頼性の再設計、採用計画、再構築提案などで使うのが適しています。

アーキテクチャレビュー用プロンプトとはどう違いますか？

アーキテクチャレビュー用プロンプトは、設計パターン、コンポーネント、トレードオフを確認することが多いです。cto-review skill はそこに経営レベルの圧力を加えます。負債の週次コスト、チームのスケーラビリティ、障害が顕在化する閾値、build-vs-buy の経済性を扱うため、ゼロから完全なリファレンスアーキテクチャを作る用途よりも、go/no-go レビューに向いています。

cto-review に参照スクリプトは必須ですか？

いいえ。cto-review skill の中核は、SKILL.md に記載された構造化レビュー手法です。参照されているスクリプトが利用できれば分析を補強できる可能性はありますが、プロンプトだけでも skill は機能します。ローカルインストールで該当ファイルの存在を確認するまでは、スクリプト対応は任意のものとして扱ってください。

cto-review skill を改善する方法

判断を求める前に cto-review への入力を改善する

最もよくある失敗は、数値なしで CTO レビューを依頼することです。おおよそのレンジでも構いません。“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 を改善するには、SLOs、インシデント履歴、クラウドコストの閾値、承認済みベンダー、セキュリティ要件、architecture decision record のテンプレートに関する社内チェックリストを追加します。参照されている analyzer scripts を使う場合は、将来の利用者が相対ファイルの欠落で詰まらないよう、skill の近くにパスと期待される入力を文書化してください。