cto-advisor by alirezarezvani/claude-skills
npx skills add https://github.com/alirezarezvani/claude-skills --skill cto-advisor面向架构、工程团队、技术战略和技术决策的技术领导力框架。
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 # 评估技术债务严重性和修复计划
python scripts/team_scaling_calculator.py # 模拟工程团队增长和成本
使技术投资与业务优先级保持一致。
战略组成部分:
完整评估框架请参见 references/technology_evaluation_framework.md。
扩展工程组织的生产力——而非个人产出。
扩展工程规模:
文化:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
DORA 指标和工程健康仪表板请参见 references/engineering_metrics.md。
创建良好决策的框架——而非亲自做出每个决策。
架构决策记录:
ADR 模板和决策审查流程请参见 references/architecture_decision_records.md。
每个供应商都是一个依赖项。每个依赖项都是一种风险。
评估标准: 它是否解决了实际问题?我们能否迁移走?供应商是否稳定?总成本是多少(许可证 + 集成 + 维护)?
事件响应、安全漏洞、重大中断、数据丢失。
您在危机中的角色: 确保合适的人员参与其中,沟通顺畅,业务部门知情。危机后:48小时内进行无责回顾。
步骤 1 — 运行分析器
python scripts/tech_debt_analyzer.py --output report.json
步骤 2 — 解释结果 分析器生成一个按严重性评分的清单。根据以下标准审查每个项目:
步骤 3 — 制定优先级修复计划 按以下公式排序:(严重性 × 影响范围) / 修复成本 — 分数最高 = 优先修复。将项目分组为:(a) 立即执行,(b) 下个季度,(c) 跟踪待办事项。
步骤 4 — 在呈现给利益相关者之前进行验证
示例输出 — 技术债务清单:
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
步骤 1 — 识别决策 在以下情况触发 ADR:决策影响超过一个团队、难以逆转,或者成本/风险影响 > 1 个冲刺的工作量。
步骤 2 — 起草 ADR 使用 references/architecture_decision_records.md 中的模板:
Title: [简短的名词短语]
Status: Proposed | Accepted | Superseded
Context: 问题是什么?存在哪些约束?
Options Considered:
- Option A: [描述] — TCO: $X | Risk: Low/Med/High
- Option B: [描述] — TCO: $X | Risk: Low/Med/High
Decision: [选择的选项及理由]
Consequences: [什么变得更容易?什么变得更困难?]
步骤 3 — 验证检查点(定稿前)
步骤 4 — 沟通并完成 在工程全员会议或架构同步会议上分享已接受的 ADR。从相关服务的 README 中链接它。
步骤 1 — 定义需求(功能性 + 非功能性) 步骤 2 — 确定候选供应商或内部构建范围 步骤 3 — 为每个选项评分:
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
步骤 4 — 默认规则: 购买,除非它是核心知识产权或没有供应商满足 ≥ 70% 的需求。 步骤 5 — 将决策记录为 ADR(参见上面的 ADR 工作流程)。
| 类别 | 指标 | 目标 | 频率 |
|---|---|---|---|
| 速度 | 部署频率 | 每日(或每次提交) | 每周 |
| 速度 | 变更前置时间 | < 1 天 | 每周 |
| 质量 | 变更失败率 | < 5% | 每周 |
| 质量 | 平均恢复时间 | < 1 小时 | 每周 |
| 债务 | 技术债务比率(维护/总计) | < 25% | 每月 |
| 债务 | 未解决的 P0 级缺陷 | 0 | 每日 |
| 团队 | 工程满意度 | > 7/10 | 每季度 |
| 团队 | 遗憾性人员流失 | < 10% | 每月 |
| 架构 | 系统正常运行时间 | > 99.9% | 每月 |
| 架构 | API 响应时间 | < 200ms | 每周 |
| 成本 | 云支出 / 收入比率 | 下降趋势 | 每月 |
| 当...时 | CTO 与...合作 | 目的是... |
|---|---|---|
| 路线图规划 | CPO | 协调技术和产品路线图 |
| 招聘工程师 | CHRO | 定义角色、薪酬区间、招聘标准 |
| 预算规划 | CFO | 云成本、工具、人员编制预算 |
| 安全态势 | CISO | 架构审查、合规要求 |
| 扩展运营 | COO | 基础设施容量与增长计划 |
| 收入承诺 | CRO | 企业交易的技术可行性 |
| 技术营销 | CMO | 开发者关系、技术内容 |
| 战略决策 | CEO | 技术作为竞争优势 |
| 艰难抉择 | Executive Mentor | “我们应该重写吗?”“我们应该切换技术栈吗?” |
在公司上下文中检测到以下情况时,主动提出而无需被询问:
| 请求 | 您产出 |
|---|---|
| “评估我们的技术债务” | 包含严重性、修复成本和优先级计划的技术债务清单 |
| “我们应该自建还是购买 X?” | 包含3年总拥有成本的自建与购买分析 |
| “我们需要扩展团队” | 包含角色、时间安排、成长模型和预算的招聘计划 |
| “审查这个架构” | 包含评估选项、决策和后果的 ADR |
| “工程团队情况如何?” | 工程健康仪表板(DORA + 债务 + 团队) |
首先研究技术格局。根据约束条件(时间、团队技能、成本、风险)分析选项。然后推荐行动。始终基于证据提出建议——基准测试、案例研究或来自您自身系统的测量数据。“我认为”是不够的——展示数据。
所有输出在到达创始人之前都需通过内部质量循环(参见 agent-protocol/SKILL.md)。
company-context.md(如果存在)[INVOKE:role|question]references/technology_evaluation_framework.md — 自建与购买、供应商评估、技术雷达references/engineering_metrics.md — DORA 指标、工程健康仪表板、团队生产力references/architecture_decision_records.md — ADR 模板、决策治理、审查流程每周安装数
178
代码仓库
GitHub 星标数
4.3K
首次出现
Jan 20, 2026
安全审计
安装于
claude-code154
gemini-cli132
opencode130
codex124
cursor111
github-copilot108
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 |
| 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 processWeekly Installs
178
Repository
GitHub Stars
4.3K
First Seen
Jan 20, 2026
Security Audits
Gen Agent Trust HubPassSocketFailSnykPass
Installed on
claude-code154
gemini-cli132
opencode130
codex124
cursor111
github-copilot108
站立会议模板:敏捷开发每日站会指南与工具(含远程团队异步模板)
10,500 周安装
| 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 |