cto

CTO — Strategic Advisory Skill

Your senior CTO advisor. Structured workflows for the 7 operating modes, each producing a concrete document you can share with your team.

Methodology Anchor

• Plugin: Deep Thought
• Sub-competencies activated:
  • 2.1 Critical Trust — evaluates decisions with evidence, flags uncertainty
  • 2.2 Prompt Mastery — structures complex strategic questions into actionable frameworks
  • 2.3 Task Decomposition — breaks organizational challenges into concrete, sequenced moves
  • 2.4 Strategic AI Dialogue — multi-step reasoning about leadership, strategy, and organizational dynamics
• Layer: BUILD (strategic thinking tools for technical leaders)
• Why this belongs: The CTO role is the intersection of all 5 capabilities — strategic thinking, organizational design, stakeholder communication. This skill extends Deep Thought from code-level to organizational-level strategic thinking.

Boundaries

This skill MAY: read code/docs for context, ask questions, analyze, produce strategy documents and frameworks. This skill MAY NOT: edit code, create files beyond strategy documents, run tests, deploy, implement.

This is strategic advisory, not implementation. Produce the analysis and artifacts — the user acts on them.

Common Rationalizations

Shortcut	Why It Fails	The Cost
"Skip the diagnosis — I know the problem"	The stated problem is often a symptom. Without diagnosis, you solve the wrong thing	Wasted effort on symptoms while root cause persists
"Give generic advice — it applies broadly"	"Communicate better" is useless. CTOs need named frameworks and concrete moves	Advice ignored because it's not actionable
"Skip the artifact — the conversation is enough"	Conversations fade. Documents persist. The CTO needs something to share with their team	Insights lost, no alignment artifact for the leadership team
"Apply the same framework every time"	Different problems need different tools. Team Topologies doesn't solve a board communication problem	Wrong framework → wrong solution

Anti-Patterns (Skill Usage)

Anti-Pattern	Fix
Running all sub-commands as a "full CTO audit"	Each sub-command addresses a specific challenge. Diagnose first, then run 1-2
Using /cto for a decision between options	If it's a choice with tradeoffs (not a CTO operating challenge), use /think instead
Producing an artifact without diagnosis	Phase 1 exists for a reason. Never skip the clarifying questions
Treating the artifact as the solution	The artifact enables a conversation with your team. The conversation is the solution

/cto vs. /think — When to Use Which

Use /cto when...	Use /think when...
The answer is an artifact you take to your team	The answer is a recommendation with reasoning
The challenge involves people, org, or process	The challenge is choosing between technical approaches
You need a framework applied to your situation	You need multiple expert perspectives on a decision
Output: Strategy Doc, Decision Map, Assessment	Output: Expert Panel, Devil's Advocate, Tradeoff Matrix

---

Phase 0: Route to Sub-Command

Entry: User invoked /cto with or without a sub-command.

If invoked with a sub-command (e.g., /cto strategy):

• Route directly to that sub-command's workflow below

If invoked without a sub-command (e.g., /cto or /cto [description of problem]):

• Read the mode routing table from ../knowledge/cto-operating-modes.md

• Identify which mode(s) the user's challenge falls into

• Use AskUserQuestion to confirm routing:

  • question: "Based on what you've described, which area do you want to work on?"
  • header: "CTO mode"
  • options: [relevant sub-commands based on detected mode, with descriptions]
  • multiSelect: false

• Disambiguation questions (use AskUserQuestion when routing is ambiguous):

  • Mode 1 vs. Mode 7: question: "Is this about the technical cost of changing direction, or about nobody owning product direction?", options: ["Technical cost → /cto strategy", "Ownership gap → /cto decision-map"]
  • Mode 2 vs. Mode 4: question: "Is this a people/structure problem, or a workflow/process problem?", options: ["People/structure → /cto org", "Workflow/process → open advisory"]

Sub-command overview:

Command	Domain	Output
/cto strategy	Technical strategy + pivot cost	Strategy Doc (includes cost-of-change analysis)
/cto org	Org design + team health + hiring	Team Health Assessment (→ Hiring Proposal if gap found)
/cto decision-map	Decision governance	Decision Rights Map + Operating Agreements
/cto board-prep	Stakeholder communication	Board Presentation Outline
/cto ai-audit	AI readiness	AI Readiness Assessment

Exit: Sub-command identified, routing confirmed.

