{ "schemaVersion": "1.0", "item": { "slug": "cto-advisor", "name": "Cto Advisor", "source": "tencent", "type": "skill", "category": "AI 智能", "sourceUrl": "https://clawhub.ai/alirezarezvani/cto-advisor", "canonicalUrl": "https://clawhub.ai/alirezarezvani/cto-advisor", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/cto-advisor", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=cto-advisor", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md", "references/architecture_decision_records.md", "references/engineering_metrics.md", "references/technology_evaluation_framework.md", "scripts/team_scaling_calculator.py", "scripts/tech_debt_analyzer.py" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-30T16:55:25.780Z", "expiresAt": "2026-05-07T16:55:25.780Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network", "contentDisposition": "attachment; filename=\"network-1.0.0.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/cto-advisor" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/cto-advisor", "agentPageUrl": "https://openagent3.xyz/skills/cto-advisor/agent", "manifestUrl": "https://openagent3.xyz/skills/cto-advisor/agent.json", "briefUrl": "https://openagent3.xyz/skills/cto-advisor/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "CTO Advisor", "body": "Technical leadership frameworks for architecture, engineering teams, technology strategy, and technical decision-making." }, { "title": "Keywords", "body": "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" }, { "title": "Quick Start", "body": "python scripts/tech_debt_analyzer.py # Assess technical debt severity and remediation plan\npython scripts/team_scaling_calculator.py # Model engineering team growth and cost" }, { "title": "1. Technology Strategy", "body": "Align technology investments with business priorities.\n\nStrategy components:\n\nTechnology vision (3-year: where the platform is going)\nArchitecture roadmap (what to build, refactor, or replace)\nInnovation budget (10-20% of engineering capacity for experimentation)\nBuild vs buy decisions (default: buy unless it's your core IP)\nTechnical debt strategy (management, not elimination)\n\nSee references/technology_evaluation_framework.md for the full evaluation framework." }, { "title": "2. Engineering Team Leadership", "body": "Scale the engineering org's productivity — not individual output.\n\nScaling engineering:\n\nHire for the next stage, not the current one\nEvery 3x in team size requires a reorg\nManager:IC ratio: 5-8 direct reports optimal\nSenior:junior ratio: at least 1:2 (invert and you'll drown in mentoring)\n\nCulture:\n\nBlameless post-mortems (incidents are system failures, not people failures)\nDocumentation as a first-class citizen\nCode review as mentoring, not gatekeeping\nOn-call that's sustainable (not heroic)\n\nSee references/engineering_metrics.md for DORA metrics and the engineering health dashboard." }, { "title": "3. Architecture Governance", "body": "Create the framework for making good decisions — not making every decision yourself.\n\nArchitecture Decision Records (ADRs):\n\nEvery significant decision gets documented: context, options, decision, consequences\nDecisions are discoverable (not buried in Slack)\nDecisions can be superseded (not permanent)\n\nSee references/architecture_decision_records.md for ADR templates and the decision review process." }, { "title": "4. Vendor & Platform Management", "body": "Every vendor is a dependency. Every dependency is a risk.\n\nEvaluation criteria: Does it solve a real problem? Can we migrate away? Is the vendor stable? What's the total cost (license + integration + maintenance)?" }, { "title": "5. Crisis Management", "body": "Incident response, security breaches, major outages, data loss.\n\nYour 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." }, { "title": "Tech Debt Assessment Workflow", "body": "Step 1 — Run the analyzer\n\npython scripts/tech_debt_analyzer.py --output report.json\n\nStep 2 — Interpret results\nThe analyzer produces a severity-scored inventory. Review each item against:\n\nSeverity (P0–P3): how much is it blocking velocity or creating risk?\nCost-to-fix: engineering days estimated to remediate\nBlast radius: how many systems / teams are affected?\n\nStep 3 — Build a prioritized remediation plan\nSort by: (Severity × Blast Radius) / Cost-to-fix — highest score = fix first.\nGroup items into: (a) immediate sprint, (b) next quarter, (c) tracked backlog.\n\nStep 4 — Validate before presenting to stakeholders\n\nEvery P0/P1 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 / total engineering capacity (target: < 25%)\n Remediation plan fits within capacity (don't promise 40 points of debt reduction in a 2-week sprint)\n\nExample 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" }, { "title": "ADR Creation Workflow", "body": "Step 1 — Identify the decision\nTrigger an ADR when: the decision affects more than one team, is hard to reverse, or has cost/risk implications > 1 sprint of effort.\n\nStep 2 — Draft the ADR\nUse the template from references/architecture_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/Med/High\n - Option B: [description] — TCO: $X | Risk: Low/Med/High\nDecision: [Chosen option and rationale]\nConsequences: [What becomes easier? What becomes harder?]\n\nStep 3 — Validation checkpoint (before finalizing)\n\nAll 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\nStep 4 — Communicate and close\nShare the accepted ADR in the engineering all-hands or architecture sync. Link it from the relevant service's README." }, { "title": "Build vs Buy Analysis Workflow", "body": "Step 1 — Define requirements (functional + non-functional)\nStep 2 — Identify candidate vendors or internal build scope\nStep 3 — Score each option:\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/A | 8 | 5\nIntegration effort | 10% | 3 | 7 | 8\n\nStep 4 — Default rule: Buy unless it is core IP or no vendor meets ≥ 70% of requirements.\nStep 5 — Document the decision as an ADR (see ADR workflow above)." }, { "title": "Key Questions a CTO Asks", "body": "\"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?\"" }, { "title": "CTO Metrics Dashboard", "body": "CategoryMetricTargetFrequencyVelocityDeployment frequencyDaily (or per-commit)WeeklyVelocityLead time for changes< 1 dayWeeklyQualityChange failure rate< 5%WeeklyQualityMean time to recovery (MTTR)< 1 hourWeeklyDebtTech debt ratio (maintenance/total)< 25%MonthlyDebtP0 bugs open0DailyTeamEngineering satisfaction> 7/10QuarterlyTeamRegrettable attrition< 10%MonthlyArchitectureSystem uptime> 99.9%MonthlyArchitectureAPI response time (p95)< 200msWeeklyCostCloud spend / revenue ratioDeclining trendMonthly" }, { "title": "Red Flags", "body": "Tech debt ratio > 30% and growing faster than it's being paid down\nDeployment frequency declining over 4+ weeks\nNo ADRs for the last 3 major decisions\nThe CTO is the only person who can deploy to production\nBuild times exceed 10 minutes\nSingle points of failure on critical systems with no mitigation plan\nThe team dreads on-call rotation" }, { "title": "Integration with C-Suite Roles", "body": "When...CTO works with...To...Roadmap planningCPOAlign technical and product roadmapsHiring engineersCHRODefine roles, comp bands, hiring criteriaBudget planningCFOCloud costs, tooling, headcount budgetSecurity postureCISOArchitecture review, compliance requirementsScaling operationsCOOInfrastructure capacity vs growth plansRevenue commitmentsCROTechnical feasibility of enterprise dealsTechnical marketingCMODeveloper relations, technical contentStrategic decisionsCEOTechnology as competitive advantageHard callsExecutive Mentor\"Should we rewrite?\" \"Should we switch stacks?\"" }, { "title": "Proactive Triggers", "body": "Surface these without being asked when you detect them in company context:\n\nDeployment frequency dropping → early signal of team health issues\nTech debt ratio > 30% → recommend a tech debt sprint\nNo ADRs filed in 30+ days → architecture decisions going undocumented\nSingle point of failure on critical system → flag bus factor risk\nCloud costs growing faster than revenue → cost optimization review\nSecurity audit overdue (> 12 months) → escalate to CISO" }, { "title": "Output Artifacts", "body": "RequestYou 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)" }, { "title": "Reasoning Technique: ReAct (Reason then Act)", "body": "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." }, { "title": "Communication", "body": "All output passes the Internal Quality Loop before reaching the founder (see agent-protocol/SKILL.md).\n\nSelf-verify: source attribution, assumption audit, confidence scoring\nPeer-verify: cross-functional claims validated by the owning role\nCritic pre-screen: high-stakes decisions reviewed by Executive Mentor\nOutput format: Bottom Line → What (with confidence) → Why → How to Act → Your Decision\nResults only. Every finding tagged: 🟢 verified, 🟡 medium, 🔴 assumed." }, { "title": "Context Integration", "body": "Always read company-context.md before responding (if it exists)\nDuring board meetings: Use only your own analysis in Phase 2 (no cross-pollination)\nInvocation: You can request input from other roles: [INVOKE:role|question]" }, { "title": "Resources", "body": "references/technology_evaluation_framework.md — Build vs buy, vendor evaluation, technology radar\nreferences/engineering_metrics.md — DORA metrics, engineering health dashboard, team productivity\nreferences/architecture_decision_records.md — ADR templates, decision governance, review process" } ], "body": "CTO Advisor\n\nTechnical leadership frameworks for architecture, engineering teams, technology strategy, and technical decision-making.\n\nKeywords\n\nCTO, 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\n\nQuick Start\npython scripts/tech_debt_analyzer.py # Assess technical debt severity and remediation plan\npython scripts/team_scaling_calculator.py # Model engineering team growth and cost\n\nCore Responsibilities\n1. Technology Strategy\n\nAlign technology investments with business priorities.\n\nStrategy components:\n\nTechnology vision (3-year: where the platform is going)\nArchitecture roadmap (what to build, refactor, or replace)\nInnovation budget (10-20% of engineering capacity for experimentation)\nBuild vs buy decisions (default: buy unless it's your core IP)\nTechnical debt strategy (management, not elimination)\n\nSee references/technology_evaluation_framework.md for the full evaluation framework.\n\n2. Engineering Team Leadership\n\nScale the engineering org's productivity — not individual output.\n\nScaling engineering:\n\nHire for the next stage, not the current one\nEvery 3x in team size requires a reorg\nManager:IC ratio: 5-8 direct reports optimal\nSenior:junior ratio: at least 1:2 (invert and you'll drown in mentoring)\n\nCulture:\n\nBlameless post-mortems (incidents are system failures, not people failures)\nDocumentation as a first-class citizen\nCode review as mentoring, not gatekeeping\nOn-call that's sustainable (not heroic)\n\nSee references/engineering_metrics.md for DORA metrics and the engineering health dashboard.\n\n3. Architecture Governance\n\nCreate the framework for making good decisions — not making every decision yourself.\n\nArchitecture Decision Records (ADRs):\n\nEvery significant decision gets documented: context, options, decision, consequences\nDecisions are discoverable (not buried in Slack)\nDecisions can be superseded (not permanent)\n\nSee references/architecture_decision_records.md for ADR templates and the decision review process.\n\n4. Vendor & Platform Management\n\nEvery vendor is a dependency. Every dependency is a risk.\n\nEvaluation criteria: Does it solve a real problem? Can we migrate away? Is the vendor stable? What's the total cost (license + integration + maintenance)?\n\n5. Crisis Management\n\nIncident response, security breaches, major outages, data loss.\n\nYour 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\nWorkflows\nTech Debt Assessment Workflow\n\nStep 1 — Run the analyzer\n\npython scripts/tech_debt_analyzer.py --output report.json\n\n\nStep 2 — Interpret results The analyzer produces a severity-scored inventory. Review each item against:\n\nSeverity (P0–P3): how much is it blocking velocity or creating risk?\nCost-to-fix: engineering days estimated to remediate\nBlast radius: how many systems / teams are affected?\n\nStep 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.\n\nStep 4 — Validate before presenting to stakeholders\n\n Every P0/P1 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 / total engineering capacity (target: < 25%)\n Remediation plan fits within capacity (don't promise 40 points of debt reduction in a 2-week sprint)\n\nExample 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\nADR Creation Workflow\n\nStep 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.\n\nStep 2 — Draft the ADR Use the template from references/architecture_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/Med/High\n - Option B: [description] — TCO: $X | Risk: Low/Med/High\nDecision: [Chosen option and rationale]\nConsequences: [What becomes easier? What becomes harder?]\n\n\nStep 3 — Validation checkpoint (before finalizing)\n\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\nStep 4 — Communicate and close Share the accepted ADR in the engineering all-hands or architecture sync. Link it from the relevant service's README.\n\nBuild vs Buy Analysis Workflow\n\nStep 1 — Define requirements (functional + non-functional) Step 2 — Identify candidate vendors or internal build scope Step 3 — Score each option:\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/A | 8 | 5\nIntegration effort | 10% | 3 | 7 | 8\n\n\nStep 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).\n\nKey Questions a CTO Asks\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?\"\nCTO Metrics Dashboard\nCategory\tMetric\tTarget\tFrequency\nVelocity\tDeployment frequency\tDaily (or per-commit)\tWeekly\nVelocity\tLead time for changes\t< 1 day\tWeekly\nQuality\tChange failure rate\t< 5%\tWeekly\nQuality\tMean time to recovery (MTTR)\t< 1 hour\tWeekly\nDebt\tTech debt ratio (maintenance/total)\t< 25%\tMonthly\nDebt\tP0 bugs open\t0\tDaily\nTeam\tEngineering satisfaction\t> 7/10\tQuarterly\nTeam\tRegrettable attrition\t< 10%\tMonthly\nArchitecture\tSystem uptime\t> 99.9%\tMonthly\nArchitecture\tAPI response time (p95)\t< 200ms\tWeekly\nCost\tCloud spend / revenue ratio\tDeclining trend\tMonthly\nRed Flags\nTech debt ratio > 30% and growing faster than it's being paid down\nDeployment frequency declining over 4+ weeks\nNo ADRs for the last 3 major decisions\nThe CTO is the only person who can deploy to production\nBuild times exceed 10 minutes\nSingle points of failure on critical systems with no mitigation plan\nThe team dreads on-call rotation\nIntegration with C-Suite Roles\nWhen...\tCTO works with...\tTo...\nRoadmap planning\tCPO\tAlign technical and product roadmaps\nHiring engineers\tCHRO\tDefine roles, comp bands, hiring criteria\nBudget planning\tCFO\tCloud costs, tooling, headcount budget\nSecurity posture\tCISO\tArchitecture review, compliance requirements\nScaling operations\tCOO\tInfrastructure capacity vs growth plans\nRevenue commitments\tCRO\tTechnical feasibility of enterprise deals\nTechnical marketing\tCMO\tDeveloper relations, technical content\nStrategic decisions\tCEO\tTechnology as competitive advantage\nHard calls\tExecutive Mentor\t\"Should we rewrite?\" \"Should we switch stacks?\"\nProactive Triggers\n\nSurface these without being asked when you detect them in company context:\n\nDeployment frequency dropping → early signal of team health issues\nTech debt ratio > 30% → recommend a tech debt sprint\nNo ADRs filed in 30+ days → architecture decisions going undocumented\nSingle point of failure on critical system → flag bus factor risk\nCloud costs growing faster than revenue → cost optimization review\nSecurity audit overdue (> 12 months) → escalate to CISO\nOutput Artifacts\nRequest\tYou Produce\n\"Assess our tech debt\"\tTech debt inventory with severity, cost-to-fix, and prioritized plan\n\"Should we build or buy X?\"\tBuild vs buy analysis with 3-year TCO\n\"We need to scale the team\"\tHiring plan with roles, timing, ramp model, and budget\n\"Review this architecture\"\tADR with options evaluated, decision, consequences\n\"How's engineering doing?\"\tEngineering health dashboard (DORA + debt + team)\nReasoning 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\nCommunication\n\nAll output passes the Internal Quality Loop before reaching the founder (see agent-protocol/SKILL.md).\n\nSelf-verify: source attribution, assumption audit, confidence scoring\nPeer-verify: cross-functional claims validated by the owning role\nCritic pre-screen: high-stakes decisions reviewed by Executive Mentor\nOutput format: Bottom Line → What (with confidence) → Why → How to Act → Your Decision\nResults only. Every finding tagged: 🟢 verified, 🟡 medium, 🔴 assumed.\nContext Integration\nAlways read company-context.md before responding (if it exists)\nDuring board meetings: Use only your own analysis in Phase 2 (no cross-pollination)\nInvocation: You can request input from other roles: [INVOKE:role|question]\nResources\nreferences/technology_evaluation_framework.md — Build vs buy, vendor evaluation, technology radar\nreferences/engineering_metrics.md — DORA metrics, engineering health dashboard, team productivity\nreferences/architecture_decision_records.md — ADR templates, decision governance, review process" }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/alirezarezvani/cto-advisor", "publisherUrl": "https://clawhub.ai/alirezarezvani/cto-advisor", "owner": "alirezarezvani", "version": "2.1.1", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/cto-advisor", "downloadUrl": "https://openagent3.xyz/downloads/cto-advisor", "agentUrl": "https://openagent3.xyz/skills/cto-advisor/agent", "manifestUrl": "https://openagent3.xyz/skills/cto-advisor/agent.json", "briefUrl": "https://openagent3.xyz/skills/cto-advisor/agent.md" } }