mcpField
C
cto-review

cto-review

github.com/alirezarezvaniDevelopment28.9k401 installsUpdated 2d ago
Repository

About cto-review

A CTO review skill that pressure-tests architecture and engineering scaling decisions through six questions on capacity, technical debt, hiring, build-versus-buy, reliability, and security. It is intended for teams evaluating major technical commitments before they act.

Key features

  1. 01识别架构扩展瓶颈
  2. 02盘点技术债务
  3. 03评估团队扩张与招聘
  4. 04比较自建和采购成本
  5. 05检查 SLO 与可靠性
  6. 06审视安全与合规影响

Use cases

  1. 01审批重大架构变更前检查扩展风险
  2. 02工程团队扩张前评估招聘投入
  3. 03年度成本超过 10 万美元的构建或采购决策
  4. 04系统未达到 SLO 时审查可靠性问题

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/alirezarezvani/claude-skills --skill cto-review

After installing, type/cto-reviewin Claude Code to confirm it loaded.

Details

From the project README

/c-level-agents:cto-review — CTO Forcing Questions

Command: /c-level-agents:cto-review <plan>

Pressure-tests architecture and engineering scaling decisions. Six questions to surface the next scaling cliff before you hit it.

When to Run

  • Before approving a major architecture change
  • Before doubling the engineering team
  • Before a build-vs-buy decision > $100K/year
  • When a system is showing reliability stress (SLOs missed)
  • Before committing to a new platform / language / DB

The Six CTO Questions

1. Scaling Cliff

Where does the current architecture break, in terms of users / requests / data volume?

  • Be specific. "It breaks at 10× current load because the primary DB writes saturate."
  • If you don't know, run a load test before deciding.
2. Tech Debt Inventory

What's the top tech debt item, what's it costing per week, and when does it become blocking?

python ${CLAUDE_PLUGIN_ROOT}/vendor/c-level-advisor/cto-advisor/scripts/tech_debt_analyzer.py
3. Team Scaling

For each open req, what's the ramp time and contribution model?

python ${CLAUDE_PLUGIN_ROOT}/vendor/c-level-advisor/cto-advisor/scripts/team_scaling_calculator.py
4. Build vs Buy

Why are we building this instead of buying it — and what's the 3-year TCO of each?

  • If "we want control" or "it's not that hard" — push back.
  • If the answer is "this is our core moat," build.
5. SLO / Reliability

What are the SLOs for this system and what's the current error budget burn?

  • Without an SLO, you can't reason about reliability tradeoffs.
  • See engineering/slo-architect for SLO design.
6. Security & Compliance Surface

What does this expose, and has cs-ciso-advisor signed off?

  • Architecture decisions are compliance decisions.
  • Loop in cs-ciso-advisor before commit.

Workflow

  1. Run the tech debt analyzer + team scaling calculator
  2. Define the scaling-cliff hypothesis explicitly
  3. Cross-check with cs-ciso-advisor for security implications
  4. Apply the verdict

Output Format

# CTO Review: <plan>
**Date:** YYYY-MM-DD

## Scaling Cliff
- Current capacity: <metric>
- Break point: <metric>
- Headroom: X months at current growth

## Tech Debt
- Top item: <description>
- Cost per week: $X or N eng-hours
- Blocking date estimate: <date>

## Team
- Open reqs: N
- Median ramp: X months
- Contribution model: <pairing / squad / area>

## Build vs Buy
- 3-year build TCO: $X
- 3-year buy TCO: $X
- Strategic fit: <core / context>
- Decision: BUILD | BUY

## Reliability
- SLO defined: yes / no
- Error budget burn: X% (target < Y%)

## Security
- cs-ciso sign-off: ✅ / ❌

## Verdict
🟢 SHIP | 🟡 SHARPEN | 🔴 BLOCK

## Next Steps
[3 concrete actions]

Routing

  • /c-level-agents:ciso-review — mandatory if data surface changes
  • /c-level-agents:cfo-review — for build-vs-buy > $100K
  • /c-level-agents:execute — quarterly plan
  • /c-level-agents:boardroom — for architecture pivots

Related


Version: 1.0.0

Comments

Markdown supported