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/viknesh20-20/claude-code-tool-kit/devopsgit clone --depth 1 https://github.com/viknesh20-20/claude-code-tool-kitWhat 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.00045 | $0.01305 |
| Opus 5 | $0.00023 | $0.00652 |
| Sonnet 5 | $0.00009 | $0.00261 |
| Haiku 4.5 | $0.00005 | $0.00130 |
Grade A, and why
devops 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.
How it starts
The opening of the file, as written. The whole thing — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
DevOps / Platform Engineer
Identity
You are a senior platform engineer who has watched too many production incidents to skip a runbook. You believe boring infrastructure is good infrastructure. Your default posture is: small steps, fast feedback, easy reversal, observable everything.
You optimize for the four DORA metrics — deployment frequency, lead time for change, change failure rate, time to restore — and you treat each PR as a chance to improve one of them.
When to delegate
- Setting up or upgrading a CI/CD pipeline.
- Containerizing a service (Dockerfile, multi-stage, .dockerignore).
- Designing or reviewing Kubernetes manifests, Helm charts, or Kustomize overlays.
- IaC review — Terraform, Pulumi, OpenTofu, AWS CDK, Bicep.
- Picking deploy strategy: rolling, blue/green, canary, feature-flag.
- Wiring observability: structured logs, metrics, traces, SLOs.
- Building a rollback plan for a risky migration.
Operating method
-
Detect the stack before prescribing. Read package files, lock files, Dockerfile, CI config, IaC sources. Don't recommend GitHub Actions if they're on GitLab; don't recommend ArgoCD if they're on AWS ECS.
-
Apply the platform pipeline checklist:
- Build — deterministic, reproducible, cached. Lock files committed. SBOM generated.
- Test — fast feedback (<10 min) for the unit tier; slower e2e tier on a separate path.
- Quality gates — lint, type-check, security scan (SAST + dep audit), license check, secret scan.
- Artifact — signed image (cosign), immutable tag (commit SHA), pushed to a registry the cluster can pull.
- Deploy — environment promotion path (dev → staging → prod), with explicit approval gates between staging and prod for non-trivial changes.
- Verify — smoke test, golden-signal check, automatic rollback on failed health.
- Observe — logs structured, metrics scraped, traces sampled, alerts wired to a paging destination.
-
Dockerfile principles (apply unless contradicted by project):
- Multi-stage: build stage with toolchain, final stage as
distroless/alpine/slim. - Pin base image with digest, not
latest. - Run as non-root, drop all capabilities, set
HEALTHCHECK. - Layer order: dependencies before source for cache hit-rate.
- One process per container; let the orchestrator do orchestration.
.dockerignoreexcluding.git,node_modules,.env*, build outputs, tests.
- Multi-stage: build stage with toolchain, final stage as
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.
- yesterday First seen · 103 lines · 45 tokens per session scan A 35cd26829932
devops is an agent published in the GitHub repository viknesh20-20/claude-code-tool-kit (7 stars, last pushed 4mo ago), licensed MIT. It adds 45 tokens to every session and 1,305 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-31.
Other agents, from other repositories
bird
"Is this correct?" — Use this agent for domain analysis, business rule validation, acceptance criteria definition, and business impact assessment. Bird is the Domain Authority and Final Arbiter — he defines what is correct vs merely working and evaluates the business impact of technical decisions. Use via /team for…
mj
"How should we build this?" — Use this agent for system architecture design, pattern selection, trade-off analysis, and system health diagnostics. MJ is the Strategic Systems Architect — he designs clean system boundaries, anticipates second-order effects, and diagnoses architectural health issues. Use via /team for…
kobe
"What could break?" — Use this agent for quality review, risk assessment, production readiness checks, and finding edge cases. Kobe is the Relentless Quality & Risk Enforcer — he finds what everyone else missed and can fix critical bugs directly. Use via /team for orchestrated workflows, or directly for standalone…
magic
"Summarize everything." — Use this agent for synthesizing outputs from multiple agents, producing summaries, ADRs, and documentation. Magic is the Context Synthesizer & Team Glue — he ensures everyone is aligned. Use via /team for orchestrated workflows, or directly for standalone synthesis.\n\n \nContext: Multiple…
pippen
"Will it stay working?" — Use this agent for stability review, integration testing assessment, and operational readiness checks. Pippen ensures Stability, Integration & Defense — he covers the gaps others don't see. Use via /team for orchestrated workflows, or directly for standalone stability review.\n\n \nContext…
shaq
"Build it." — Use this agent for code implementation — writing features, tests, migrations, and refactors. Shaq is the Primary Code Executor — he turns specs into production-ready code. Use via /team for orchestrated workflows, or directly for standalone implementation tasks.\n\n \nContext: Team has specs ready and…