Sidecar proxy visualization pattern
Skill kjuhwa/skills-hub/skills/design/sidecar-proxy-visualization-pattern
Self-correcting knowledge corpus for Claude Code — 9 stable shape clusters, bias-correction pipeline baked into contribution flow. 47 papers, 45 techniques, 1.1k skills.
npx -y skills add kjuhwa/skills-hub --skill sidecar-proxy-visualization-patternAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Visualize sidecar proxy topology as paired app+proxy nodes with intercepted traffic flows and policy overlays.
SKILL.md
1.9 KB, 337 tokens by cl100k_base, as published. Nobody here has run it
sidecar-proxy-visualization-pattern
Render each workload as a two-part unit: a primary application container and its co-located sidecar proxy, drawn as nested or tightly-grouped nodes inside a shared pod boundary (dashed outline). Traffic arrows must always enter and exit through the sidecar, never the app directly — this visually enforces the "transparent interception" invariant. Use distinct stroke styles for inbound vs outbound legs (e.g., solid for ingress, dashed for egress) and color-code by protocol (HTTP/gRPC/TCP) so mTLS upgrades and protocol sniffing decisions are legible at a glance.
Overlay cross-cutting concerns as toggleable layers rather than baking them into the base topology: mTLS handshake indicators on edges, retry/timeout badges on proxy nodes, circuit-breaker state (closed/open/half-open) as node fill color, and rate-limit token buckets as small gauges. For the control plane (xDS/Envoy-style), draw it as a separate pane pushing config down to all sidecars via dotted lines — this makes the "config distribution" vs "data plane traffic" distinction obvious and mirrors the Istio/Linkerd mental model users already carry.
Interactive affordances should let users click a sidecar to see its inbound/outbound listener chain, filter chains, and cluster assignments in a side panel. Animate individual requests as pulses traveling app→sidecar→network→remote sidecar→remote app, pausing briefly at each hop so viewers can observe where latency, policy checks, and telemetry emission actually happen. This hop-by-hop animation is the single most effective way to teach why the sidecar pattern exists.