cloud

Overview of cloud skill

What the cloud skill does

The cloud skill helps you generate PlantUML cloud architecture diagrams with provider-specific service icons, so your output reads like an actual AWS, Azure, GCP, Alibaba Cloud, IBM Cloud, or OpenStack architecture instead of a generic sketch. It is best when you need a cloud guide for Cloud Architecture that shows real services, boundaries, and traffic flow.

When this skill is the right fit

Use the cloud skill if you are documenting deployments, proposing an architecture, comparing cloud services, or turning a rough system description into a diagram with official stencil icons. It is a strong fit for cloud install decisions, design reviews, and architecture handoffs where icon accuracy matters.

What makes it different

The main differentiator is stencil-aware PlantUML syntax: it expects mxgraph.* service icons, cloud containers, and directional flow, not just boxes and arrows. That makes the cloud skill more precise than a normal prompt for diagrams, especially when readers care about whether the diagram shows VPCs, regions, subnets, load balancers, databases, and managed services correctly.

How to Use cloud skill

Install and open the right files

Install the cloud skill with npx skills add markdown-viewer/skills --skill cloud. Then start with SKILL.md and the examples in examples/ before you write your own diagram. There are no helper scripts or extra rule folders here, so the examples are the best source for cloud install context and pattern matching.

Turn a rough goal into a usable prompt

Give the skill a concrete architecture, not a vague outcome. A strong input names the provider, workload type, traffic path, and must-include services. For example: “Create an AWS web app diagram with users, CloudFront, ALB, EC2 Auto Scaling, RDS, and S3; show public and private subnets.” That is much better than “draw my cloud architecture” because the skill can map each service to the correct stencil and layout.

Practical workflow for better output

Start by deciding the provider and the boundary model: region, VPC, subnet, zone, or cluster. Then list the services in flow order, from entry point to compute to storage or events. If you want a diagram that uses the cloud skill well, include whether the architecture is synchronous, event-driven, multi-AZ, hybrid, or serverless, because those choices change the container structure and arrows.

What to check in the examples

Read examples/aws-basic.md, examples/aws-serverless.md, examples/azure-hybrid-network.md, examples/gcp-log-processing.md, and examples/alibaba-web-app.md first. They show the fastest path to good cloud usage: provider naming, nested containers, multi-line labels, async arrows, and when to duplicate components across zones or paths. Use them as patterns, not templates to paste unchanged.

cloud skill FAQ

Is the cloud skill only for cloud diagrams?

Yes. The cloud skill is for cloud architecture diagrams with provider stencils. If you need general software modeling, use uml. If you need network topology without cloud services, use network. That boundary matters because the skill is optimized for cloud service icons and deployment structure, not every kind of diagram.

Do I need to know PlantUML already?

Not much. You can start with plain architecture requirements and let the skill handle the stencil syntax, but you will get better results if you know the basics of @startuml, @enduml, arrow direction, and containers. The cloud skill is beginner-friendly for cloud architecture, but it is not a substitute for clear system input.

How does this compare with a normal prompt?

A normal prompt can describe the architecture, but the cloud skill adds installable conventions: correct provider icon families, layout expectations, and cloud-specific grouping. That reduces guesswork when you need a diagram that is readable by engineers and consistent across teams.

When should I not use cloud skill?

Do not use it if your diagram is mostly generic application logic, pure sequence behavior, or a network map without cloud-managed services. It is also a poor fit if you cannot name the provider or service set, because the result will become too abstract to be useful.

How to Improve cloud skill

Give the model stronger architecture facts

The cloud skill works best when you specify provider, region count, network boundaries, and service roles. Better input: “AWS, two AZs, public ALB, private app tier, RDS primary/standby, S3 for assets, NAT gateway for outbound.” Weak input: “modern scalable app.” The first lets the skill produce a concrete cloud guide; the second forces it to invent structure.

State the diagram’s purpose

Tell it whether the diagram is for ops, review, onboarding, migration, or cloud architecture documentation. That changes how much detail belongs in the diagram. For example, an install decision page for executives may need fewer internal services, while an engineering handoff needs subnet and data-flow detail.

Watch for the common failure modes

The main failure modes are wrong stencil names, missing container hierarchy, and overusing generic boxes when a provider icon exists. Another common issue is mixing cloud and non-cloud scopes in the same diagram. If the first output feels too broad, ask for tighter boundaries, fewer services, or a specific pattern such as “serverless event flow” or “multi-AZ three-tier app.”

Iterate with constraints, not just edits

If the first result is close, improve it by adding constraints: “keep only the 8 core services,” “show async flows with dashed arrows,” “label public vs private subnets,” or “use AWS service names only.” This kind of cloud usage guidance is more effective than asking for “better formatting,” because it changes the underlying architecture the skill will encode.