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.
67
48%
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 capability description could be more specific about the concrete actions performed (e.g., service mapping, cost comparison, migration planning). Overall it performs well for skill selection purposes.
Suggestions
Add more specific concrete actions like 'map equivalent services across providers, design cross-cloud networking, compare pricing models, plan migration strategies' 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 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
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 overview document that restates common cloud knowledge Claude already possesses. It lacks actionable, concrete guidance—no Terraform examples, no architecture diagrams as code, no decision trees with specific criteria, no executable commands. The content would need a fundamental rethink to provide genuine value beyond what Claude can generate from its training data.
Suggestions
Replace generic service comparison tables with a concrete decision framework (e.g., a decision tree with specific criteria like 'if latency < 10ms AND data sovereignty required in EU, then...' with actual Terraform or architecture-as-code examples).
Add executable Terraform code examples showing how to implement at least one multi-cloud pattern end-to-end (e.g., a DR setup with database replication across AWS and GCP).
Remove content Claude already knows (basic service name mappings, generic best practices like 'design for failure', 'train teams') and focus on non-obvious gotchas, specific configuration pitfalls, and concrete decision criteria.
Add validation checkpoints to the migration workflow—e.g., specific commands to verify connectivity, data integrity checks between clouds, and rollback procedures with concrete steps.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is verbose and largely consists of information Claude already knows—service name mappings, generic best practices ('design for failure', 'train teams'), and high-level migration phases that are standard knowledge. Very little here adds novel, non-obvious information that Claude couldn't generate on its own. | 1 / 3 |
Actionability | The skill provides no executable code, no concrete commands, no specific configuration examples, and no copy-paste-ready artifacts. Everything is abstract guidance ('use Terraform', 'implement CI/CD pipelines', 'monitor performance') without showing how to actually do any of it. | 1 / 3 |
Workflow Clarity | The migration strategy lists phases but with no validation checkpoints, no concrete verification steps, and no feedback loops. The multi-cloud patterns are described at a bullet-point level without sequenced implementation steps. For architectures involving complex multi-cloud operations, this lacks the rigor needed. | 1 / 3 |
Progressive Disclosure | The skill references external files (references/service-comparison.md, references/multi-cloud-patterns.md) and related skills, which is good structure. However, the main file itself contains too much generic content that should either be cut or moved to reference files, and the inline service comparison tables are extensive yet shallow. | 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
- Dicklesworthstone/pi_agent_rust
- Commit
47823e3
- 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.