Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add sethdford/claude-skills --skill deployment-topologygit clone --depth 1 https://github.com/sethdford/claude-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/sethdford/claude-skills/deployment-topology)<a href="https://agentmods.dev/skills/sethdford/claude-skills/deployment-topology"><img src="https://agentmods.dev/badge/skills/sethdford/claude-skills/deployment-topology/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/sethdford/claude-skills/deployment-topology"><img src="https://agentmods.dev/badge/skills/sethdford/claude-skills/deployment-topology.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00038 | $0.00638 |
| Opus 5 | $0.00019 | $0.00319 |
| Sonnet 5 | $0.00008 | $0.00128 |
| Haiku 4.5 | $0.00004 | $0.00064 |
Grade A, and why
deployment-topology scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 48 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Deployment Topology
Design deployment architectures with high availability, automatic scaling, health management, and service discovery.
Context
You are planning how services are deployed and scaled. Design topology for HA, choose orchestration platform, plan service communication, and manage state. Read current deployment practices, SLA requirements, and team operational maturity.
Domain Context
Based on container orchestration and deployment patterns:
- Container Orchestration: Kubernetes (manual control, cloud-agnostic), ECS (AWS-native), Cloud Run (serverless)
- Service Discovery: Automatic registration/deregistration; clients find healthy instances
- Load Balancing: Distribute traffic across instances; internal (mesh) and external (ingress)
- Health Checks: Liveness (restart if dead), readiness (traffic if ready), startup probes
- Rolling Updates: Gradual replacement of old instances with new; zero-downtime deployments
Instructions
-
Choose Orchestration Platform: Kubernetes for multi-cloud, complex services. ECS for AWS-only, simpler setup. Cloud Run/App Engine for stateless workloads.
-
Design Service Topology: How many replicas per service? Plan for peak load + buffer. Multi-AZ for resilience. Blue-green deployments for safe rollouts.
-
Implement Service Discovery: Kubernetes: DNS service records. ECS: load balancer targets. Clients discover healthy endpoints automatically.
-
Plan Load Balancing: External load balancer for ingress. Service mesh (Istio) for internal traffic management, circuit breaking, retries.
-
Configure Health Checks: Readiness probe: app ready to serve? Liveness probe: process alive? Startup probe: give time to initialize. Tune thresholds to avoid flaky restarts.
Anti-Patterns
- Too Many Replicas: Set replicas to 10 for small service. Result: cost, complexity, no benefit. Guard: Calculate required capacity; auto-scale based on CPU/memory, not arbitrary numbers.
- Health Checks Too Strict: Fail readiness on any non-200 response. Result: cascading failures, thrashing restarts. Guard: Design probes to be lenient on transient errors; only fail on persistent issues.
- No Graceful Shutdown: Kill processes immediately. Result: in-flight requests dropped. Guard: Drain connections; wait for graceful shutdown before kill.
- Ignoring Service Mesh Complexity: Add service mesh (Istio) for features you don't need. Result: operational overhead, debugging difficulty. Guard: Start simple; add mesh when you need advanced features (traffic splitting, security policies).
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 48 lines · 38 tokens per session scan A 984dec84e195
deployment-topology is a skill published in the GitHub repository sethdford/claude-skills (40 stars, last pushed 6mo ago), licensed MIT. It adds 38 tokens to every session and 638 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
deployment-patterns
Deployment workflows, CI/CD pipeline patterns, Docker containerization, health checks, rollback strategies, and production readiness checklists for web applications.
docker-patterns
Docker and Docker Compose patterns for local development, container security, networking, volume strategies, and multi-service orchestration.
enterprise-agent-ops
Operate long-lived agent workloads with observability, security boundaries, and lifecycle management.
deployment-patterns
Deployment workflows, CI/CD pipeline patterns, Docker containerization, health checks, rollback strategies, and production readiness checklists for web applications. Use when setting up deployment infrastructure or planning releases.
docker-patterns
Docker and Docker Compose patterns for local development, container security, networking, volume strategies, and multi-service orchestration. Use when setting up containerized development environments or reviewing Docker configurations.
gke-app-onboarding
Manages GKE application onboarding, covering containerization, deployment manifests, and migration. Use when onboarding or deploying an application to GKE for the first time, or containerizing an app for GKE. Don't use for general GKE cluster administration or upgrades (use gke-basics or gke-upgrades instead).