What does the Cto Advisor AI skill do?

CTO-level advisory - build vs buy decisions, tech debt quantification, team scaling, ADRs, technology evaluation (RICE), budget planning, TCO, vendor management, DORA/SPACE metrics

Why use Cto Advisor on TypingMind?

Because you install it once and use it with any model. Cto Advisor is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Cto Advisor in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/vibeeval/vibecosystem/tree/main/skills/cto-advisor. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Cto Advisor?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Cto Advisor?

As many as you like. As long as a model supports skills, you can use Cto Advisor with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Cto Advisor AI skill free?

Yes. It is published on GitHub by vibeeval under the MIT license. You only pay your own AI provider for the tokens you use.

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

Cto Advisor by vibeeval — AI Skill for Any LLM

CTO Advisor

Build vs Buy Decision Framework

Decision Matrix

markdown
## Build vs Buy Analysis: [Feature/System Name]

### Scoring (1-5 each)

| Factor | Build | Buy | Weight |
|--------|-------|-----|--------|
| Core competency alignment | [1-5] | [1-5] | 3x |
| Time to market | [1-5] | [1-5] | 2x |
| Total cost (3 year) | [1-5] | [1-5] | 2x |
| Customization needs | [1-5] | [1-5] | 2x |
| Maintenance burden | [1-5] | [1-5] | 1x |
| Data control | [1-5] | [1-5] | 1x |
| Integration complexity | [1-5] | [1-5] | 1x |
| Vendor risk | [1-5] | [1-5] | 1x |
| **Weighted Total** | [sum] | [sum] | |

### Decision: BUILD / BUY / HYBRID

Decision Rules

Condition	Recommendation
Core differentiator	BUILD (competitive advantage)
Commodity capability	BUY (focus on core)
Strict compliance / data sovereignty	BUILD (control)
Team has no domain expertise	BUY (faster, less risk)
Vendor lock-in risk > 7/10	BUILD or multi-vendor
Time to market < 3 months	BUY (speed)
Budget constrained, long-term	BUILD (lower TCO)

Build vs Buy Anti-Patterns

Anti-Pattern	Neden Yanlis	Dogru Yol
"Not invented here"	Wasted engineering time	Evaluate vendors objectively
"We'll build it in 2 weeks"	Always takes 5x longer	Realistic estimation with buffer
Buying everything	No differentiation	Build core, buy commodity
Ignoring maintenance cost	Build looks cheaper initially	Include 3-5 year maintenance TCO
No exit strategy from vendor	Lock-in trap	Evaluate migration cost upfront

Tech Debt Quantification & Prioritization

Tech Debt Classification

Type	Description	Impact	Example
Code debt	Poor code quality	Developer velocity	No types, huge functions, no tests
Architecture debt	Wrong architectural decisions	Scalability	Monolith that should be microservice
Test debt	Insufficient test coverage	Reliability	No integration tests, flaky tests
Dependency debt	Outdated dependencies	Security	3 major versions behind, CVEs
Documentation debt	Missing/outdated docs	Onboarding	No API docs, stale README
Infrastructure debt	Manual processes, legacy infra	Reliability	No CI/CD, manual deployments
Design debt	UX inconsistencies	User experience	5 different button styles

Tech Debt Scorecard

markdown
## Tech Debt Assessment: [Project Name]

| Area | Score (1-10) | Trend | Priority |
|------|-------------|-------|----------|
| Code quality | [X] | [up/down/flat] | [H/M/L] |
| Test coverage | [X%] | [up/down/flat] | [H/M/L] |
| Dependency freshness | [X] | [up/down/flat] | [H/M/L] |
| Build/deploy time | [X min] | [up/down/flat] | [H/M/L] |
| Documentation | [X] | [up/down/flat] | [H/M/L] |
| Security posture | [X] | [up/down/flat] | [H/M/L] |

