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.
52
56%
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/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 trigger terms covering all major cloud providers and clear 'Use when' guidance. Its main weakness is that the capability description is somewhat high-level—it could benefit from listing more specific concrete actions beyond 'select and integrate services.' Overall, it performs well for skill selection purposes.
Suggestions
Add more specific concrete actions to improve specificity, e.g., 'compare pricing models, design cross-cloud networking, plan data residency strategies, evaluate service equivalencies across providers.'
| 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 designing networking topologies, configuring IAM federation, or setting up cross-cloud data replication. | 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 keywords 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 would naturally use when seeking this kind of help. | 3 / 3 |
Distinctiveness Conflict Risk | The multi-cloud focus with all four named providers and the decision framework concept create a clear niche. This is unlikely to conflict with single-cloud architecture skills or general infrastructure skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
22%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads more like a high-level overview document or wiki page than an actionable skill for Claude. It catalogs cloud service equivalencies and describes patterns abstractly but provides zero executable code, no Terraform examples, no concrete implementation steps, and no validation checkpoints. The content is largely information Claude already knows, making it a poor use of context window tokens.
Suggestions
Add concrete, executable Terraform code examples for at least one multi-cloud pattern (e.g., a Kubernetes cluster deployed across two providers with shared state).
Replace the generic migration strategy and best practices sections with specific decision trees or checklists that encode non-obvious judgment calls (e.g., 'If latency between clouds > 50ms, use Pattern 1 instead of Pattern 2').
Add validation steps to workflows—e.g., 'After deploying cross-cloud networking, verify connectivity: `kubectl exec -it test-pod -- curl http://service.other-cloud:8080/health`'.
Remove or drastically condense the service comparison tables (Claude knows these mappings) and instead focus on non-obvious gotchas, pricing traps, or compatibility issues that would genuinely inform architectural decisions.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content includes some unnecessary framing (Purpose, When to Use sections) and generic best practices that Claude already knows. The service comparison tables are useful reference material but the migration strategy and best practices sections are largely common knowledge that add bulk without unique value. | 2 / 3 |
Actionability | The skill is almost entirely descriptive with no executable code, no concrete commands, no specific Terraform examples, and no copy-paste-ready configurations. Patterns are described abstractly ('Database replication across clouds') without showing how to implement them. The migration strategy is generic project management advice rather than actionable technical guidance. | 1 / 3 |
Workflow Clarity | The migration strategy lists phases but lacks any validation checkpoints, specific commands, or feedback loops. There's no concrete sequence for actually implementing a multi-cloud architecture—no 'run this, then verify that' steps. The multi-cloud patterns are listed as bullet points without implementation sequences. | 1 / 3 |
Progressive Disclosure | The skill references `references/service-comparison.md` and `references/multi-cloud-patterns.md`, and links to related skills, which shows intent for progressive disclosure. However, no bundle files exist to support these references, and the main file contains substantial inline content (tables, patterns, strategies) that could be better organized into referenced files. | 2 / 3 |
Total | 6 / 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
cf6059d
- 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.