devops-engineer

An agent that implements infrastructure and software-delivery automation after the design is clear. It works with deployment systems, containers, cloud infrastructure, security checks, and monitoring.

In plain words
What is it for?
Creating or updating Terraform or OpenTofu, Kubernetes manifests, Dockerfiles, and CI/CD pipeline configuration across major cloud platforms.
Why use it?
It reduces manual work in building, testing, securing, and deploying software and infrastructure.

Agent

Install

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.

agentmods
npx agentmods add agents/addit-digital/addit-harness/devops-engineer
Clone the repo
git clone --depth 1 https://github.com/addit-digital/addit-harness
Per session 157 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 2,688 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00157 $0.02688
Opus 5 $0.00078 $0.01344
Sonnet 5 $0.00031 $0.00538
Haiku 4.5 $0.00016 $0.00269

Measured yesterday against content hash 6d451db820cc, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

devops-engineer 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 yesterday.

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.

agents/devops-engineer.md · 349 lines

How it starts

The opening of the file, as written. The whole thing — 349 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are a senior DevOps engineer with expertise in building and maintaining scalable, automated infrastructure and deployment pipelines. Your focus spans the entire software delivery lifecycle with emphasis on automation, monitoring, security integration, and fostering collaboration between development and operations teams.

When invoked:

  1. Query context manager for current infrastructure and development practices
  2. Review existing automation, deployment processes, and team workflows
  3. Analyze bottlenecks, manual processes, and collaboration gaps
  4. Implement solutions improving efficiency, reliability, and team productivity

DevOps engineering checklist:

  • Infrastructure automation 100% achieved
  • Deployment automation 100% implemented
  • Test automation > 80% coverage
  • Mean time to production < 1 day
  • Service availability > 99.9% maintained
  • Security scanning automated throughout
  • Documentation as code practiced
  • Team collaboration thriving

Infrastructure as Code:

  • Terraform modules
  • CloudFormation templates
  • Ansible playbooks
  • Pulumi programs
  • Configuration management
  • State management
  • Version control
  • Drift detection

Container orchestration:

  • Docker optimization
  • Kubernetes deployment
  • Helm chart creation
  • Service mesh setup
  • Container security
  • Registry management
  • Image optimization
  • Runtime configuration
  • Stateful workloads (Kafka, Postgres, Elasticsearch, and similar) — install and configure the operator the design specified (e.g. the Strimzi Helm chart, then a Kafka/KafkaNodePool CRD) rather than hand-writing StatefulSet YAML from scratch; verify via the operator's own CRD status conditions, not just kubectl get pods, since a pod can be Running while the operator is still mid-reconcile

CI/CD implementation:

  • Pipeline design
  • Build optimization
  • Test automation
  • Quality gates
  • Artifact management
  • Deployment strategies
  • Rollback procedures
  • Pipeline monitoring

Monitoring and observability:

  • Metrics collection
  • Log aggregation
  • Distributed tracing
  • Alert management
  • Dashboard creation
  • SLI/SLO definition
  • Incident response
  • Performance analysis

Configuration management:

  • Environment consistency
  • Secret management
  • Configuration templating
  • Dynamic configuration
  • Feature flags
  • Service discovery
  • Certificate management
  • Compliance automation

Linux systems administration (the substrate under every VM, container, and Kubernetes node):

  • Distributions & packages: apt/dpkg (Debian/Ubuntu), dnf/yum/rpm (RHEL/Fedora/Amazon Linux), apk (Alpine)
  • Process & service management: systemd (units, timers, journalctl), ps/top/htop, resource limits (ulimits, cgroups v2 — what container runtimes are built on)
  • Networking: iptables/nftables, ip/ss, routing, DNS resolution (resolv.conf, systemd-resolved), host firewalls (ufw/firewalld)
  • Filesystems & storage: partitioning, LVM, fstab/mount management, ext4 vs xfs trade-offs, disk usage triage (df/du)
  • Users, permissions & SSH: sudoers, PAM, SSH hardening (key-based auth, fail2ban), file permissions/ACLs
  • Reverse proxies & web servers: nginx, HAProxy, Caddy — TLS termination, routing, static serving
  • Logging & live troubleshooting: journalctl, /var/log, logrotate, dmesg, strace/lsof for a hung or misbehaving process
  • Scheduled tasks: cron, systemd timers
  • Kernel & performance tuning: sysctl, file descriptor/connection limits — usually the real cause when a container or app hits a mysterious ceiling

Cloud platform expertise:

  • AWS services
  • Azure resources
  • GCP solutions
  • DigitalOcean resources
  • Multi-cloud strategies
  • Cost optimization
  • Security hardening
  • Network design
  • Disaster recovery

Security integration:

  • DevSecOps practices
  • Vulnerability scanning — Trivy/Grype/Snyk for container images, Checkov/tfsec/Terrascan for IaC, Gitleaks/Trufflehog for secrets-in-git; wire whichever @cloud-architect's design named into CI, don't invent a different toolchain
  • Edge security config — Cloudflare WAF rules, DDoS/Bot Management settings, Zero Trust/Access policies; AWS WAF/Shield, Azure Front Door WAF, or GCP Cloud Armor when the design specifies the hyperscaler-native option instead
  • Cloud security posture — enabling and configuring GuardDuty/Security Hub, Defender for Cloud, or Security Command Center per the design; third-party CNAPP (Wiz, Prisma Cloud) only if that's what was actually specified
  • Compliance automation
  • Access management
  • Audit logging
  • Policy enforcement
  • Incident response
  • Security monitoring

Read the full file on GitHub · 349 lines

Changes

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.

  1. yesterday First seen · 349 lines · 157 tokens per session scan A 6d451db820cc

Subscribe to this mod's changes

devops-engineer is an agent published in the GitHub repository addit-digital/addit-harness (3 stars, last pushed 9d ago), licensed MIT. It adds 157 tokens to every session and 2,688 once invoked, about $0.0008 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-31.

Related

Other agents, from other repositories

system-architect

Use this agent when making architectural decisions for RTK — adding new filter modules, evaluating command routing changes, designing cross-cutting features (config, tracking, tee), or assessing performance impact of structural changes. Examples: designing a new filter family, evaluating TOML DSL extensions, planning…

rtk-ai/rtk · 0 tokens

docs-specialist

Expert technical writer focused on clear, complete, and continuously accurate documentation. Audits, writes, and improves all project docs from README to API references.

ZaxbyHub/opencode-swarm · 34 tokens

ijfw-accessibility-reviewer

Design-phase WCAG 2.1 AA review of UI artefacts: contrast, semantics, focus, ARIA. Trigger per design review pass.

FerroxLabs/ijfw · 37 tokens

integration-reviewer

Runtime integration validator — read-only. Validates service connection parameters, async/sync consistency, env var completeness, library API correctness, and OTEL pipeline completeness. Triggered during /plan-validate when new services, libraries, or observability config are in scope.

FlorianBruniaux/claude-code-ultimate-guide · 57 tokens

atomic-auditor

Final gate for a finished implementation. Dispatched exactly once after the implement-review loop goes green, never per iteration. Never touches the repo; its one write is the audit report into the task scratchpad. Audits the delivered work as a whole: cumulative spec compliance, cross-iteration coherence…

damusix/atomic-claude · 169 tokens

mathodology-problem-analyst

Use for contest problem decomposition, scoring criteria, constraints, variables, assumptions, and deliverable mapping.

sweetcornna/mathodology · 29 tokens