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 atretyak1985/swarmery --skill docker-buildgit clone --depth 1 https://github.com/atretyak1985/swarmeryWrote 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/atretyak1985/swarmery/docker-build)<a href="https://agentmods.dev/skills/atretyak1985/swarmery/docker-build"><img src="https://agentmods.dev/badge/skills/atretyak1985/swarmery/docker-build/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/atretyak1985/swarmery/docker-build"><img src="https://agentmods.dev/badge/skills/atretyak1985/swarmery/docker-build.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.00054 | $0.00774 |
| Opus 5.5 | $0.00022 | $0.00310 |
| Sonnet 5.5 | $0.00011 | $0.00155 |
| Haiku 4.5 | $0.00005 | $0.00077 |
Grade A, and why
docker-build 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 1mo 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 — 64 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
Build and push Docker images for the project's services to the cloud container registry (.claude/project.json → cloud.provider): multi-arch builds (ARM64 edge, AMD64 web), tagging conventions, registry authentication. Image creation only — rollout belongs to the project's infra pack skills. Placeholders <mainApp> and <device> come from project.json.
Rules (never violate)
- Never pass
NEXT_PUBLIC_*as--build-arg— client config comes through thewindow.__ENV__runtime bridge (12-factor). - Registry URLs use
$IMAGE_REGISTRY— never a hardcoded cloud project ID. - Tags are a git short hash (dev) or semver (release) — never
latest; flag base images pinned to:latest. - A push writes to the shared registry immediately and irreversibly — confirm tag and target first; never push to production from a local machine (CI only).
- Stop and ask when tests have not passed for the code being built, or on a platform mismatch.
- Verify every push via the registry describe command; attach a confidence label (LOW if unverified).
Resources
- Read
resources/build-procedure.mdwhen building — the procedure with commands, per-service build parameters, output template, and self-check. - Read
resources/troubleshooting-and-examples.mdwhen diagnosing — DO-NOT patterns, escalation conditions, two full examples, failure modes.
How to use
What it does
Builds Docker images for your services and, when asked, pushes them to your cloud container registry. It handles what is easy to get wrong: multi-architecture builds through buildx, tag conventions, registry authentication, and the 12-factor rule keeping client config out of the image. It produces the image; rollout is somebody else's job.
When to use it
- An image for the main app or a device/edge service, built from the current commit.
- A built image pushed to the registry and verified by digest.
- Setting up buildx for ARM64 edge builds, or diagnosing a build failure.
Not for rollouts or config templates (the project's infra pack skills), Dockerfile review without a build (code-quality), or production pushes from a local machine (escalate).
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 1mo ago First seen · 64 lines · 54 tokens per session scan A 33d5b0546640
docker-build is a skill published in the GitHub repository atretyak1985/swarmery (7 stars, last pushed 2d ago), licensed Apache-2.0. It adds 54 tokens to every session and 774 once invoked, about $0.0002 per session on Opus 5.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-09-03.
Other skills, from other repositories
k8s-sidecar-testing
Test the nat464-sidecar demo topology in a selected Kubernetes test namespace, verify IPv6 translation paths, and compare HTTP latency. Includes optional disposable Multipass/k3s setup.
deploy-docker-compose
Run the Omnigent server as a Docker compose stack (server + Postgres) on any Docker host — your laptop, a VPS, EC2 by hand, or as the base layer of any container-platform deploy. Invoke when the user wants to build the image, bring up the compose stack, debug the stack on a host they already have, or extend the stack…
azure-prepare
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd…
aks-troubleshooting
Debug live Azure Kubernetes Service (AKS) incidents with a read-only, evidence-first investigation. WHEN: pod crashes or Pending, CrashLoopBackOff, OOMKilled, ImagePullBackOff, node NotReady, DNS or ingress failure, connectivity timeout, network policy, SNAT exhaustion, node-pool scaling blocked by QuotaExceeded or…
aks-gpu-inference
Diagnose Day-2 AKS GPU and KAITO incidents using profile-aware, read-only evidence. WHEN: 'Insufficient nvidia.com/gpu', GPU pod Pending, model-load OOM, DCGM/VRAM, KAITO Workspace not ready, or GPU autoscaling. DO NOT USE FOR: setup (airunway-aks-setup), non-GPU incidents (aks-troubleshooting), standalone VM quota…
aks-network-capture
Collects bounded packet captures from AKS nodes and Azure network configuration for wire-level evidence. WHEN: "capture packets on an AKS node", "take a pcap", "run tcpdump on AKS", "prove where packets drop". Use for explicit packet-capture intent after read-only diagnostics, not general AKS connectivity or ingress…