メニュー
Manage — Technical leadership guidance for engineering teams, architecture decisions, and technology strategy. Use when assessing technical debt, scaling engineering teams, evaluating techn
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/thiagofernandes1987-create/APEX --skill cto-advisorコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Token-aware reasoning workflow with real tools: picks an operating mode to control cost, runs a structured pipeline (decompose → validate → verify → snapshot), and gives Claude Program-of-Thought, RK4/Euler, a code gate, and a safe skill router. Use when: multi-step or high-stakes tasks, real math, precise computation, audits, or the user mentions APEX, PoT, pipeline, or scientific mode.
**v00.33.0**: Ingested from antigravity-awesome-skills community repo
run multiple local CLI agents in parallel (separate tmux sessions)
SOC 職業分類に基づく
SKILL.md を表示中
| name | cto-advisor |
| description | Manage — Technical leadership guidance for engineering teams, architecture decisions, and technology strategy. Use when assessing technical debt, scaling engineering teams, evaluating techn |
| license | MIT |
| metadata | {"version":"2.0.0","author":"Alireza Rezvani","category":"c-level","domain":"cto-leadership","updated":"2026-03-05T00:00:00.000Z","python-tools":"tech_debt_analyzer.py, team_scaling_calculator.py","frameworks":"architecture-decisions, engineering-metrics, technology-evaluation"} |
| executor | HYBRID |
| skill_id | business.c-level-advisor.cto-advisor |
| status | ADOPTED |
| security | {"level":"standard","pii":false,"approval_required":false} |
| anchors | ["business","sales","management","observability","design"] |
| tier | 2 |
| input_schema | [{"name":"code_or_task","type":"string","description":"Code snippet, script, or task description to process","required":true}] |
| output_schema | [{"name":"plan","type":"string","description":"Strategic plan or design document"},{"name":"next_steps","type":"array","description":"List of recommended next steps"}] |
Technical leadership frameworks for architecture, engineering teams, technology strategy, and technical decision-making.
CTO, chief technology officer, tech debt, technical debt, architecture, engineering metrics, DORA, team scaling, technology evaluation, build vs buy, cloud migration, platform engineering, AI/ML strategy, system design, incident response, engineering culture
python scripts/tech_debt_analyzer.py # Assess technical debt severity and remediation plan
python scripts/team_scaling_calculator.py # Model engineering team growth and cost
Align technology investments with business priorities.
Strategy components:
See references/technology_evaluation_framework.md for the full evaluation framework.
Scale the engineering org's productivity — not individual output.
Scaling engineering:
Culture:
See references/engineering_metrics.md for DORA metrics and the engineering health dashboard.
Create the framework for making good decisions — not making every decision yourself.
Architecture Decision Records (ADRs):
See references/architecture_decision_records.md for ADR templates and the decision review process.
Every vendor is a dependency. Every dependency is a risk.
Evaluation criteria: Does it solve a real problem? Can we migrate away? Is the vendor stable? What's the total cost (license + integration + maintenance)?
Incident response, security breaches, major outages, data loss.
Your role in a crisis: Ensure the right people are on it, communication is flowing, and the business is informed. Post-crisis: blameless retrospective within 48 hours.
Step 1 — Run the analyzer
python scripts/tech_debt_analyzer.py --output report.json
Step 2 — Interpret results The analyzer produces a severity-scored inventory. Review each item against:
Step 3 — Build a prioritized remediation plan
Sort by: (Severity × Blast Radius) / Cost-to-fix — highest score = fix first.
Group items into: (a) immediate sprint, (b) next quarter, (c) tracked backlog.
Step 4 — Validate before presenting to stakeholders
Example output — Tech Debt Inventory:
Item | Severity | Cost-to-Fix | Blast Radius | Priority Score
----------------------|----------|-------------|--------------|---------------
Auth service (v1 API) | P1 | 8 days | 6 services | HIGH
Unindexed DB queries | P2 | 3 days | 2 services | MEDIUM
Legacy deploy scripts | P3 | 5 days | 1 service | LOW
Step 1 — Identify the decision Trigger an ADR when: the decision affects more than one team, is hard to reverse, or has cost/risk implications > 1 sprint of effort.
Step 2 — Draft the ADR
Use the template from references/architecture_decision_records.md:
Title: [Short noun phrase]
Status: Proposed | Accepted | Superseded
Context: What is the problem? What constraints exist?
Options Considered:
- Option A: [description] — TCO: $X | Risk: Low/Med/High
- Option B: [description] — TCO: $X | Risk: Low/Med/High
Decision: [Chosen option and rationale]
Consequences: [What becomes easier? What becomes harder?]
Step 3 — Validation checkpoint (before finalizing)
Step 4 — Communicate and close Share the accepted ADR in the engineering all-hands or architecture sync. Link it from the relevant service's README.
Step 1 — Define requirements (functional + non-functional) Step 2 — Identify candidate vendors or internal build scope Step 3 — Score each option:
Criterion | Weight | Build Score | Vendor A Score | Vendor B Score
-----------------------|--------|-------------|----------------|---------------
Solves core problem | 30% | 9 | 8 | 7
Migration risk | 20% | 2 (low risk)| 7 | 6
3-year TCO | 25% | $X | $Y | $Z
Vendor stability | 15% | N/A | 8 | 5
Integration effort | 10% | 3 | 7 | 8
Step 4 — Default rule: Buy unless it is core IP or no vendor meets ≥ 70% of requirements. Step 5 — Document the decision as an ADR (see ADR workflow above).
| Category | Metric | Target | Frequency |
|---|---|---|---|
| Velocity | Deployment frequency | Daily (or per-commit) | Weekly |
| Velocity | Lead time for changes | < 1 day | Weekly |
| Quality | Change failure rate | < 5% | Weekly |
| Quality | Mean time to recovery (MTTR) | < 1 hour | Weekly |
| Debt | Tech debt ratio (maintenance/total) | < 25% | Monthly |
| Debt | P0 bugs open | 0 | Daily |
| Team | Engineering satisfaction | > 7/10 | Quarterly |
| Team | Regrettable attrition | < 10% | Monthly |
| Architecture | System uptime | > 99.9% | Monthly |
| Architecture | API response time (p95) | < 200ms | Weekly |
| Cost | Cloud spend / revenue ratio | Declining trend | Monthly |
| When... | CTO works with... | To... |
|---|---|---|
| Roadmap planning | CPO | Align technical and product roadmaps |
| Hiring engineers | CHRO | Define roles, comp bands, hiring criteria |
| Budget planning | CFO | Cloud costs, tooling, headcount budget |
| Security posture | CISO | Architecture review, compliance requirements |
| Scaling operations | COO | Infrastructure capacity vs growth plans |
| Revenue commitments | CRO | Technical feasibility of enterprise deals |
| Technical marketing | CMO | Developer relations, technical content |
| Strategic decisions | CEO | Technology as competitive advantage |
| Hard calls | Executive Mentor | "Should we rewrite?" "Should we switch stacks?" |
Surface these without being asked when you detect them in company context:
| Request | You Produce |
|---|---|
| "Assess our tech debt" | Tech debt inventory with severity, cost-to-fix, and prioritized plan |
| "Should we build or buy X?" | Build vs buy analysis with 3-year TCO |
| "We need to scale the team" | Hiring plan with roles, timing, ramp model, and budget |
| "Review this architecture" | ADR with options evaluated, decision, consequences |
| "How's engineering doing?" | Engineering health dashboard (DORA + debt + team) |
Research the technical landscape first. Analyze options against constraints (time, team skill, cost, risk). Then recommend action. Always ground recommendations in evidence — benchmarks, case studies, or measured data from your own systems. "I think" is not enough — show the data.
All output passes the Internal Quality Loop before reaching the founder (see agent-protocol/SKILL.md).
company-context.md before responding (if it exists)[INVOKE:role|question]references/technology_evaluation_framework.md — Build vs buy, vendor evaluation, technology radarreferences/engineering_metrics.md — DORA metrics, engineering health dashboard, team productivityreferences/architecture_decision_records.md — ADR templates, decision governance, review processManage — Technical leadership guidance for engineering teams, architecture decisions, and technology strategy.
Use this skill when assessing technical debt, scaling engineering teams, evaluating techn
If this skill fails to produce the expected output: (1) verify input completeness, (2) retry with more specific context, (3) fall back to the parent workflow without this skill.