skills/cto-plan-reviewer/SKILL.md
Technical architecture review agent for execution plans. Uses cto-advisor skill to evaluate technical decisions, architecture patterns, tech debt implications, and technology choices in plan.md. Triggered by: 'review technical plan', 'cto review', 'architecture review', or automatically during Step 2 (Evaluate Plan) for tracks involving architecture decisions, integrations, or infrastructure changes.
npx skillsauth add Ibrahim-3d/orchestrator-supaconductor cto-plan-reviewerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This agent provides CTO-level technical review of execution plans before implementation begins. It catches architectural issues, tech debt accumulation, and suboptimal technology choices during the planning phase.
Automatically invoked during Step 2: EVALUATE PLAN when the track involves:
Also manually invocable via:
claude /cto-advisor
plan.md -- execution plan to reviewspec.md -- requirements and contextconductor/tech-stack.md -- current technology decisionsconductor/product.md -- product requirements and constraintsThe agent leverages the cto-advisor skill to perform deep technical analysis across multiple dimensions:
| Check | Uses CTO Advisor For | |-------|---------------------| | Architecture patterns | Evaluate proposed patterns against team topologies, scalability needs | | Design decisions | ADR template guidance, decision documentation quality | | System design | Component boundaries, separation of concerns, modularity | | Technology standards | Alignment with existing stack, consistency |
CTO Advisor Frameworks Used:
| Check | Uses CTO Advisor For | |-------|---------------------| | Debt introduction | Will this plan create technical debt? Quantify and justify | | Debt mitigation | If debt is introduced, is there a paydown plan? | | Complexity analysis | Is the approach over-engineered or under-engineered? | | Maintenance burden | Long-term ownership and maintenance implications |
CTO Advisor Tools Used:
| Check | Uses CTO Advisor For | |-------|---------------------| | Technology choices | Are new libraries/services necessary and well-justified? | | Vendor dependencies | Lock-in risk, SLA monitoring, cost implications | | Integration complexity | API design, error handling, retry logic | | Cost implications | Infrastructure costs, API usage costs, scaling costs |
CTO Advisor Frameworks Used:
| Check | Uses CTO Advisor For | |-------|---------------------| | Testing strategy | Coverage targets, test types, TDD applicability | | Performance criteria | Load requirements, optimization strategy | | Security review | OWASP top 10, input validation, auth patterns | | Observability | Monitoring, logging, alerting, debugging |
CTO Advisor Metrics Used:
| Check | Uses CTO Advisor For | |-------|---------------------| | Complexity appropriateness | Can the team execute this plan effectively? | | Knowledge distribution | Single points of failure in knowledge? | | Onboarding impact | Will this make onboarding harder? | | Documentation needs | What documentation is required for maintainability? |
CTO Advisor Principles Used:
Use context-loader skill to efficiently load:
plan.md and spec.mdconductor/tech-stack.md -- current stack decisionsconductor/product.md -- product constraintsFor each technical aspect of the plan, invoke relevant cto-advisor frameworks:
For architecture decisions:
- Apply ADR template guidance
- Check system design review criteria
- Validate against technology standards
For tech debt concerns:
- Run tech debt analyzer concepts
- Apply debt strategy allocation principles
- Check red flags
For new technologies:
- Apply technology evaluation framework
- Assess vendor management needs
- Calculate cost implications
For quality:
- Check against DORA metrics targets
- Verify testing strategy
- Validate security checklist
## CTO Technical Review Report
**Track**: [track-id]
**Reviewer**: cto-plan-reviewer (using cto-advisor frameworks)
**Date**: [YYYY-MM-DD]
### Architecture Assessment
#### Design Decisions
- [x] Architecture pattern: [pattern name] -- appropriate for [reason]
- [ ] CONCERN: [specific issue with decision]
- Recommendation: [specific guidance from ADR framework]
#### System Design
- [x] Component boundaries clear and well-defined
- [x] Separation of concerns maintained
- [ ] CONCERN: Tight coupling between [module A] and [module B]
- Recommendation: [refactoring suggestion]
### Tech Debt Analysis
#### Debt Introduction: [NONE / LOW / MEDIUM / HIGH]
- Debt items introduced:
1. [Description] -- Severity: [Critical/High/Medium/Low] -- Justification: [why necessary]
2. [Description] -- Severity: [level] -- Justification: [reason]
#### Mitigation Plan
- [ ] Debt paydown plan required: [yes/no]
- [ ] Capacity allocated: [percentage] -- Aligns with cto-advisor 40/25/15 strategy: [yes/no]
### Technology Evaluation
#### New Dependencies
| Library/Service | Necessity | Alternatives Considered | Lock-in Risk | Cost Impact |
|----------------|-----------|------------------------|--------------|-------------|
| [name] | [justified] | [yes/no - list] | [low/med/high] | [amount/impact] |
#### Integration Assessment
- API design: [quality assessment]
- Error handling: [adequate/needs improvement]
- Retry logic: [present/missing]
- Cost monitoring: [planned/missing]
### Engineering Excellence
#### Testing Strategy: [STRONG / ADEQUATE / WEAK]
- Coverage targets: [percentage] -- Meets cto-advisor 80% threshold: [yes/no]
- TDD applicability: [high/medium/low] -- Justification: [reason]
- Test types planned: [unit/integration/e2e]
#### Performance Criteria: [DEFINED / VAGUE / MISSING]
- Load requirements: [specified/missing]
- Optimization strategy: [present/absent]
#### Security Review: [PASS / NEEDS ATTENTION]
- OWASP top 10 considered: [yes/no]
- Input validation: [planned/missing]
- Auth patterns: [appropriate/needs review]
#### Observability: [COMPREHENSIVE / BASIC / MISSING]
- Monitoring: [planned/missing]
- Logging: [planned/missing]
- Alerting: [planned/missing]
### Team & Process
#### Execution Feasibility: [HIGH / MEDIUM / LOW]
- Team capability match: [assessment]
- Knowledge distribution: [good/concerning]
- Onboarding impact: [low/medium/high]
#### Documentation Plan: [ADEQUATE / NEEDS EXPANSION]
- Technical docs needed: [list]
- ADR required: [yes/no]
- Onboarding docs: [needed/not needed]
### Red Flags
[List any critical concerns from cto-advisor red flags checklist]:
- Increasing technical debt without paydown plan
- Vendor lock-in without escape hatch
- Security vulnerabilities introduced
- Performance bottlenecks designed in
- Tight coupling reducing maintainability
### DORA Metrics Impact Assessment
| Metric | Current Target | Impact of Plan | Assessment |
|--------|---------------|----------------|------------|
| Deployment Frequency | >1/day | [positive/neutral/negative] | [explanation] |
| Lead Time | <1 day | [positive/neutral/negative] | [explanation] |
| MTTR | <1 hour | [positive/neutral/negative] | [explanation] |
| Change Failure Rate | <15% | [positive/neutral/negative] | [explanation] |
### Recommendations
#### Must Fix (Blocking Issues)
1. [Critical issue] -- [specific action required]
2. [Critical issue] -- [specific action required]
#### Should Consider (Improvements)
1. [Suggestion] -- [benefit]
2. [Suggestion] -- [benefit]
#### Nice to Have (Enhancements)
1. [Enhancement] -- [optional benefit]
### Verdict
**Technical Review**: [PASS / PASS WITH CONDITIONS / FAIL]
**PASS**: Technical approach is sound, no blocking issues
**PASS WITH CONDITIONS**: Approved, but recommendations must be addressed during execution
**FAIL**: Blocking issues must be resolved before execution begins
**Rationale**: [1-2 sentence summary of verdict reasoning]
plan.md under "## Technical Review"This agent is automatically invoked by conductor-orchestrator during Step 2 (EVALUATE PLAN) when the track's spec.md or plan.md contains technical architecture keywords:
Trigger Keywords:
Invocation:
conductor-orchestrator -> detects technical track -> dispatches cto-plan-reviewer -> receives report -> includes in plan evaluation -> proceeds or blocks
This agent uses:
A successful technical review:
Manual invocation:
# User wants technical review of current plan
claude /cto-advisor
# Agent loads plan.md, applies cto-advisor frameworks, generates technical review report
Automatic invocation:
# User runs conductor implement
/conductor implement
# Conductor detects Step 2 (Evaluate Plan) + technical track -> automatically calls cto-plan-reviewer
# Report generated -> included in plan evaluation -> execution proceeds or blocks
testing
Use when creating new skills, editing existing skills, or verifying skills work before deployment
development
Use when you have a spec or requirements for a multi-step task, before touching code
data-ai
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
tools
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions