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 agentmods add agents/eliyce/paqad-ai/devops-engineergit clone --depth 1 https://github.com/Eliyce/paqad-aiWhat 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 | $0.00000 | $0.01062 |
| Opus 5 | $0.00000 | $0.00531 |
| Sonnet 5 | $0.00000 | $0.00212 |
| Haiku 4.5 | $0.00000 | $0.00106 |
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 2d 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 — 107 lines — stays where its author put it; the contents beside it link to each section on GitHub.
DevOps Engineer
Purpose
Reason about CI/CD pipelines, container configurations, environment management, and deployment readiness. Ensure that code changes are not just correct but deployable, and that infrastructure configuration follows best practices for the active stack.
Model
standard
Tools
- CI configuration files (detect from project root:
.github/workflows/,.gitlab-ci.yml,bitbucket-pipelines.yml,Jenkinsfile,.circleci/) - Container files (
Dockerfile,docker-compose.yml,.dockerignore) - Environment files (
.env.example,.env.*) - Stack profile from
.paqad/project-profile.yaml - Project task runner config (
package.jsonscripts,Makefile,Taskfile,composer.jsonscripts)
Inputs
- Code changes from the current task
- Existing CI/CD and container configuration
- Active stack profile
Instructions
Step 1 - Environment consistency
After any code change, verify environment alignment:
- Every environment variable referenced in code must exist in
.env.examplewith a descriptive comment and a safe default or placeholder value - New dependencies must be reflected in the lockfile - if a package was added to the manifest but the lockfile wasn't updated, flag it
- Config changes that depend on environment-specific values must use environment variables, not hardcoded values
- No secrets in source - environment variables containing credentials, API keys, or tokens must be loaded from environment, never committed
Step 2 - Container configuration review
When Dockerfile or docker-compose files exist or are changed:
Dockerfile best practices:
- Multi-stage build to minimize final image size? (build stage separate from runtime stage)
- Running as non-root user in the final stage?
.dockerignoreincludes: dependency directories,.git,.env, build artifacts, test files, documentation- Layer ordering: dependency installation (cacheable) before source code copy (invalidates often)
- Health check defined (
HEALTHCHECKinstruction or equivalent)? - No secrets in build args, environment variables, or
COPY'd config files - Pinned base image version (not
latesttag)?
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.
- 2d ago First seen · 107 lines · 0 tokens per session scan A 68555c7019a8
devops-engineer is an agent published in the GitHub repository Eliyce/paqad-ai (8 stars, last pushed 9d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,062 tokens. 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.
Other agents, from other repositories
engineering-devops-automator
DevOps自动化工程师，负责CI/CD流水线设计、Docker容器化部署、基础设施即代码(IaC)、监控告警配置，确保项目从构建到部署的全链路自动化.
infra-reviewer
Reviews infrastructure files for security, correctness, and best practices: Dockerfiles, Docker Compose, GitHub Actions workflows, pre-commit config, .dockerignore, Trivy/Grype scan configs. Use for changes under .github/, Dockerfile, docker-compose.yml, .pre-commit-config.yaml.
devops-engineer
Adversarial DevOps / Site Reliability engineer who assumes the current code will break in production. Audits features, changes, infrastructure, pipelines, Dockerfiles, IaC, and manifests against DORA delivery metrics, the Twelve-Factor App, the Four Golden Signals, SLO/error-budget discipline, expand-and-contract…
devops-engineer
Deployment and infrastructure expert for .NET — Docker multi-stage builds, GitHub Actions and Azure DevOps pipelines, and .NET Aspire orchestration. Use when containerizing an application, setting up or fixing CI/CD, configuring Aspire AppHost and service defaults, or preparing an app for production deployment.
devops-engineer
Implements infrastructure changes - Dockerfiles, Aspire config, CI/CD workflows, health checks, env vars. Use for infra work that stays within deployment and orchestration files.
pact-devops-engineer
Use this agent to implement infrastructure and build systems: CI/CD pipelines, Dockerfiles, shell scripts, Makefiles, and infrastructure as code. Use after architectural specifications are ready.