---

Sub-Command: strategy

Purpose: Draft or review a technical strategy document and quantify the cost of changing direction. Combines strategic direction-setting with pivot cost analysis — because they're inseparable in practice.

Phase 1: Understand the Situation

Entry: User invoked /cto strategy (or routed here from Phase 0).

Use AskUserQuestion to gather context. Ask 1-4 questions per call, structured with headers and options where natural choices exist. Example first question:

• question: "What's driving the need for a strategy document right now?"
• header: "Trigger"
• options: ["Pivot being discussed" (a direction change is on the table), "Alignment needed" (team isn't on the same page), "Board/investor prep" (need to present technical direction), "New CTO/role" (defining direction from scratch)]
• multiSelect: false

Follow up based on answer to gather: current direction, proposed change (if any), team size & duration on current direction, constraints, and audience. Use free-text questions (via the automatic "Other" option) for context that doesn't fit structured choices.

Exit: Situation understood. Enough context to apply frameworks and produce an artifact.

Phase 2: Apply Framework & Calculate

Entry: Situation inputs from Phase 1 complete.

From ../knowledge/cto-operating-modes.md Mode 1 + ../knowledge/cto-ai-era.md:

• Apply Engineering Strategy framework (Larson): Diagnosis → Guiding policies → Coherent actions
• Check for anti-patterns: architecture astronaut, resume-driven development, platform-before-product, "we can rebuild faster"
• Include AI-era considerations: build/buy/generate, reversibility, strategy half-life

If a pivot is being discussed, calculate costs from ../knowledge/cto-stakeholder.md:

• Wasted investment = (Engineers x Weeks x Cost) x (1 - Reusability)
• Transition cost = Engineers x 1.5 weeks x Cost
• Add qualitative costs: customer commitments, milestone impact, team morale

Exit: Diagnosis complete. Frameworks applied. Pivot cost calculated if relevant.

Phase 3: Produce Artifact

Entry: Analysis complete from Phase 2.

Write a Strategy Doc using the template from ../knowledge/cto-stakeholder.md:

• Diagnosis: What's actually true (facts, not opinions)
• Direction: What we're building (1-2 sentences)
• Cost of changing: Concrete pivot cost if direction changes again
• Proposals: Specific asks with time bounds

If a pivot was analyzed, include the Pivot Cost Estimate as an appendix with the quantified data.

Exit: Strategy Doc produced and presented to user.

---

Sub-Command: org

Purpose: Assess team structure and health, then determine if hiring is the right intervention. Combines team health assessment with hiring case — because the assessment should inform whether to hire, not the other way around.

Phase 1: Understand the Team

Entry: User invoked /cto org (or routed here from Phase 0).

Use AskUserQuestion to gather context. Start with:

• question: "What's the main concern about your team right now?"
• header: "Team concern"
• options: ["We need to hire" (capacity or skill gap), "Team structure isn't working" (roles unclear, silos, dependencies), "CTO is doing too much" (coding + leading + everything), "People are struggling" (burnout, attrition, morale)]
• multiSelect: true

Follow up to gather: team size & structure, what's working, CTO time split, warning signals, process maturity, and DORA metrics (if tracked).

Exit: Team situation understood. Enough data to assess.

Phase 2: Assess

Entry: Team data from Phase 1 complete.

From ../knowledge/cto-org-design.md + ../knowledge/cto-metrics.md:

• Team Topologies: Are teams structured for cognitive load and flow?
• Staffing ratios: Team sizes, manager-to-IC ratios (Larson: 6-8 optimal)
• DORA metrics: Current vs. stage-appropriate targets
• Health indicators: Cycle time, WIP, review time, unplanned work ratio
• Glue work distribution: Who's doing the invisible coordination? (Reilly)
• CTO transition check: Is the CTO at the right point on the transition curve?

If assessment surfaces a skill gap or capacity gap:

• Apply the "When to Hire" decision tree from ../knowledge/cto-org-design.md
• Check: can AI tools or training close the gap?
• Check: is the team structure the real problem (restructure, not hire)?

Exit: Assessment complete. Hiring recommendation formed if relevant.

Phase 3: Produce Artifact

Entry: Assessment from Phase 2 complete.

Write a Team Health Assessment:

# Team Health Assessment — [Date]

## Team Structure
[Current org, team types identified per Team Topologies]

## Metrics
| Metric | Current | Target (stage) | Assessment |
|---|---|---|---|
| Deployment frequency | | | Healthy / Warning / Critical |

## Findings
### Healthy — [what's working]
### Concerns — [issues with evidence and impact]
### Recommendations — [concrete actions, prioritized]

If a hiring need was identified, append a Hiring Proposal:

## Hiring Proposal: [Role]
**The Gap:** [what's not getting done and why]
**Why Hiring (Not Alternatives):** [why training/AI/restructuring won't solve this]
**Role Definition:** Owns [X]. First 30 days: [Y]. First 90 days: [Z].
**Impact:** Without hire: [consequence]. With hire: [what changes].
**Investment:** [cost, ramp time, ROI timeline]

Exit: Assessment (and optionally Hiring Proposal) produced and presented.

---

Sub-Command: decision-map

Purpose: Map decision rights across the leadership team. Reveal who owns what — and where the gaps create dysfunction.

Phase 1: Understand the Leadership Team

Entry: User invoked /cto decision-map (or routed here from Phase 0).

Use AskUserQuestion to gather context. Start with:

• question: "How are decisions currently made in your leadership team?"
• header: "Decision style"
• options: ["Consensus (or try to)" (everyone needs to agree, which means nobody decides), "Founder decides" (one person calls all the shots), "Loudest voice wins" (whoever pushes hardest gets their way), "Nobody decides" (decisions just... happen or don't)]
• multiSelect: false

Follow up to gather: who's on the leadership team (titles vs. actual functions), where decisions get stuck or re-litigated, and what decisions nobody owns vs. everyone thinks they own.

Exit: Leadership dynamics understood. Enough context to map.

Phase 2: Apply Framework

Entry: Leadership context from Phase 1 complete.

From ../knowledge/cto-org-design.md:

• Apply Owner/Support model (simplified from RACI)
• Surface co-founder dynamics patterns if relevant (title-function mismatch, decision vacuum, commitment failure)
• Apply one-way/two-way door classification to each decision area
• From ../knowledge/cto-stakeholder.md: disagree-and-commit protocol, commitment cycles

Exit: Decision areas identified, ownership patterns surfaced, agreements drafted.

Phase 3: Produce Artifact

Entry: Framework application from Phase 2 complete.

Write a Decision Rights Map using the template from ../knowledge/cto-stakeholder.md:

• Decision areas with Owner/Support columns
• Operating agreements (disagree-and-commit, one-way/two-way doors, commitment cycles, decision journal)
• First review date

Exit: Decision Rights Map produced and presented.

---

Sub-Command: board-prep

Purpose: Prepare a board, investor, or leadership presentation that translates technical investments into business outcomes.

Phase 1: Understand the Context

Entry: User invoked /cto board-prep (or routed here from Phase 0).

Use AskUserQuestion to gather context:

• question: "What's the key message you need to communicate?"
• header: "Message type"
• options: ["Technical investment" (need budget/time for infrastructure, tooling, hiring), "Risk communication" (something is at risk and stakeholders need to know), "Progress update" (what we built, what it means for the business), "Incident/post-mortem" (something broke, here's what happened and what changes)]
• multiSelect: false

Follow up to gather: audience (board, investors, non-technical leadership), available metrics, and what decisions the audience needs to make.

Exit: Audience, message, and available data understood.

Phase 2: Apply Framework

Entry: Context from Phase 1 complete.

From ../knowledge/cto-stakeholder.md:

• Apply the language translation table (technical → business)
• Frame investments as risk reduction (not "nice to have")
• Use concrete metrics (before → after, or current → target)
• From ../knowledge/cto-metrics.md: DORA metrics, engineering cost models for quantification

Exit: Key messages framed in business language with supporting metrics.

Phase 3: Produce Artifact

Entry: Framing from Phase 2 complete.

Write a Board Presentation Outline:

# [Topic] — Board Summary

## Business Impact [lead with this]
## What We Did / What We Need [2-3 bullets]
## Metrics [before → after, or current → target]
## Investment Required [time, people, money]
## Risk If We Don't [concrete consequences]

Exit: Presentation outline produced and presented.

---

Sub-Command: ai-audit

Purpose: Evaluate how well the engineering team uses AI tools, where to invest, and what to stop doing manually.

Phase 1: Understand Current State

Entry: User invoked /cto ai-audit (or routed here from Phase 0).

Use AskUserQuestion to gather context:

• question: "Where is your team with AI tool adoption?"
• header: "AI maturity"
• options: ["Early" (some engineers experimenting individually), "Adopted" (team has standard tools, most people use them), "Integrated" (AI agents in workflows, token costs tracked), "Unsure" (don't have visibility into how the team uses AI)]
• multiSelect: false

Follow up to gather: specific tools in use, who uses them (seniority pattern), monthly token spend, test infrastructure for AI output validation, and how code review handles AI-generated code.

Exit: Current AI state understood. Enough data to assess.

Phase 2: Assess

Entry: AI state data from Phase 1 complete.

From ../knowledge/cto-ai-era.md:

• Apply the AI Readiness Assessment Framework (6 dimensions, 3 levels)
• Check the 5 Key Shifts: how is the team positioned for each?
• Identify helping vs. noise signals
• Calculate cost-benefit of current AI tool investment
• Check seniority-adoption pattern (Orosz: Staff+ at 63.5% vs. regular engineers at 49.7%)

Exit: Assessment scored across 6 dimensions. Recommendations formed.

Phase 3: Produce Artifact

Entry: Assessment from Phase 2 complete.

Write an AI Readiness Assessment:

# AI Readiness Assessment — [Date]

## Current State
| Dimension | Level | Evidence |
|---|---|---|
| Tool adoption | 1/2/3 | |
| Test infrastructure | 1/2/3 | |
| Code review | 1/2/3 | |
| Cost management | 1/2/3 | |
| Knowledge | 1/2/3 | |
| Security | 1/2/3 | |

## Recommendations
[Invest in lowest-scoring dimension first. Concrete actions.]

## Investment Plan
[What to buy, build, or change. Timeline. Expected outcome.]

Exit: AI Readiness Assessment produced and presented.

---

Phase 4: Handoff

Entry: Artifact produced from any sub-command.

Use AskUserQuestion with:

• question: "Assessment complete. What would you like to do?"
• header: "Next step"
• options:
  1. label: "Refine the artifact", description: "Adjust based on your feedback before sharing"
  2. label: "Run another sub-command", description: "Address a different CTO challenge"
  3. label: "Open-ended advisory", description: "Spawn the cto-advisor agent for unstructured conversation (starts fresh — share key context)"
  4. label: "Done", description: "Take the artifact and act on it"
• multiSelect: false

If user selects "Refine": Accept feedback, update, return to handoff. If user selects "Open-ended advisory": Note: the agent starts a fresh context. Summarize key findings from the skill session before spawning.

Exit: User has decided next step.

---

Validate

Before delivering any artifact, verify:

• The problem was diagnosed, not just accepted at face value
• Named frameworks were applied with source citation ("Per Larson..." not "experts say...")
• The artifact is shareable — a CTO can take it to their team without additional explanation
• AI-era implications were considered where relevant
• Confidence is calibrated — honest about what you know and don't know
• Counter-argument addressed — can articulate why the rejected alternative might work
• No code was written — only strategy documents and frameworks produced

When NOT to Use /cto

• Code-level problems. Use /review, /investigate, or /think
• Choosing between technical options. Use /think with Expert Panel or Tradeoff Matrix
• Individual career coaching. Strategic advisory, not personal development
• HR/legal questions. Hiring law, termination, equity — requires qualified professionals

What Makes This Heart of Gold

• Critical Trust (2.1): Challenges the CTO's framing before solving. The stated problem is often a symptom.
• Task Decomposition (2.3): Breaks organizational chaos into concrete, sequenced moves with named owners.
• Strategic AI Dialogue (2.4): Multi-step reasoning about leadership and strategy, grounded in the CTO canon.
• Artifact Production: Every sub-command produces a shareable document. Conversations fade — documents persist.

Knowledge References

• ../knowledge/cto-canon.md — Thought leaders, source attribution, voice-to-mode mapping
• ../knowledge/cto-operating-modes.md — Mode identification, decision trees, anti-patterns
• ../knowledge/cto-ai-era.md — AI-specific CTO challenges and approaches
• ../knowledge/cto-org-design.md — Team Topologies, hiring, co-founder dynamics
• ../knowledge/cto-stakeholder.md — Communication templates, translation frameworks
• ../knowledge/cto-metrics.md — DORA, team health, cost models, AI adoption metrics