Adding Animated Traffic Flows to Draw.io Diagrams with GitHub Copilot Agent Skills

I have added optional animated traffic flows to my Draw.io diagram skill.

The rule is simple: only animate a connector when the movement helps explain the design. Most diagrams should stay static.

For normal architecture diagrams, static connectors are usually the right choice. If the diagram is showing platform layout, ownership boundaries, service dependencies, or environment structure, animation rarely adds much. It often makes the diagram busier.

Where animation helps is when the diagram is trying to explain a path.

Take a typical Azure web application diagram with Front Door and WAF, App Service, PostgreSQL, private endpoints, DNS, Application Insights, Log Analytics, and Azure Monitor. A static version can show the components and relationships clearly enough, but it can still be hard to see which connectors are part of the HTTPS request path and which ones are there for telemetry, DNS, or supporting services.

Labels can help, but they have a limit. Too many labels make the diagram harder to scan. For traffic paths, animating the specific route you want someone to follow can be cleaner.

Keeping animation optional

The behaviour I wanted to avoid was Copilot seeing “animated traffic” and applying animation to every arrow.

In the example below, the skill identifies two possible traffic flows:

• Internet → Front Door + WAF
• Front Door + WAF → App Service

Rather than animating every connector, GitHub Copilot asks which arrows should be animated.

That is the behaviour I want from the skill. Architecture diagrams often contain a lot of valid relationships, but only a few are relevant to the explanation. If every connector moves, the reader has to work harder to understand the diagram.

Putting this guidance into the skill makes the behaviour more repeatable than relying on a one-off prompt. The agent has a small set of rules before it changes the diagram: animate the path being discussed, keep supporting relationships static, and do not turn the diagram into a visual effect.

Azure Example

In the Azure three-tier example, only the selected traffic arrows are animated.

The rest of the diagram remains static. Front Door and WAF, App Service, PostgreSQL, private endpoints, DNS, observability, and supporting Azure services are still shown, but they are not competing with the request path.

The animation is there to guide the eye through the flow, not to make the whole architecture move.

AWS Example

The same pattern applies to the AWS example.

The diagram includes Route 53, CloudFront and WAF, an Internet Gateway, an ALB, ECS Fargate services across multiple availability zones, NAT Gateways, RDS PostgreSQL, S3, Secrets Manager, and Certificate Manager.

There are several relationships in a diagram like this: ingress, egress, data access, and managed service dependencies. Animating all of them would be the wrong default. The useful behaviour is being selective about the path being explained and leaving the rest of the design readable.

Where this helps

I would use animated flows where direction or order matters, especially for ingress and egress paths, authentication flows, CI/CD deployment flows, service-to-service communication, private connectivity, or blocked traffic.

Blocked traffic is a good example. A red cross on a connector can show that traffic is denied, but it does not always make the stopping point obvious. Showing the attempted path can make the control point easier to see.

Ingress is similar. A static diagram can show the edge, gateway, application tier, and backend services. An animated path can show how the request moves through them.

Why put this in a skill?

You can do this with a direct prompt. Asking Copilot to make selected arrows animated will probably work.

I still prefer this as a skill because the behaviour becomes repeatable. The skill carries the judgement about when animation helps and when it should be left out.

The guidance is intentionally small:

• animate the flow being explained
• keep supporting relationships static
• do not animate every connector
• prefer clarity over effect

That is the kind of value I want from agent skills. They should capture small pieces of engineering judgement, not turn every task into a framework. The output still needs review, but the starting point is better because the expected behaviour is written down.

Final thoughts

Animation is useful when the diagram is about flow. It is not useful when the diagram is about layout.

For most architecture diagrams, static should remain the default. When the question is “what route does this take?”, a small amount of movement can be clearer than another label.

Used carefully, animation helps explain the design. Used everywhere, it becomes something the reader has to ignore.

You can try the skill here:

https://github.com/thomast1906/github-copilot-agent-skills/tree/main/.github/skills/azure-drawio-mcp-diagramming