### Cost of Delay
[If we don't address debt area X, what happens in 6 months?]

### Investment Request
| Initiative | Effort | Impact | ROI Period |
|-----------|--------|--------|------------|
| [debt 1] | [weeks] | [description] | [months] |
| [debt 2] | [weeks] | [description] | [months] |

Prioritization Formula


Priority Score = (Impact * Urgency * Spread) / Effort

Impact (1-5):    How much does it slow the team?
Urgency (1-5):   How quickly will it get worse?
Spread (1-5):    How many areas does it affect?
Effort (1-5):    How hard is it to fix? (inverse: 1=hard, 5=easy)

Tech Debt Budget Rule


RULE: 20% of sprint capacity reserved for tech debt reduction

Sprint capacity: 10 story points
├── 8 points: Feature work
└── 2 points: Tech debt reduction (ZORUNLU, negotiable degil)

Team Scaling Strategies

Hiring Framework

markdown
## Hiring Plan: [Quarter/Year]

### Current State
| Role | Headcount | Capacity | Gap |
|------|-----------|----------|-----|
| Backend | [X] | [Y features/quarter] | [shortfall] |
| Frontend | [X] | [Y features/quarter] | [shortfall] |
| DevOps | [X] | [Y deploys/week] | [shortfall] |
| QA | [X] | [Y tests/sprint] | [shortfall] |

### Ratios
- Engineer : Manager = 6-8 : 1
- Senior : Mid : Junior = 2 : 3 : 1
- Backend : Frontend = project-dependent
- Engineer : QA = 4-6 : 1

### Onboarding Milestones
| Day | Milestone |
|-----|-----------|
| 1 | Dev environment running, first commit |
| 7 | First PR merged |
| 14 | First feature shipped to staging |
| 30 | Independent task completion |
| 60 | Contributing to architecture discussions |
| 90 | Fully productive, mentoring others |

Team Topology Patterns

Pattern	When to Use	Size
Stream-aligned	Product features	5-8 people
Platform	Internal tooling, infrastructure	3-5 people
Enabling	Coach other teams, remove blockers	2-3 people
Complicated subsystem	Deep expertise (ML, security)	2-4 people

Architecture Decision Records (ADR)

ADR Template

markdown
# ADR-[number]: [decision title]

## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]

## Context
[What is the issue? What forces are at play?]
[Include constraints, requirements, team capabilities]

## Decision
[What is the change that we're proposing and/or doing?]

## Alternatives Considered
### Option A: [name]
- Pros: [list]
- Cons: [list]

### Option B: [name]
- Pros: [list]
- Cons: [list]

## Consequences
### Positive
- [benefit 1]
- [benefit 2]

### Negative
- [tradeoff 1]
- [tradeoff 2]

### Risks
- [risk 1]: [mitigation]
- [risk 2]: [mitigation]

## Decision Date
[YYYY-MM-DD]

## Decision Makers
[names/roles]

ADR Index

markdown
## Architecture Decision Log

| # | Decision | Status | Date | Impact |
|---|---------|--------|------|--------|
| 001 | Use PostgreSQL over MongoDB | Accepted | 2025-01-15 | High |
| 002 | Adopt microservices for billing | Accepted | 2025-02-01 | High |
| 003 | Use React over Vue | Accepted | 2025-02-15 | Medium |
| 004 | Monolith-first for MVP | Deprecated | 2025-03-01 | High |

Technology Evaluation Framework

RICE Scoring

markdown
## Technology Evaluation: [Technology Name]

### RICE Score

| Factor | Score | Weight | Weighted |
|--------|-------|--------|----------|
| **Reach** (how many people/teams affected) | [1-10] | 1x | [X] |
| **Impact** (how much improvement per person) | [1-3: minimal/medium/massive] | 2x | [X] |
| **Confidence** (how sure are we) | [50-100%] | 1x | [X] |
| **Effort** (person-months) | [X] | divisor | [X] |

**RICE Score = (Reach * Impact * Confidence) / Effort = [score]**

Weighted Scoring Matrix

markdown
## Vendor/Technology Comparison

| Criteria | Weight | Option A | Option B | Option C |
|----------|--------|----------|----------|----------|
| Performance | 20% | [1-5] | [1-5] | [1-5] |
| Community/support | 15% | [1-5] | [1-5] | [1-5] |
| Learning curve | 15% | [1-5] | [1-5] | [1-5] |
| Cost | 15% | [1-5] | [1-5] | [1-5] |
| Scalability | 10% | [1-5] | [1-5] | [1-5] |
| Security | 10% | [1-5] | [1-5] | [1-5] |
| Integration | 10% | [1-5] | [1-5] | [1-5] |
| Maturity | 5% | [1-5] | [1-5] | [1-5] |
| **Weighted Total** | | [sum] | [sum] | [sum] |

### Recommendation: [Option X]
### Reasoning: [1-2 sentences]

Technology Evaluation Anti-Patterns

Anti-Pattern	Risk	Dogru Yol
Resume-driven development	Wrong tool for the job	Evaluate against actual needs
Hype-driven adoption	Immature ecosystem	Wait for version 2.0+
Single vendor evaluation	No comparison baseline	Always evaluate 3+ options
Ignoring exit cost	Future lock-in	Calculate migration cost
No POC/prototype	Unknown unknowns	Build spike before committing

Budget Planning & TCO Analysis

TCO Template (3-Year)

markdown
## Total Cost of Ownership: [System/Technology]

### Year 1 (Setup + Operations)
| Category | Cost |
|----------|------|
| Licenses/subscriptions | $[X] |
| Infrastructure (cloud/hardware) | $[X] |
| Implementation/migration | $[X] |
| Training | $[X] |
| Integration development | $[X] |
| **Year 1 Total** | **$[X]** |

### Year 2-3 (Ongoing)
| Category | Annual Cost |
|----------|------------|
| Licenses/subscriptions (+ annual increase) | $[X] |
| Infrastructure | $[X] |
| Maintenance engineering (FTE fraction) | $[X] |
| Support contracts | $[X] |
| Upgrades/patches | $[X] |
| **Annual Ongoing** | **$[X]** |

### 3-Year TCO: $[Year 1 + Year 2 + Year 3]

### Hidden Costs (often missed)
- Context switching overhead
- On-call/incident response time
- Documentation maintenance
- Vendor management overhead
- Compliance/audit costs

Vendor Management

Vendor Assessment Checklist

Vendor Risk Matrix

Risk	Likelihood	Impact	Mitigation
Vendor acquired/shutdown	Low	Critical	Data export procedure, backup vendor
Price increase > 30%	Medium	High	Multi-year contract, alternative evaluation
SLA breach	Medium	High	Credits, contractual remedies
Data breach at vendor	Low	Critical	Encryption, contractual liability
Feature deprecation	Medium	Medium	API abstraction layer

Engineering Metrics

DORA Metrics

Metric	Elite	High	Medium	Low
Deployment Frequency	On-demand (multiple/day)	Daily-weekly	Weekly-monthly	Monthly-6monthly
Lead Time for Changes	< 1 hour	1 day - 1 week	1 week - 1 month	1 - 6 months
Change Failure Rate	0-15%	16-30%	16-30%	16-30%
Mean Time to Recovery	< 1 hour	< 1 day	1 day - 1 week	> 1 week

SPACE Framework

Dimension	Metrics	How to Measure
Satisfaction	Developer satisfaction survey	Quarterly survey (1-5 scale)
Performance	Code review turnaround, incident resolution	Tooling metrics
Activity	PRs merged, deploys, commits	Git/CI data (NOT for evaluation)
Communication	Knowledge sharing, documentation	Survey + doc metrics
Efficiency	Dev environment setup time, build time	Measure and track

Engineering Health Dashboard

markdown
## Engineering Health: [Quarter]

### DORA Metrics
| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| Deploy frequency | Daily | [X/week] | [on/off track] |
| Lead time | < 1 day | [X hours] | [on/off track] |
| Change failure rate | < 15% | [X%] | [on/off track] |
| MTTR | < 1 hour | [X min] | [on/off track] |

### Team Health
| Area | Score (1-10) | Trend |
|------|-------------|-------|
| Developer satisfaction | [X] | [up/down/flat] |
| On-call burden | [X] | [up/down/flat] |
| Tech debt sentiment | [X] | [up/down/flat] |
| Tooling satisfaction | [X] | [up/down/flat] |

### Actionable Insights
1. [Insight + recommended action]
2. [Insight + recommended action]

Board/Investor Technical Reporting

Quarterly Tech Report Template

markdown
## Technology Report: Q[X] [Year]

### Executive Summary
[2-3 sentences: key wins, risks, requests]

### Key Metrics
| Metric | Q-1 | Q0 | Target | Trend |
|--------|-----|-----|--------|-------|
| Uptime | [X%] | [X%] | 99.9% | [arrow] |
| Page load time | [Xs] | [Xs] | < 2s | [arrow] |
| Active users | [X] | [X] | [target] | [arrow] |
| Deploy frequency | [X/mo] | [X/mo] | Daily | [arrow] |

### Achievements
1. [Milestone/launch/improvement]
2. [Milestone/launch/improvement]

### Risks & Challenges
| Risk | Severity | Mitigation | Status |
|------|----------|-----------|--------|
| [risk] | [H/M/L] | [plan] | [active/mitigated] |

### Budget
| Category | Budget | Actual | Variance |
|----------|--------|--------|----------|
| Infrastructure | $[X] | $[X] | [+/-X%] |
| Licenses | $[X] | $[X] | [+/-X%] |
| Headcount | $[X] | $[X] | [+/-X%] |

### Next Quarter Focus
1. [Priority 1]
2. [Priority 2]
3. [Priority 3]

### Resource Request
[If applicable: what do we need and why]

Board Communication Anti-Patterns

Anti-Pattern	Neden Yanlis	Dogru Yol
Too much jargon	Board members aren't engineers	Translate to business impact
Only good news	Erodes trust	Honest + solution-oriented
No metrics	Unverifiable	Data-driven with trends
Feature list only	No business context	Connect features to revenue/growth
Asking for budget without ROI	Unlikely approval	Show expected return

Publisher	vibeeval
Repository	`vibecosystem`
Skill name	`cto-advisor`
Stars	533
Forks	44
Bundled files	Instructions only
License	MIT
Links	Skill source Repository

Overview

Installation

Install in TypingMind

Install in another agent

Use it in TypingMind

Works with any AI model

Skill instructions

CTO Advisor

Build vs Buy Decision Framework

Decision Matrix

Decision Rules

Build vs Buy Anti-Patterns

Tech Debt Quantification & Prioritization

Tech Debt Classification

Tech Debt Scorecard

Prioritization Formula

Tech Debt Budget Rule

Team Scaling Strategies

Hiring Framework

Team Topology Patterns

Architecture Decision Records (ADR)

ADR Template

ADR Index

Technology Evaluation Framework

RICE Scoring

Weighted Scoring Matrix

Technology Evaluation Anti-Patterns

Budget Planning & TCO Analysis

TCO Template (3-Year)

Vendor Management

Vendor Assessment Checklist

Vendor Risk Matrix

Engineering Metrics

DORA Metrics

SPACE Framework

Engineering Health Dashboard

Board/Investor Technical Reporting

Quarterly Tech Report Template

Board Communication Anti-Patterns

Frequently asked questions

Related AI Skills

Set up your own AI workspace now