multi-cloud-architecture
Design multi-cloud architectures using a decision framework to select and integrate services across AWS, Azure, and GCP. Use when building multi-cloud systems, avoiding vendor lock-in, or leveraging best-of-breed services from multiple providers.
71
55%
Does it follow best practices?
Impact
99%
1.07xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./tests/ext_conformance/artifacts/agents-wshobson/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 a clear 'Use when' clause and good trigger term coverage across the major cloud providers. Its main weakness is that the 'what' portion could be more specific about the concrete actions performed (e.g., comparing services, designing failover, mapping equivalent services). Overall it performs well for skill selection purposes.
Suggestions
Add more specific concrete actions to the 'what' portion, e.g., 'compare equivalent services across providers, design cross-cloud networking, map provider-specific services to portable abstractions'.
| 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 failover strategies, configuring cross-cloud networking, or setting up identity federation. | 2 / 3 |
Completeness | Clearly answers both 'what' (design multi-cloud architectures using a decision framework to select and integrate services across AWS, Azure, and GCP) 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', 'AWS', 'Azure', 'GCP', and 'multiple providers'. These cover the main ways users would phrase requests in this domain. | 3 / 3 |
Distinctiveness Conflict Risk | The multi-cloud focus across AWS, Azure, and GCP with the decision framework angle creates a clear niche. It's distinct from single-cloud architecture skills and from general infrastructure skills, with specific triggers like 'vendor lock-in' and 'best-of-breed' that are unlikely to conflict. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
20%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 overview or study guide rather than actionable instructions for Claude. It consists almost entirely of information Claude already knows (cloud service mappings, generic best practices, standard migration phases) with no concrete code, commands, decision frameworks with specific criteria, or executable examples. The content would need to be fundamentally restructured to provide novel, actionable guidance that Claude couldn't generate on its own.
Suggestions
Replace generic service comparison tables with a concrete decision framework that includes specific criteria and thresholds (e.g., 'Choose GCP Cloud Spanner when: >10TB, global distribution needed, budget >$X/month').
Add executable Terraform code examples showing how to implement at least one multi-cloud pattern end-to-end, rather than abstract descriptions.
Remove content Claude already knows (what EC2 is, generic best practices like 'right-size resources') and focus on novel decision logic, gotchas, and non-obvious tradeoffs.
Add validation checkpoints to the migration workflow, such as specific commands to verify connectivity, data integrity checks, and performance benchmarks to meet before proceeding to the next phase.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is verbose and largely consists of information Claude already knows—service name mappings, generic best practices lists, and high-level migration phases. Very little here is novel or adds value beyond what Claude could generate from its training data. Lists like '1. Right-size resources 2. Use serverless for variable workloads' are generic advice that waste tokens. | 1 / 3 |
Actionability | The skill provides no executable code, no concrete commands, no specific configuration examples, and no decision criteria with thresholds. Everything is abstract guidance like 'Use best service from each provider' and 'Implement comprehensive monitoring' without any concrete implementation details. | 1 / 3 |
Workflow Clarity | The migration strategy has a clear 4-phase sequence, and the multi-cloud patterns provide some structure. However, there are no validation checkpoints, no feedback loops, no concrete criteria for moving between phases, and no verification steps for any of the processes described. | 2 / 3 |
Progressive Disclosure | References to external files like `references/service-comparison.md` and `references/multi-cloud-patterns.md` are present and one-level deep, which is good. However, the main file contains extensive inline content (service comparison tables, cost strategies, best practices) that could be better split out, and the references are not clearly signaled with descriptions of what additional value they provide. | 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
- Dicklesworthstone/pi_agent_rust
- Commit
6e3d68c
- 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.