multi-cloud-architecture
Design multi-cloud architectures using a decision framework to select and integrate services across AWS, Azure, GCP, and OCI. Use when building multi-cloud systems, avoiding vendor lock-in, or leveraging best-of-breed services from multiple providers.
59
48%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/cloud-infrastructure/skills/multi-cloud-architecture/SKILL.mdQuality
Discovery
89%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 solid description with excellent completeness (clear 'what' and 'when' clauses) and strong trigger terms covering the major cloud providers and common user language like 'vendor lock-in' and 'multi-cloud'. The main weakness is that the specificity of concrete actions could be improved—it describes the general approach (decision framework, select and integrate) but doesn't enumerate specific deliverables or architectural tasks.
Suggestions
Add more specific concrete actions such as 'compare pricing models, design failover strategies, map equivalent services across providers, create architecture diagrams' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (multi-cloud architectures) and mentions some actions ('select and integrate services', 'decision framework'), but doesn't list multiple concrete specific actions like specific architectural patterns, migration steps, or configuration tasks. | 2 / 3 |
Completeness | Clearly answers both 'what' (design multi-cloud architectures using a decision framework to select and integrate services across providers) and 'when' (explicit 'Use when' clause covering building multi-cloud systems, avoiding vendor lock-in, or leveraging best-of-breed services). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'multi-cloud', 'vendor lock-in', 'best-of-breed', and names all four major providers (AWS, Azure, GCP, OCI). These are terms users naturally use when seeking this kind of help. | 3 / 3 |
Distinctiveness Conflict Risk | The multi-cloud focus with specific provider names (AWS, Azure, GCP, OCI) and the decision framework angle create a clear niche that is unlikely to conflict with single-cloud provider skills or general architecture skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
7%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads like a high-level cloud architecture overview or study guide rather than an actionable skill for Claude. It consists almost entirely of information Claude already knows (service name mappings, generic best practices, standard migration phases) without providing any executable code, decision frameworks with concrete criteria, or novel guidance. The content would need a fundamental restructuring to become a useful skill.
Suggestions
Replace the service comparison tables with a concrete decision framework—e.g., 'If workload requires X, choose Y because Z'—with specific selection criteria and tradeoffs rather than just listing equivalent services.
Add executable Terraform/OpenTofu code examples showing how to implement at least one multi-cloud pattern (e.g., a DR setup or cloud-agnostic abstraction layer).
Include concrete validation steps in the migration workflow, such as specific commands to verify connectivity, benchmark performance, or validate data integrity between clouds.
Remove generic best practices that Claude already knows (e.g., 'use infrastructure as code', 'design for failure') and replace with specific, non-obvious guidance unique to multi-cloud scenarios.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose with large comparison tables that Claude already knows, generic best practices lists, and high-level migration phases that add no novel information. Almost every section restates common cloud knowledge without providing unique decision-making logic or executable guidance. | 1 / 3 |
Actionability | The content is entirely descriptive with no executable code, commands, or concrete examples. There are no Terraform snippets, no CLI commands, no configuration files—just abstract lists and tables. Phrases like 'Design for failure across clouds' and 'Implement comprehensive monitoring' are vague platitudes, not actionable instructions. | 1 / 3 |
Workflow Clarity | The migration strategy lists phases but with no validation checkpoints, no concrete criteria for moving between phases, and no feedback loops. The multi-cloud patterns are described at a surface level without sequenced steps or decision criteria for choosing between them. | 1 / 3 |
Progressive Disclosure | There are two references to external files (service-comparison.md and multi-cloud-patterns.md) and related skills are listed, showing some structure. However, the main file is a monolithic wall of tables and lists that could be significantly trimmed, with detailed comparisons moved to reference files. | 2 / 3 |
Total | 5 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- wshobson/agents
- Commit
27a7ed9
- 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.