Cto Advisor
Capture and draft Architecture Decision Records so stack and structure choices stay explainable as a solo CTO.
Overview
CTO Advisor is an agent skill most often used in Build (also Validate, Ship) that guides you through writing Architecture Decision Records with context, options, and consequences.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill cto-advisorWhat is this skill?
- Full ADR template: status, deciders, context, drivers, options, outcome, pros/cons, links
- Example ADR structure (e.g. microservices) for calibrating tone and depth
- Explicit positive and negative consequence sections with risk/mitigation slots
- Supports Proposed → Accepted → Deprecated → Superseded lifecycle for institutional memory
- Decision-driver checklist (performance, time to market, team expertise, cost)
- ADR template includes Context, Decision Drivers, Considered Options, Decision Outcome, and Pros/Cons sections
- Example ADR-001 microservices architecture block in SKILL.md
Adoption & trust: 754 installs on skills.sh; 17.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You keep reversing stack choices because nobody wrote down why the system was built this way.
Who is it for?
Solo founders acting as their own CTO who need lightweight governance before scope explodes or before raising/helping a first hire.
Skip if: Builders who only need a one-off code snippet with no lasting architectural tradeoffs, or teams that already enforce a formal enterprise architecture review board with a fixed tool.
When should I use this skill?
When you need to document a significant architectural choice with context, alternatives, and consequences before or during implementation.
What do I get? / Deliverables
You produce numbered, status-tracked ADR drafts with drivers, rejected options, and mitigations so later refactors and hires align with recorded intent.
- ADR markdown draft with status and deciders
- Options comparison with positive/negative consequences
- Cross-links to related ADRs or tickets
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build/pm because ADRs most often land while shaping architecture during implementation, even though the same records matter later in Ship and Operate. PM subphase fits decision framing—context, drivers, options, consequences—not day-to-day frontend coding.
Where it fits
Record why you are deferring multi-tenant isolation until post-PMF with explicit drivers and rejected options.
Draft ADR-003 for your primary database and auth approach before the agent implements migrations.
Attach an Accepted ADR to a pre-launch review so security and performance tradeoffs are explicit.
Supersede an old hosting ADR after an outage forces a move to managed Kubernetes.
How it compares
Use structured ADR markdown instead of ad-hoc architecture debates in chat with no durable record.
Common Questions / FAQ
Who is cto-advisor for?
Indie developers and small teams who make architecture calls themselves and want institutional memory without heavyweight enterprise tooling.
When should I use cto-advisor?
In Validate when scoping proves a technical fork; in Build when choosing services, data, or deployment shape; in Ship when documenting launch-critical constraints; in Operate when superseding an old decision after an incident or scale change.
Is cto-advisor safe to install?
It is documentation and template guidance—review the Security Audits panel on this Prism page and avoid pasting secrets into ADR bodies you commit to git.
SKILL.md
READMESKILL.md - Cto Advisor
# Architecture Decision Records (ADR) Framework ## What is an ADR? Architecture Decision Records capture important architectural decisions made along with their context and consequences. They help maintain institutional knowledge and explain why systems are built the way they are. ## ADR Template ### ADR-[NUMBER]: [TITLE] **Date**: YYYY-MM-DD **Status**: [Proposed | Accepted | Deprecated | Superseded] **Deciders**: [List of people involved in decision] **Technical Story**: [Ticket/Issue reference] #### Context and Problem Statement [Describe the context and problem that needs to be solved. What are we trying to achieve?] #### Decision Drivers - [Driver 1: e.g., Performance requirements] - [Driver 2: e.g., Time to market] - [Driver 3: e.g., Team expertise] - [Driver 4: e.g., Cost constraints] #### Considered Options 1. **Option 1: [Name]** 2. **Option 2: [Name]** 3. **Option 3: [Name]** #### Decision Outcome **Chosen option**: "[Option Name]", because [justification] ##### Positive Consequences - [Consequence 1] - [Consequence 2] ##### Negative Consequences - [Risk 1 and mitigation] - [Risk 2 and mitigation] #### Pros and Cons of Options ##### Option 1: [Name] - **Pros**: - [Advantage 1] - [Advantage 2] - **Cons**: - [Disadvantage 1] - [Disadvantage 2] ##### Option 2: [Name] [Repeat structure] #### Links - [Related ADRs] - [Documentation] - [Research/PoCs] --- ## Example ADRs ### ADR-001: Microservices Architecture **Date**: 2024-01-15 **Status**: Accepted **Deciders**: CTO, VP Engineering, Tech Leads **Technical Story**: ARCH-001 #### Context and Problem Statement Our monolithic application is becoming difficult to scale and deploy. Different teams are stepping on each other's toes, and deployment cycles are getting longer. We need to decide on our architectural approach for the next 3-5 years. #### Decision Drivers - Need for independent team deployment - Requirement to scale different components independently - Different components have different performance characteristics - Team size growing from 25 to 75+ engineers - Need to support multiple technology stacks #### Considered Options 1. **Keep Monolith**: Continue with current architecture 2. **Modular Monolith**: Break into modules but single deployment 3. **Microservices**: Full service-oriented architecture 4. **Serverless**: Function-as-a-Service approach #### Decision Outcome **Chosen option**: "Microservices", because it best supports our team autonomy needs and scaling requirements, despite added complexity. ##### Positive Consequences - Teams can deploy independently - Services can scale based on individual needs - Technology diversity is possible - Fault isolation improved ##### Negative Consequences - Increased operational complexity - Mitigated by investing in DevOps - Network latency between services - Mitigated by careful service boundaries - Data consistency challenges - Mitigated by event sourcing patterns --- ### ADR-002: Container Orchestration Platform **Date**: 2024-02-01 **Status**: Accepted **Deciders**: CTO, DevOps Lead, Platform Team **Technical Story**: INFRA-045 #### Context and Problem Statement With the move to microservices (ADR-001), we need a container orchestration platform to manage deployment, scaling, and operations of application containers. #### Decision Drivers - Need for automated deployment and scaling - High availability requirements (99.9% SLA) - Multi-cloud strategy (avoid vendor lock-in) - Team familiarity and ecosystem maturity - Cost considerations #### Considered Options 1. **Kubernetes**: Industry standard, self-managed 2. **Amazon ECS**: AWS-native solution 3. **Docker Swarm**: Simpler alternative 4. **Nomad**: HashiCorp solution #### Decision Outcome **Chosen option**: "Kubernetes", because of its maturity, ecosystem, and multi-cloud support. ##### Positive Consequences - Industry standard with huge ecosystem - Multi-cloud compatible - Strong community su