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.
91
88%
Does it follow best practices?
Impact
92%
1.43xAverage score across 6 eval scenarios
Passed
No known issues
Quality
Discovery
92%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly communicates its purpose, lists concrete capabilities, and provides explicit trigger guidance with good keyword coverage. The main weakness is that its broad scope—spanning leadership, architecture, metrics, and strategy—could create some overlap with more specialized skills in those individual areas. Overall, it follows best practices well with third-person voice and a clear 'Use when' clause.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: assessing technical debt, scaling engineering teams, evaluating technologies, making architecture decisions, establishing engineering metrics. These are clear, actionable capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (technical leadership guidance for engineering teams, architecture decisions, and technology strategy) and 'when' with an explicit 'Use when...' clause listing specific scenarios and trigger terms. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'CTO', 'tech debt', 'technical debt', 'team scaling', 'architecture decisions', 'technology evaluation', 'engineering metrics', 'DORA metrics', 'technology strategy'. Includes both formal and informal variations (e.g., 'tech debt' and 'technical debt'). | 3 / 3 |
Distinctiveness Conflict Risk | While terms like 'CTO', 'DORA metrics', and 'tech debt' are fairly distinctive, broader terms like 'architecture decisions' and 'technology evaluation' could overlap with general software engineering or DevOps skills. The scope is somewhat broad, covering leadership, strategy, and metrics. | 2 / 3 |
Total | 11 / 12 Passed |
Implementation
85%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured CTO advisor skill with strong actionability through concrete workflows, scoring frameworks, and validation checklists. The progressive disclosure is excellent with clear references to supporting documents. The main weakness is moderate verbosity — sections like 'Key Questions a CTO Asks', 'Red Flags', and some cultural guidance explain things Claude already understands, consuming tokens without adding unique procedural value.
Suggestions
Trim or remove the 'Key Questions a CTO Asks' section — Claude can generate these contextually without being told what questions a CTO asks.
Condense the 'Core Responsibilities' cultural guidance (blameless post-mortems, code review philosophy) which Claude already knows, and focus those sections on the specific frameworks and thresholds unique to this skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly comprehensive but includes some content Claude already knows (e.g., explaining what ADRs are, general leadership platitudes like 'blameless post-mortems'). The 'Key Questions a CTO Asks' section and some cultural guidance are padding. However, the tables and workflows are dense and useful, so it's not egregiously verbose. | 2 / 3 |
Actionability | The workflows provide concrete, step-by-step guidance with specific commands, scoring templates, example output tables, and checklists. The Build vs Buy scoring matrix, Tech Debt priority formula (`Severity × Blast Radius / Cost-to-fix`), and ADR template are all directly usable and copy-paste ready. | 3 / 3 |
Workflow Clarity | Multi-step workflows are clearly sequenced with explicit validation checkpoints (checklists before presenting to stakeholders, validation before finalizing ADRs). The Tech Debt Assessment workflow includes a feedback loop with capacity validation, and the ADR workflow has a clear checkpoint before finalization with specific criteria. | 3 / 3 |
Progressive Disclosure | The skill provides a clear overview with well-signaled one-level-deep references to `references/technology_evaluation_framework.md`, `references/engineering_metrics.md`, and `references/architecture_decision_records.md`. Content is appropriately split between the main skill and reference files, with a dedicated Resources section at the bottom. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 10 / 11 Passed | |
f567c61
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.