service-cost-deep-dive
Use when you need a detailed breakdown of a specific cloud service's costs — EC2, RDS, S3, Lambda, etc. — to understand usage patterns and find optimization opportunities
44
46%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/cost-analyst/skills/service-cost-deep-dive/SKILL.mdQuality
Discovery
64%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has good trigger term coverage with specific cloud service names and cost-related keywords, but lacks concrete action verbs describing what the skill actually does. The 'what' component is underdeveloped — it tells you when to use it but not what specific outputs or analyses it produces. Adding explicit capabilities would significantly improve its effectiveness.
Suggestions
Add explicit capability statements before the 'Use when' clause, e.g., 'Analyzes cloud billing data, generates cost breakdowns by service, identifies unused resources, and recommends cost-saving actions.'
Strengthen the 'what' by listing specific outputs or deliverables (e.g., 'produces cost trend charts, highlights spending anomalies, compares on-demand vs reserved pricing').
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (cloud service costs) and lists specific services (EC2, RDS, S3, Lambda), but the actual actions are vague — 'detailed breakdown', 'understand usage patterns', and 'find optimization opportunities' are high-level rather than concrete actions like 'generate cost reports' or 'compare monthly spend'. | 2 / 3 |
Completeness | The description has a 'Use when...' clause which addresses the 'when', but the 'what does this do' part is weak — it doesn't clearly state what the skill actually does (e.g., generates reports, analyzes billing data, produces charts). The 'what' is implied but not explicitly stated. | 2 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'cloud service', 'costs', 'EC2', 'RDS', 'S3', 'Lambda', 'usage patterns', 'optimization'. These are terms a user would naturally use when asking about cloud cost analysis. | 3 / 3 |
Distinctiveness Conflict Risk | The focus on cloud service costs with specific service names (EC2, RDS, S3, Lambda) provides some distinctiveness, but 'optimization opportunities' and 'usage patterns' could overlap with general cloud infrastructure or DevOps skills. It could also conflict with a broader cloud cost management or FinOps skill. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is extremely verbose, containing extensive output templates, service-specific guides, and general optimization advice that inflates it well beyond what's needed. While the core workflow (Steps 1-9) provides a reasonable analytical sequence with concrete API call patterns, the document is dominated by template boilerplate and knowledge Claude already possesses about cloud cost optimization. The content would benefit enormously from splitting the output templates and service-specific guides into separate reference files.
Suggestions
Move the entire Output Format section (sections 1-11) into a separate reference file like `output-template.md` and reference it with a single line from SKILL.md
Move Service-Specific Analysis Guides and Advanced Techniques into separate reference files — this content is reference material, not core workflow
Remove tips and best practices that restate general cloud optimization knowledge Claude already knows (e.g., 'Quantify everything', 'Consider dependencies', 'Think holistically')
Add validation checkpoints between steps — e.g., 'If get_dimension_values returns no match, ask user to clarify service name' and 'If usage type dimension doesn't exist, skip to Step 4'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~400+ lines. Massive output template sections with placeholder tables, extensive service-specific guides, and tips sections that largely restate things Claude already knows (e.g., 'Be service-specific,' 'Quantify everything'). The output format alone is enormous and mostly template boilerplate. Much of the service-specific analysis guides repeat general cloud optimization knowledge Claude already possesses. | 1 / 3 |
Actionability | Provides concrete API call patterns with specific function signatures and parameters, which is useful. However, the code examples use placeholder syntax like '[service_name]' and are not fully executable. The optimization recommendations in Steps 8+ are descriptive checklists rather than actionable code or commands. The savings rate calculation is one of the few truly executable snippets. | 2 / 3 |
Workflow Clarity | Steps 1-9 provide a clear sequence for the analysis process, which is good. However, there are no validation checkpoints — no guidance on what to do if API calls return empty results, if dimensions don't exist, or if data looks anomalous. For a multi-step process involving many sequential API calls, the lack of error handling or verification between steps is a gap. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text. The output format templates (sections 1-11), service-specific analysis guides, and advanced techniques sections are all inline and massively inflate the document. These should be split into separate reference files. While the 'See Also' section references external files, the bulk of content that belongs in those references is duplicated inline. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (561 lines); consider splitting into references/ and linking | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Repository
- Cloudzero/cloudzero-claude-marketplace
- Commit
760a9c7
- Reviewed
Table of Contents
Is this your skill?
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.