/cs:cto-review — CTO Forcing Questions

/cs:cto-review <plan> — Architecture and scaling interrogation.

How to use it

Claude Code
  1. Run the line below. It pulls the whole folder into ~/.claude/skills/cto-review.
  2. Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit alirezarezvani/claude-skills/c-level-agents/skills/cto-review#main ~/.claude/skills/cto-review

For one project only, change the path to .claude/skills/cto-review.

Claude (web or desktop app)
  1. On this page open ⋯ → Download .md.
  2. Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
  3. Pick the file and Save. Claude shows the name and description and runs a security scan.
  4. Check the skill is switched on.
  5. Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
  1. ChatGPT: make a Project and paste it into Instructions.
  2. Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
  • Check which app you pasted it into — the steps above name the right one.
  • Some skills need the paid tier of Claude or ChatGPT.
Step-by-step guide with screenshots · Ask in the forum

Paste into Claude, ChatGPT or Cursor.

Source of /cs:cto-review — CTO Forcing Questions

Show the full text118 lines
namedescription
cto-review/cs:cto-review <plan> — Architecture and scaling interrogation. Tech debt, scaling cliffs, team scaling, build-vs-buy. Use when committing to an architecture, planning for 10x load, or weighing a rebuild against a vendor.

/cs:cto-review — CTO Forcing Questions

Command: /cs: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 ../../../c-level-advisor/skills/cto-advisor/scripts/tech_debt_analyzer.py
3. Team Scaling

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

python ../../../c-level-advisor/skills/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

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

Version: 1.0.0

1---
2name: "cto-review"
3description: "/cs:cto-review <plan> — Architecture and scaling interrogation. Tech debt, scaling cliffs, team scaling, build-vs-buy. Use when committing to an architecture, planning for 10x load, or weighing a rebuild against a vendor."
4---
5 
6# /cs:cto-review — CTO Forcing Questions
7 
8**Command:** `/cs:cto-review <plan>`
9 
10Pressure-tests architecture and engineering scaling decisions. Six questions to surface the next scaling cliff before you hit it.
11 
12## When to Run
13 
14- Before approving a major architecture change
15- Before doubling the engineering team
16- Before a build-vs-buy decision > $100K/year
17- When a system is showing reliability stress (SLOs missed)
18- Before committing to a new platform / language / DB
19 
20## The Six CTO Questions
21 
22### 1. Scaling Cliff
23**Where does the current architecture break, in terms of users / requests / data volume?**
24- Be specific. "It breaks at 10× current load because the primary DB writes saturate."
25- If you don't know, run a load test before deciding.
26 
27### 2. Tech Debt Inventory
28**What's the top tech debt item, what's it costing per week, and when does it become blocking?**
29```bash
30python ../../../c-level-advisor/skills/cto-advisor/scripts/tech_debt_analyzer.py
31```
32 
33### 3. Team Scaling
34**For each open req, what's the ramp time and contribution model?**
35```bash
36python ../../../c-level-advisor/skills/cto-advisor/scripts/team_scaling_calculator.py
37```
38 
39### 4. Build vs Buy
40**Why are we building this instead of buying it — and what's the 3-year TCO of each?**
41- If "we want control" or "it's not that hard" — push back.
42- If the answer is "this is our core moat," build.
43 
44### 5. SLO / Reliability
45**What are the SLOs for this system and what's the current error budget burn?**
46- Without an SLO, you can't reason about reliability tradeoffs.
47- See `engineering/slo-architect` for SLO design.
48 
49### 6. Security & Compliance Surface
50**What does this expose, and has cs-ciso-advisor signed off?**
51- Architecture decisions are compliance decisions.
52- Loop in cs-ciso-advisor before commit.
53 
54## Workflow
55 
561. Run the tech debt analyzer + team scaling calculator
572. Define the scaling-cliff hypothesis explicitly
583. Cross-check with cs-ciso-advisor for security implications
594. Apply the verdict
60 
61## Output Format
62 
63```markdown
64# CTO Review: <plan>
65**Date:** YYYY-MM-DD
66 
67## Scaling Cliff
68- Current capacity: <metric>
69- Break point: <metric>
70- Headroom: X months at current growth
71 
72## Tech Debt
73- Top item: <description>
74- Cost per week: $X or N eng-hours
75- Blocking date estimate: <date>
76 
77## Team
78- Open reqs: N
79- Median ramp: X months
80- Contribution model: <pairing / squad / area>
81 
82## Build vs Buy
83- 3-year build TCO: $X
84- 3-year buy TCO: $X
85- Strategic fit: <core / context>
86- Decision: BUILD | BUY
87 
88## Reliability
89- SLO defined: yes / no
90- Error budget burn: X% (target < Y%)
91 
92## Security
93- cs-ciso sign-off: ✅ / ❌
94 
95## Verdict
96🟢 SHIP | 🟡 SHARPEN | 🔴 BLOCK
97 
98## Next Steps
99[3 concrete actions]
100```
101 
102## Routing
103 
104- `/cs:ciso-review` — mandatory if data surface changes
105- `/cs:cfo-review` — for build-vs-buy > $100K
106- `/cs:execute` — quarterly plan
107- `/cs:boardroom` — for architecture pivots
108 
109## Related
110 
111- Agent: [`cs-cto-advisor`](../../../agents/c-level/cs-cto-advisor.md)
112- Skill: [`cto-advisor`](../../../c-level-advisor/skills/cto-advisor/SKILL.md)
113- SLO: `../../../engineering/slo-architect/`
114 
115---
116 
117**Version:** 1.0.0
118 

Discussion

Alternatives

Also in ArchitectureSee all 533 in Development →
A Philosophy of Software Design FrameworkManage software complexity through deep modules, information hiding, and strategic programming. Use when the user mentions "module design", "API too complex", "shallow class", "complexity budget", "strategic vs tactical", "deep module", "information leakage", "pass-through method", "this code is over-engineered", or "simplify this design". Also trigger when reviewing an interface for simplicity, evaluating whether an abstraction is pulling its weight, deciding whether a comment is worth writing, or choosing between general-purpose and special-purpose approaches. Covers deep vs shallow modules, red flags for complexity, and comments as design documentation. For code quality, see clean-code. For architecture boundaries, see clean-architecture.Coding · MITArchitecture optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.Coding · MITArchitecture & UI/UX AuditIt asks an AI to assume the persona of a Senior Frontend Engineer & Product Reviewer to perform a high-level critique of a Next.js (App Router) project. Instead of writing code, the prompt focuses on evaluating the architecture (folder structure, scalability), UI/UX (hierarchy, consistency), and design system (component reuse) of a developer community platform to identify anti-patterns and suggest high-impact improvements.Coding · CC0-1.0Candle pattern trading chart generatorGenerate a chart showing buy below and sell above candle patterns to indicate optimal trading points.Coding · CC0-1.0