/cto-advisor

name: cto-advisor
description: "Run CTO-level technical review of the current execution plan - architecture, tech debt, engineering excellence"
model: opus
arguments:
  - name: track_id
    description: "Optional track ID to review (defaults to active track)"
    required: false
user_invocable: true

/orchestrator-supaconductor:cto-advisor

Run CTO-level technical review of the current execution plan. Uses the `cto-advisor` skill to evaluate architecture decisions, tech debt implications, technology choices, and engineering excellence.

When to Use

Run this command to get technical leadership guidance on:

• **Architecture decisions** — evaluating system design patterns, component boundaries
• **Technology selection** — choosing libraries, frameworks, services
• **Technical debt** — assessing debt introduction and mitigation strategies
• **Engineering metrics** — validating against DORA metrics and quality standards
• **Integration planning** — reviewing API design, vendor dependencies
• **Infrastructure changes** — evaluating scalability, performance, monitoring
• **Security review** — checking authentication, authorization, OWASP compliance

Usage

# Review current track's plan
/orchestrator-supaconductor:cto-advisor

# Or manually specify track
/orchestrator-supaconductor:cto-advisor TRACK-001-core-feature

What It Does

The command invokes the `cto-plan-reviewer` skill, which:

1. **Loads Context**

• Reads track's `plan.md` and `spec.md`
• Loads `conductor/tech-stack.md` for current technology decisions
• Loads `conductor/product.md` for product constraints
• Scans codebase for existing architecture patterns

2. **Applies CTO Advisor Frameworks**

• **Architecture Review** — ADR templates, system design criteria, technology standards
• **Tech Debt Assessment** — Debt analyzer, 40/25/15 allocation strategy, red flags
• **Technology Evaluation** — 4-week evaluation framework, vendor management, cost analysis
• **Engineering Excellence** — DORA metrics (deployment frequency, lead time, MTTR, CFR), quality metrics (test coverage >80%)
• **Team & Process** — Execution feasibility, knowledge distribution, documentation needs

3. **Generates Technical Review Report**

• Architecture assessment with specific recommendations
• Tech debt analysis with severity and mitigation plan
• Technology evaluation with alternatives and lock-in risk
• Engineering excellence checklist (testing, performance, security, observability)
• Team & process fit analysis
• Red flags from CTO advisor checklist
• DORA metrics impact assessment
• Actionable recommendations (must-fix, should-consider, nice-to-have)
• Final verdict: PASS / PASS WITH CONDITIONS / FAIL

Output Format

## CTO Technical Review Report

**Track**: TRACK-001-core-feature
**Reviewer**: cto-plan-reviewer (using cto-advisor frameworks)
**Date**: YYYY-MM-DD

### Architecture Assessment

#### Design Decisions
- [x] Architecture pattern: Zustand store with React hooks — appropriate for client-side state
- [ ] CONCERN: No error boundary strategy for API failures
- Recommendation: Add React Error Boundaries around critical components

#### System Design
- [x] Component boundaries clear and well-defined
- [x] Separation of concerns maintained (state/UI/API separated)
- [ ] CONCERN: Tight coupling between generation and state management
- Recommendation: Extract state to separate store slice for independent evolution

### Tech Debt Analysis

#### Debt Introduction: LOW
- Debt items introduced:
  1. Mock client for development — Severity: Low — Justification: Needed for parallel frontend work
  2. Hardcoded templates — Severity: Medium — Justification: Will be moved to database in Phase 2

#### Mitigation Plan
- [x] Debt paydown plan documented in plan.md Phase 2
- [x] Capacity allocated: 15% in maintenance sprints — Aligns with cto-advisor 40/25/15 strategy

### Technology Evaluation

#### New Dependencies
| Library/Service | Necessity | Alternatives Considered | Lock-in Risk | Cost Impact |
|----------------|-----------|------------------------|--------------|-------------|
| API Service | High | Alternative A, Alternative B | Medium | $X/request |
| Utility Lib | High | alt-lib-1, alt-lib-2 | Low | None (open source) |
| State Manager | Medium | Redux, Jotai, Context API | Low | None (easy to migrate) |

#### Integration Assessment
- API design: Well-structured with proper error types
- Error handling: Good — includes retry logic and user-friendly messages
- Retry logic: Present with exponential backoff
- Cost monitoring: Missing — Add API usage tracking before production

### Engineering Excellence

#### Testing Strategy: ADEQUATE
- Coverage targets: 70% overall, 90% business logic — Meets cto-advisor 80% threshold for critical paths
- TDD applicability: High for core logic
- Test types planned: Unit (core logic), Integration (store), E2E (full flow)
- Recommendation: Add E2E test for complete end-to-end flow

#### Performance Criteria: DEFINED
- Load requirements: Defined per use case
- Optimization strategy: Lazy loading, caching where appropriate

#### Security Review: PASS
- OWASP top 10 considered: Yes
- Input validation: In place
- Auth patterns: Appropriate for current phase

#### Observability: BASIC
- Monitoring: Missing — Add analytics
- Logging: Present — Console logs for key steps
- Alerting: Not applicable for Phase 1
- Recommendation: Add structured logging for production debugging

### Team & Process

#### Execution Feasibility: HIGH
- Team capability match: Good
- Knowledge distribution: Acceptable, documentation present
- Onboarding impact: Low — clear component structure and naming

#### Documentation Plan: ADEQUATE
- Technical docs needed: Key integration guides
- ADR required: No (decisions documented in architecture doc)
- Onboarding docs: Present in project docs

### Red Flags

**X red flag(s) found:**
- [List any red flags with acti