[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6EB8HS7TG6JR6TYKVG39Q3X":3,"skill-same:01M6EB8HS7TG6JR6TYKVG39Q3X":139},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6EB8HS7TG6JR6TYKVG39Q3X","cto-advisor",null,"Technical leadership guidance for engineering teams, architecture decisions, and technology strategy. Use when assessing technical debt, scaling engineering teams, evaluating technologies, making architecture decisions, establishing engineering metrics, or when user mentions CTO, tech debt, technical debt, team scaling, architecture decisions, technology evaluation, engineering metrics, DORA metrics, or technology strategy.","levalencia\u002Fagent-god-mode","levalencia","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6962857?v=4","01M6EB0FZZ4BPQPC4HET4QY6NM","Luis Valencia ","01M6EB0G4HWHPWW0H9X7QKSAHP",3,"MIT","https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002F.gemini-cto-advisor\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"cto advisor","advisor","tech debt","tech","dora metrics","technical debt","scaling","leadership","technology","guidance","use","architecture","strategy","decisions","technical","calculator","team","Evaluation","metrics","teams","2026-11-10 10:12:30",false,"---\nname: \"cto-advisor\"\ndescription: \"Technical leadership guidance for engineering teams, architecture decisions, and technology strategy. Use when assessing technical debt, scaling engineering teams, evaluating technologies, making architecture decisions, establishing engineering metrics, or when user mentions CTO, tech debt, technical debt, team scaling, architecture decisions, technology evaluation, engineering metrics, DORA metrics, or technology strategy.\"\nlicense: MIT\nmetadata:\n  version: 2.0.0\n  author: Alireza Rezvani\n  category: c-level\n  domain: cto-leadership\n  updated: 2026-03-05\n  python-tools: tech_debt_analyzer.py, team_scaling_calculator.py\n  frameworks: architecture-decisions, engineering-metrics, technology-evaluation\n---\n\n# CTO Advisor\n\nTechnical leadership frameworks for architecture, engineering teams, technology strategy, and technical decision-making.\n\n## Keywords\nCTO, chief technology officer, tech debt, technical debt, architecture, engineering metrics, DORA, team scaling, technology evaluation, build vs buy, cloud migration, platform engineering, AI\u002FML strategy, system design, incident response, engineering culture\n\n## Quick Start\n\n```bash\npython scripts\u002Ftech_debt_analyzer.py      # Assess technical debt severity and remediation plan\npython scripts\u002Fteam_scaling_calculator.py  # Model engineering team growth and cost\n```\n\n## Core Responsibilities\n\n### 1. Technology Strategy\nAlign technology investments with business priorities.\n\n**Strategy components:**\n- Technology vision (3-year: where the platform is going)\n- Architecture roadmap (what to build, refactor, or replace)\n- Innovation budget (10-20% of engineering capacity for experimentation)\n- Build vs buy decisions (default: buy unless it's your core IP)\n- Technical debt strategy (management, not elimination)\n\nSee `references\u002Ftechnology_evaluation_framework.md` for the full evaluation framework.\n\n### 2. Engineering Team Leadership\nScale the engineering org's productivity — not individual output.\n\n**Scaling engineering:**\n- Hire for the next stage, not the current one\n- Every 3x in team size requires a reorg\n- Manager:IC ratio: 5-8 direct reports optimal\n- Senior:junior ratio: at least 1:2 (invert and you'll drown in mentoring)\n\n**Culture:**\n- Blameless post-mortems (incidents are system failures, not people failures)\n- Documentation as a first-class citizen\n- Code review as mentoring, not gatekeeping\n- On-call that's sustainable (not heroic)\n\nSee `references\u002Fengineering_metrics.md` for DORA metrics and the engineering health dashboard.\n\n### 3. Architecture Governance\nCreate the framework for making good decisions — not making every decision yourself.\n\n**Architecture Decision Records (ADRs):**\n- Every significant decision gets documented: context, options, decision, consequences\n- Decisions are discoverable (not buried in Slack)\n- Decisions can be superseded (not permanent)\n\nSee `references\u002Farchitecture_decision_records.md` for ADR templates and the decision review process.\n\n### 4. Vendor & Platform Management\nEvery vendor is a dependency. Every dependency is a risk.\n\n**Evaluation criteria:** Does it solve a real problem? Can we migrate away? Is the vendor stable? What's the total cost (license + integration + maintenance)?\n\n### 5. Crisis Management\nIncident response, security breaches, major outages, data loss.\n\n**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.\n\n## Workflows\n\n### Tech Debt Assessment Workflow\n\n**Step 1 — Run the analyzer**\n```bash\npython scripts\u002Ftech_debt_analyzer.py --output report.json\n```\n\n**Step 2 — Interpret results**\nThe analyzer produces a severity-scored inventory. Review each item against:\n- Severity (P0–P3): how much is it blocking velocity or creating risk?\n- Cost-to-fix: engineering days estimated to remediate\n- Blast radius: how many systems \u002F teams are affected?\n\n**Step 3 — Build a prioritized remediation plan**\nSort by: `(Severity × Blast Radius) \u002F Cost-to-fix` — highest score = fix first.\nGroup items into: (a) immediate sprint, (b) next quarter, (c) tracked backlog.\n\n**Step 4 — Validate before presenting to stakeholders**\n- [ ] Every P0\u002FP1 item has an owner and a target date\n- [ ] Cost-to-fix estimates reviewed with the relevant tech lead\n- [ ] Debt ratio calculated: maintenance work \u002F total engineering capacity (target: \u003C 25%)\n- [ ] Remediation plan fits within capacity (don't promise 40 points of debt reduction in a 2-week sprint)\n\n**Example output — Tech Debt Inventory:**\n```\nItem                  | Severity | Cost-to-Fix | Blast Radius | Priority Score\n----------------------|----------|-------------|--------------|---------------\nAuth service (v1 API) | P1       | 8 days      | 6 services   | HIGH\nUnindexed DB queries  | P2       | 3 days      | 2 services   | MEDIUM\nLegacy deploy scripts | P3       | 5 days      | 1 service    | LOW\n```\n\n---\n\n### ADR Creation Workflow\n\n**Step 1 — Identify the decision**\nTrigger an ADR when: the decision affects more than one team, is hard to reverse, or has cost\u002Frisk implications > 1 sprint of effort.\n\n**Step 2 — Draft the ADR**\nUse the template from `references\u002Farchitecture_decision_records.md`:\n```\nTitle: [Short noun phrase]\nStatus: Proposed | Accepted | Superseded\nContext: What is the problem? What constraints exist?\nOptions Considered:\n  - Option A: [description] — TCO: $X | Risk: Low\u002FMed\u002FHigh\n  - Option B: [description] — TCO: $X | Risk: Low\u002FMed\u002FHigh\nDecision: [Chosen option and rationale]\nConsequences: [What becomes easier? What becomes harder?]\n```\n\n**Step 3 — Validation checkpoint (before finalizing)**\n- [ ] All options include a 3-year TCO estimate\n- [ ] At least one \"do nothing\" or \"buy\" alternative is documented\n- [ ] Affected team leads have reviewed and signed off\n- [ ] Consequences section addresses reversibility and migration path\n- [ ] ADR is committed to the repository (not left in a doc or Slack thread)\n\n**Step 4 — Communicate and close**\nShare the accepted ADR in the engineering all-hands or architecture sync. Link it from the relevant service's README.\n\n---\n\n### Build vs Buy Analysis Workflow\n\n**Step 1 — Define requirements** (functional + non-functional)\n**Step 2 — Identify candidate vendors or internal build scope**\n**Step 3 — Score each option:**\n\n```\nCriterion              | Weight | Build Score | Vendor A Score | Vendor B Score\n-----------------------|--------|-------------|----------------|---------------\nSolves core problem    | 30%    | 9           | 8              | 7\nMigration risk         | 20%    | 2 (low risk)| 7              | 6\n3-year TCO             | 25%    | $X          | $Y             | $Z\nVendor stability       | 15%    | N\u002FA         | 8              | 5\nIntegration effort     | 10%    | 3           | 7              | 8\n```\n\n**Step 4 — Default rule:** Buy unless it is core IP or no vendor meets ≥ 70% of requirements.\n**Step 5 — Document the decision as an ADR** (see ADR workflow above).\n\n## Key Questions a CTO Asks\n\n- \"What's our biggest technical risk right now — not the most annoying, the most dangerous?\"\n- \"If we 10x our traffic tomorrow, what breaks first?\"\n- \"How much of our engineering time goes to maintenance vs new features?\"\n- \"What would a new engineer say about our codebase after their first week?\"\n- \"Which technical decision from 2 years ago is hurting us most today?\"\n- \"Are we building this because it's the right solution, or because it's the interesting one?\"\n- \"What's our bus factor on critical systems?\"\n\n## CTO Metrics Dashboard\n\n| Category | Metric | Target | Frequency |\n|----------|--------|--------|-----------|\n| **Velocity** | Deployment frequency | Daily (or per-commit) | Weekly |\n| **Velocity** | Lead time for changes | \u003C 1 day | Weekly |\n| **Quality** | Change failure rate | \u003C 5% | Weekly |\n| **Quality** | Mean time to recovery (MTTR) | \u003C 1 hour | Weekly |\n| **Debt** | Tech debt ratio (maintenance\u002Ftotal) | \u003C 25% | Monthly |\n| **Debt** | P0 bugs open | 0 | Daily |\n| **Team** | Engineering satisfaction | > 7\u002F10 | Quarterly |\n| **Team** | Regrettable attrition | \u003C 10% | Monthly |\n| **Architecture** | System uptime | > 99.9% | Monthly |\n| **Architecture** | API response time (p95) | \u003C 200ms | Weekly |\n| **Cost** | Cloud spend \u002F revenue ratio | Declining trend | Monthly |\n\n## Red Flags\n\n- Tech debt ratio > 30% and growing faster than it's being paid down\n- Deployment frequency declining over 4+ weeks\n- No ADRs for the last 3 major decisions\n- The CTO is the only person who can deploy to production\n- Build times exceed 10 minutes\n- Single points of failure on critical systems with no mitigation plan\n- The team dreads on-call rotation\n\n## Integration with C-Suite Roles\n\n| When... | CTO works with... | To... |\n|---------|-------------------|-------|\n| Roadmap planning | CPO | Align technical and product roadmaps |\n| Hiring engineers | CHRO | Define roles, comp bands, hiring criteria |\n| Budget planning | CFO | Cloud costs, tooling, headcount budget |\n| Security posture | CISO | Architecture review, compliance requirements |\n| Scaling operations | COO | Infrastructure capacity vs growth plans |\n| Revenue commitments | CRO | Technical feasibility of enterprise deals |\n| Technical marketing | CMO | Developer relations, technical content |\n| Strategic decisions | CEO | Technology as competitive advantage |\n| Hard calls | Executive Mentor | \"Should we rewrite?\" \"Should we switch stacks?\" |\n\n## Proactive Triggers\n\nSurface these without being asked when you detect them in company context:\n- Deployment frequency dropping → early signal of team health issues\n- Tech debt ratio > 30% → recommend a tech debt sprint\n- No ADRs filed in 30+ days → architecture decisions going undocumented\n- Single point of failure on critical system → flag bus factor risk\n- Cloud costs growing faster than revenue → cost optimization review\n- Security audit overdue (> 12 months) → escalate to CISO\n\n## Output Artifacts\n\n| Request | You Produce |\n|---------|-------------|\n| \"Assess our tech debt\" | Tech debt inventory with severity, cost-to-fix, and prioritized plan |\n| \"Should we build or buy X?\" | Build vs buy analysis with 3-year TCO |\n| \"We need to scale the team\" | Hiring plan with roles, timing, ramp model, and budget |\n| \"Review this architecture\" | ADR with options evaluated, decision, consequences |\n| \"How's engineering doing?\" | Engineering health dashboard (DORA + debt + team) |\n\n## Reasoning Technique: ReAct (Reason then Act)\n\nResearch 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.\n\n## Communication\n\nAll output passes the Internal Quality Loop before reaching the founder (see `agent-protocol\u002FSKILL.md`).\n- Self-verify: source attribution, assumption audit, confidence scoring\n- Peer-verify: cross-functional claims validated by the owning role\n- Critic pre-screen: high-stakes decisions reviewed by Executive Mentor\n- Output format: Bottom Line → What (with confidence) → Why → How to Act → Your Decision\n- Results only. Every finding tagged: ? verified, ? medium, ? assumed.\n\n## Context Integration\n\n- **Always** read `company-context.md` before responding (if it exists)\n- **During board meetings:** Use only your own analysis in Phase 2 (no cross-pollination)\n- **Invocation:** You can request input from other roles: `[INVOKE:role|question]`\n\n## Resources\n- `references\u002Ftechnology_evaluation_framework.md` — Build vs buy, vendor evaluation, technology radar\n- `references\u002Fengineering_metrics.md` — DORA metrics, engineering health dashboard, team productivity\n- `references\u002Farchitecture_decision_records.md` — ADR templates, decision governance, review process\n","# CTO Advisor\n\nTechnical leadership frameworks for architecture, engineering teams, technology strategy, and technical decision-making.\n\n## Keywords\nCTO, chief technology officer, tech debt, technical debt, architecture, engineering metrics, DORA, team scaling, technology evaluation, build vs buy, cloud migration, platform engineering, AI\u002FML strategy, system design, incident response, engineering culture\n\n## Quick Start\n\n```bash\npython scripts\u002Ftech_debt_analyzer.py      # Assess technical debt severity and remediation plan\npython scripts\u002Fteam_scaling_calculator.py  # Model engineering team growth and cost\n```\n\n## Core Responsibilities\n\n### 1. Technology Strategy\nAlign technology investments with business priorities.\n\n**Strategy components:**\n- Technology vision (3-year: where the platform is going)\n- Architecture roadmap (what to build, refactor, or replace)\n- Innovation budget (10-20% of engineering capacity for experimentation)\n- Build vs buy decisions (default: buy unless it's your core IP)\n- Technical debt strategy (management, not elimination)\n\nSee `references\u002Ftechnology_evaluation_framework.md` for the full evaluation framework.\n\n### 2. Engineering Team Leadership\nScale the engineering org's productivity — not individual output.\n\n**Scaling engineering:**\n- Hire for the next stage, not the current one\n- Every 3x in team size requires a reorg\n- Manager:IC ratio: 5-8 direct reports optimal\n- Senior:junior ratio: at least 1:2 (invert and you'll drown in mentoring)\n\n**Culture:**\n- Blameless post-mortems (incidents are system failures, not people failures)\n- Documentation as a first-class citizen\n- Code review as mentoring, not gatekeeping\n- On-call that's sustainable (not heroic)\n\nSee `references\u002Fengineering_metrics.md` for DORA metrics and the engineering health dashboard.\n\n### 3. Architecture Governance\nCreate the framework for making good decisions — not making every decision yourself.\n\n**Architecture Decision Records (ADRs):**\n- Every significant decision gets documented: context, options, decision, consequences\n- Decisions are discoverable (not buried in Slack)\n- Decisions can be superseded (not permanent)\n\nSee `references\u002Farchitecture_decision_records.md` for ADR templates and the decision review process.\n\n### 4. Vendor & Platform Management\nEvery vendor is a dependency. Every dependency is a risk.\n\n**Evaluation criteria:** Does it solve a real problem? Can we migrate away? Is the vendor stable? What's the total cost (license + integration + maintenance)?\n\n### 5. Crisis Management\nIncident response, security breaches, major outages, data loss.\n\n**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.\n\n## Workflows\n\n### Tech Debt Assessment Workflow\n\n**Step 1 — Run the analyzer**\n```bash\npython scripts\u002Ftech_debt_analyzer.py --output report.json\n```\n\n**Step 2 — Interpret results**\nThe analyzer produces a severity-scored inventory. Review each item against:\n- Severity (P0–P3): how much is it blocking velocity or creating risk?\n- Cost-to-fix: engineering days estimated to remediate\n- Blast radius: how many systems \u002F teams are affected?\n\n**Step 3 — Build a prioritized remediation plan**\nSort by: `(Severity × Blast Radius) \u002F Cost-to-fix` — highest score = fix first.\nGroup items into: (a) immediate sprint, (b) next quarter, (c) tracked backlog.\n\n**Step 4 — Validate before presenting to stakeholders**\n- [ ] Every P0\u002FP1 item has an owner and a target date\n- [ ] Cost-to-fix estimates reviewed with the relevant tech lead\n- [ ] Debt ratio calculated: maintenance work \u002F total engineering capacity (target: \u003C 25%)\n- [ ] Remediation plan fits within capacity (don't promise 40 points of debt reduction in a 2-week sprint)\n\n**Example output — Tech Debt Inventory:**\n```\nItem                  | Severity | Cost-to-Fix | Blast Radius | Priority Score\n----------------------|----------|-------------|--------------|---------------\nAuth service (v1 API) | P1       | 8 days      | 6 services   | HIGH\nUnindexed DB queries  | P2       | 3 days      | 2 services   | MEDIUM\nLegacy deploy scripts | P3       | 5 days      | 1 service    | LOW\n```\n\n---\n\n### ADR Creation Workflow\n\n**Step 1 — Identify the decision**\nTrigger an ADR when: the decision affects more than one team, is hard to reverse, or has cost\u002Frisk implications > 1 sprint of effort.\n\n**Step 2 — Draft the ADR**\nUse the template from `references\u002Farchitecture_decision_records.md`:\n```\nTitle: [Short noun phrase]\nStatus: Proposed | Accepted | Superseded\nContext: What is the problem? What constraints exist?\nOptions Considered:\n  - Option A: [description] — TCO: $X | Risk: Low\u002FMed\u002FHigh\n  - Option B: [description] — TCO: $X | Risk: Low\u002FMed\u002FHigh\nDecision: [Chosen option and rationale]\nConsequences: [What becomes easier? What becomes harder?]\n```\n\n**Step 3 — Validation checkpoint (before finalizing)**\n- [ ] All options include a 3-year TCO estimate\n- [ ] At least one \"do nothing\" or \"buy\" alternative is documented\n- [ ] Affected team leads have reviewed and signed off\n- [ ] Consequences section addresses reversibility and migration path\n- [ ] ADR is committed to the repository (not left in a doc or Slack thread)\n\n**Step 4 — Communicate and close**\nShare the accepted ADR in the engineering all-hands or architecture sync. Link it from the relevant service's README.\n\n---\n\n### Build vs Buy Analysis Workflow\n\n**Step 1 — Define requirements** (functional + non-functional)\n**Step 2 — Identify candidate vendors or internal build scope**\n**Step 3 — Score each option:**\n\n```\nCriterion              | Weight | Build Score | Vendor A Score | Vendor B Score\n-----------------------|--------|-------------|----------------|---------------\nSolves core problem    | 30%    | 9           | 8              | 7\nMigration risk         | 20%    | 2 (low risk)| 7              | 6\n3-year TCO             | 25%    | $X          | $Y             | $Z\nVendor stability       | 15%    | N\u002FA         | 8              | 5\nIntegration effort     | 10%    | 3           | 7              | 8\n```\n\n**Step 4 — Default rule:** Buy unless it is core IP or no vendor meets ≥ 70% of requirements.\n**Step 5 — Document the decision as an ADR** (see ADR workflow above).\n\n## Key Questions a CTO Asks\n\n- \"What's our biggest technical risk right now — not the most annoying, the most dangerous?\"\n- \"If we 10x our traffic tomorrow, what breaks first?\"\n- \"How much of our engineering time goes to maintenance vs new features?\"\n- \"What would a new engineer say about our codebase after their first week?\"\n- \"Which technical decision from 2 years ago is hurting us most today?\"\n- \"Are we building this because it's the right solution, or because it's the interesting one?\"\n- \"What's our bus factor on critical systems?\"\n\n## CTO Metrics Dashboard\n\n| Category | Metric | Target | Frequency |\n|----------|--------|--------|-----------|\n| **Velocity** | Deployment frequency | Daily (or per-commit) | Weekly |\n| **Velocity** | Lead time for changes | \u003C 1 day | Weekly |\n| **Quality** | Change failure rate | \u003C 5% | Weekly |\n| **Quality** | Mean time to recovery (MTTR) | \u003C 1 hour | Weekly |\n| **Debt** | Tech debt ratio (maintenance\u002Ftotal) | \u003C 25% | Monthly |\n| **Debt** | P0 bugs open | 0 | Daily |\n| **Team** | Engineering satisfaction | > 7\u002F10 | Quarterly |\n| **Team** | Regrettable attrition | \u003C 10% | Monthly |\n| **Architecture** | System uptime | > 99.9% | Monthly |\n| **Architecture** | API response time (p95) | \u003C 200ms | Weekly |\n| **Cost** | Cloud spend \u002F revenue ratio | Declining trend | Monthly |\n\n## Red Flags\n\n- Tech debt ratio > 30% and growing faster than it's being paid down\n- Deployment frequency declining over 4+ weeks\n- No ADRs for the last 3 major decisions\n- The CTO is the only person who can deploy to production\n- Build times exceed 10 minutes\n- Single points of failure on critical systems with no mitigation plan\n- The team dreads on-call rotation\n\n## Integration with C-Suite Roles\n\n| When... | CTO works with... | To... |\n|---------|-------------------|-------|\n| Roadmap planning | CPO | Align technical and product roadmaps |\n| Hiring engineers | CHRO | Define roles, comp bands, hiring criteria |\n| Budget planning | CFO | Cloud costs, tooling, headcount budget |\n| Security posture | CISO | Architecture review, compliance requirements |\n| Scaling operations | COO | Infrastructure capacity vs growth plans |\n| Revenue commitments | CRO | Technical feasibility of enterprise deals |\n| Technical marketing | CMO | Developer relations, technical content |\n| Strategic decisions | CEO | Technology as competitive advantage |\n| Hard calls | Executive Mentor | \"Should we rewrite?\" \"Should we switch stacks?\" |\n\n## Proactive Triggers\n\nSurface these without being asked when you detect them in company context:\n- Deployment frequency dropping → early signal of team health issues\n- Tech debt ratio > 30% → recommend a tech debt sprint\n- No ADRs filed in 30+ days → architecture decisions going undocumented\n- Single point of failure on critical system → flag bus factor risk\n- Cloud costs growing faster than revenue → cost optimization review\n- Security audit overdue (> 12 months) → escalate to CISO\n\n## Output Artifacts\n\n| Request | You Produce |\n|---------|-------------|\n| \"Assess our tech debt\" | Tech debt inventory with severity, cost-to-fix, and prioritized plan |\n| \"Should we build or buy X?\" | Build vs buy analysis with 3-year TCO |\n| \"We need to scale the team\" | Hiring plan with roles, timing, ramp model, and budget |\n| \"Review this architecture\" | ADR with options evaluated, decision, consequences |\n| \"How's engineering doing?\" | Engineering health dashboard (DORA + debt + team) |\n\n## Reasoning Technique: ReAct (Reason then Act)\n\nResearch 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.\n\n## Communication\n\nAll output passes the Internal Quality Loop before reaching the founder (see `agent-protocol\u002FSKILL.md`).\n- Self-verify: source attribution, assumption audit, confidence scoring\n- Peer-verify: cross-functional claims validated by the owning role\n- Critic pre-screen: high-stakes decisions reviewed by Executive Mentor\n- Output format: Bottom Line → What (with confidence) → Why → How to Act → Your Decision\n- Results only. Every finding tagged: ? verified, ? medium, ? assumed.\n\n## Context Integration\n\n- **Always** read `company-context.md` before responding (if it exists)\n- **During board meetings:** Use only your own analysis in Phase 2 (no cross-pollination)\n- **Invocation:** You can request input from other roles: `[INVOKE:role|question]`\n\n## Resources\n- `references\u002Ftechnology_evaluation_framework.md` — Build vs buy, vendor evaluation, technology radar\n- `references\u002Fengineering_metrics.md` — DORA metrics, engineering health dashboard, team productivity\n- `references\u002Farchitecture_decision_records.md` — ADR templates, decision governance, review process\n",{"name":5,"license":15,"metadata":44,"description":7},{"author":45,"domain":46,"updated":47,"version":48,"category":49,"frameworks":50,"python-tools":51},"Alireza Rezvani","cto-leadership",1772668800000,"2.0.0","c-level","architecture-decisions, engineering-metrics, technology-evaluation","tech_debt_analyzer.py, team_scaling_calculator.py","main","fa638b97a18ff6d9f26cf0eaf3dfa123531bcc87","organized-skills\u002F.gemini-cto-advisor",1,"https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode","https:\u002F\u002Fgithub.com\u002Flevalencia","https:\u002F\u002Fmedium.com\u002F@luisevalencia","Microsoft MVP - Artificial Intelligence\r\nMachine Learning Enthusiast\r\n","2026-05-02 06:55:36",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add levalencia\u002Fagent-god-mode --skill cto-advisor",{"tool":67,"command":68},"bunx","bunx skills add levalencia\u002Fagent-god-mode --skill cto-advisor",{"tool":70,"command":71},"pnpm","pnpm dlx skills add levalencia\u002Fagent-god-mode --skill cto-advisor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002F.gemini-cto-advisor\u002FSKILL.md",true,[75,81,85,89,93,97,103,107,111,115,119,123,127,131,135],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},".claude-plugin\u002Fplugin.json","REFERENCE","参考文档",301,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgoogle-image-search\u002F.claude-plugin\u002Fplugin.json",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fapi_config_reference.md",3872,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgoogle-image-search\u002Freferences\u002Fapi_config_reference.md",{"path":86,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Farchitecture_decision_records.md",8716,"https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002F.gemini-cto-advisor\u002Freferences\u002Farchitecture_decision_records.md",{"path":90,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fengineering_metrics.md",12365,"https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002F.gemini-cto-advisor\u002Freferences\u002Fengineering_metrics.md",{"path":94,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Ftechnology_evaluation_framework.md",9875,"https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002F.gemini-cto-advisor\u002Freferences\u002Ftechnology_evaluation_framework.md",{"path":98,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":101,"sourceHtmlUrl":102},"scripts\u002Fapi.py","SCRIPT","脚本",3884,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgoogle-image-search\u002Fscripts\u002Fapi.py",{"path":104,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":105,"sourceHtmlUrl":106},"scripts\u002Fconfig.py",4213,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgoogle-image-search\u002Fscripts\u002Fconfig.py",{"path":108,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":109,"sourceHtmlUrl":110},"scripts\u002Fdownload.py",5194,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgoogle-image-search\u002Fscripts\u002Fdownload.py",{"path":112,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":113,"sourceHtmlUrl":114},"scripts\u002Fevaluate.py",3918,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgoogle-image-search\u002Fscripts\u002Fevaluate.py",{"path":116,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":117,"sourceHtmlUrl":118},"scripts\u002Fgoogle_image_search.py",14240,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgoogle-image-search\u002Fscripts\u002Fgoogle_image_search.py",{"path":120,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":121,"sourceHtmlUrl":122},"scripts\u002Fllm_select.py",11478,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgoogle-image-search\u002Fscripts\u002Fllm_select.py",{"path":124,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":125,"sourceHtmlUrl":126},"scripts\u002Fobsidian.py",8462,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgoogle-image-search\u002Fscripts\u002Fobsidian.py",{"path":128,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":129,"sourceHtmlUrl":130},"scripts\u002Foutput.py",7989,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fgoogle-image-search\u002Fscripts\u002Foutput.py",{"path":132,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":133,"sourceHtmlUrl":134},"scripts\u002Fteam_scaling_calculator.py",21569,"https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002F.gemini-cto-advisor\u002Fscripts\u002Fteam_scaling_calculator.py",{"path":136,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":137,"sourceHtmlUrl":138},"scripts\u002Ftech_debt_analyzer.py",17297,"https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002F.gemini-cto-advisor\u002Fscripts\u002Ftech_debt_analyzer.py",[140,162,199,226,252,280],{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":39},"01M6EM8ES5M9J4S8N78NJST0YC","zarr-python","Chunked N-D arrays for cloud storage. Compressed arrays, parallel I\u002FO, S3\u002FGCS integration, NumPy\u002FDask\u002FXarray compatible, for large-scale scientific computing pipelines.","https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002Fzarr-python\u002FSKILL.md",[],[147,148,149,150,151,152,153,154,155,156,157,158,159,160,161],"python","zarr python","storage","integration","s3","gcs","cloud","dask","parallel","pipelines","arrays","numpy","scientific computing","scale","scientific",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":181,"publishedAt":39},"01M6EM8AR6ZFKZ9YVW8TTG850Z","zabbix","Zabbix monitoring system automation via API and Python. Use when: (1) Managing hosts, templates, items, triggers, or host groups, (2) Automating monitoring configuration, (3) Sending data via Zabbix trapper\u002Fsender, (4) Querying historical data or events, (5) Bulk operations on Zabbix objects, (6) Maintenance window management, (7) User\u002Fpermission management","https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002Fzabbix-api-skill\u002FSKILL.md",[168,173,176],{"categoryNo":169,"categoryName":170,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":174,"categoryName":175,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":177,"categoryName":178,"taxonomyType":179,"taxonomyTypeDesc":180},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[164,147,182,183,184,185,186,187,188,189,29,190,191,192,193,194,195,196,197,198],"automation","window management","monitoring","data","templates","api","system","operations","maintenance","objects","permission","bulk operations","triggers","host","events","via","bulk",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":39},"01M6EM6Q9JG846ECQY9A210A26","x-twitter-growth","X\u002FTwitter growth engine for building audience, crafting viral content, and analyzing engagement. Use when the user wants to grow on X\u002FTwitter, write tweets or threads, analyze their X profile, research competitors on X, plan a posting strategy, or optimize engagement. Complements social-content (generic multi-platform) with X-specific depth: algorithm mechanics, thread engineering, reply strategy, profile optimization, and competitive intelligence via web search.","https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002Fx-twitter-growth\u002FSKILL.md",[],[206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225],"twitter","x twitter growth","growth","competitive intelligence","search","analyzing","plan","marketing","web search","competitors","analyze","write","optimize","social","intelligence","viral","growth engine","mechanics","grow","competitive",{"skillNo":227,"name":228,"nameZh":6,"description":229,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":230,"categories":231,"keywords":232,"publishedAt":39},"01M6EM3FQNPYNKPC4CV9TCVNGD","what-if-oracle","Run structured What-If scenario analysis with multi-branch possibility exploration. Use this skill when the user asks speculative questions like \"what if...\", \"what would happen if...\", \"what are the possibilities\", \"explore scenarios\", \"scenario analysis\", \"possibility space\", \"what could go wrong\", \"best case \u002F worst case\", \"risk analysis\", \"contingency planning\", \"strategic options\", or any question about uncertain futures. Also trigger when the user faces a fork-in-the-road decision, wants to stress-test an idea, or needs to think through consequences before committing.","https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002Fwhat-if-oracle\u002FSKILL.md",[],[233,234,235,236,237,238,239,240,241,242,243,244,29,245,246,247,248,249,250,251],"oracle","what if oracle","test","planning","ux","futures","risk","analysis","explore","decision","branch","question","exploration","options","stress-test","strategies","trigger","case","multi",{"skillNo":253,"name":254,"nameZh":6,"description":255,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":256,"categories":257,"keywords":261,"publishedAt":39},"01M6EM08C06RGDYCJ86HAPK0FF","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002Fvercel-react-best-practices\u002FSKILL.md",[258],{"categoryNo":259,"categoryName":260,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000009","前端开发",[262,263,264,265,266,267,268,269,270,271,272,273,274,185,275,276,277,278,279,194],"react","vercel react best practices","best practices","react best practices","vercel","writing","performance","components","react components","guidelines","tasks","code","Optimization","Next.js","refactoring","performance optimization","next","pages",{"skillNo":281,"name":282,"nameZh":6,"description":283,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":284,"categories":285,"keywords":296,"publishedAt":39},"01M6EM00S13326QM08DTM94J6Z","venue-templates","Access comprehensive LaTeX templates, formatting requirements, and submission guidelines for major scientific publication venues (Nature, Science, PLOS, IEEE, ACM), academic conferences (NeurIPS, ICML, CVPR, CHI), research posters, and grant proposals (NSF, NIH, DOE, DARPA). This skill should be used when preparing manuscripts for journal submission, conference papers, research posters, or grant proposals and need venue-specific formatting requirements and templates.","https:\u002F\u002Fgithub.com\u002Flevalencia\u002Fagent-god-mode\u002Fblob\u002Fmain\u002Forganized-skills\u002Fvenue-templates\u002FSKILL.md",[286,289,292,293],{"categoryNo":287,"categoryName":288,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":290,"categoryName":291,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":174,"categoryName":175,"taxonomyType":171,"taxonomyTypeDesc":172},{"categoryNo":294,"categoryName":295,"taxonomyType":179,"taxonomyTypeDesc":180},"01JBSEEDCAT000000000000036","内容创作者",[186,297,298,271,299,300,301,302,303,304,305,217,306,307,308,309,310,311,161,312],"venue templates","research","NeurIPS","ICML","LaTeX","science","Bash","access","read","edit","proposals","Academic","requirements","formatting","journal","chi"]