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 anatolykoptev/dozor --skill maintenancegit clone --depth 1 https://github.com/anatolykoptev/dozorWrote 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/anatolykoptev/dozor/maintenance)<a href="https://agentmods.dev/skills/anatolykoptev/dozor/maintenance"><img src="https://agentmods.dev/badge/skills/anatolykoptev/dozor/maintenance/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/anatolykoptev/dozor/maintenance"><img src="https://agentmods.dev/badge/skills/anatolykoptev/dozor/maintenance.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.00048 | $0.00749 |
| Opus 5 | $0.00024 | $0.00375 |
| Sonnet 5 | $0.00010 | $0.00150 |
| Haiku 4.5 | $0.00005 | $0.00075 |
Grade A, and why
maintenance 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 9d 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 — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Maintenance
Proactive resource management to prevent incidents.
Disk Management
Thresholds
| Usage | Status | Action |
|---|---|---|
| < 60% | Healthy | No action needed |
| 60-80% | Watch | Report in next status check |
| 80-90% | Warning | Run targeted cleanup |
| 90-95% | Critical | Immediate cleanup, escalate if insufficient |
| > 95% | Emergency | Aggressive cleanup + escalate |
Cleanup Priority (safest first)
-
Journal logs —
server_cleanup(targets: ["journal"], report: false, min_age: "3d")- Typically frees 200MB-2GB
- Zero risk
-
Temp files —
server_cleanup(targets: ["tmp"], report: false, min_age: "7d")- Frees build artifacts, old downloads
- Low risk
-
Docker build cache —
server_prune(build_cache: true, images: false, age: "48h")- Frees 1-10GB typically
- Safe: only removes unused cache layers
-
Docker images —
server_prune(images: true, age: "48h")- Frees dangling/unused images
- Safe: only removes images not used by any container
-
Package caches —
server_cleanup(targets: ["go", "npm", "pip", "uv"], report: false)- Frees build caches for various package managers
- Moderate risk: may slow next build
-
Docker volumes —
server_prune(volumes: true)- DANGEROUS: may delete persistent data
- Only with user approval
Always Scan First
Before any cleanup, run dry-run:
server_cleanup(targets: ["all"], report: true)
This shows reclaimable sizes without deleting anything.
Docker Maintenance
Regular Pruning (weekly)
server_prune(images: true, build_cache: true, age: "48h")
After Failed Deploys
server_prune(build_cache: true, images: true, age: "1h")
Failed builds leave large intermediate layers.
Container Log Growth
Docker container logs can grow unbounded. Check with:
server_inspect(mode: "overview")
System Resource Monitoring
Memory Pressure
If memory > 90%:
server_inspect(mode: "overview")to identify top consumers- Check for container memory leaks: is any container using 2x+ its normal?
- Restart the leaky container
- If no obvious leak: report to user
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.
- 9d ago First seen · 95 lines · 48 tokens per session scan A e40c4ad3fb8c
maintenance is a skill published in the GitHub repository anatolykoptev/dozor (5 stars, last pushed today), licensed MIT. It adds 48 tokens to every session and 749 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 skills, from other repositories
harbor
CLI toolkit for managing containerized LLM services. Use when the user wants to start, stop, configure, or manage AI/LLM services like Ollama, Open WebUI, llama.cpp, vLLM, LiteLLM, ComfyUI, and 250+ others. Triggers on requests to "run a model", "start ollama", "set up an LLM", "configure harbor", "manage services"…
devops-deployment
Use when setting up CI/CD pipelines, containerizing applications, deploying to Kubernetes, or writing infrastructure as code. DevOps & Deployment covers GitHub Actions, Docker, Helm, and Terraform patterns.
项目任务流程
A process guide for creating and managing container tasks: larger, ongoing jobs such as building an app, game, or novel. It covers task planning, workspaces, progress checks, task chains, resources, failures, and completion.
bunjs-production
Use when deploying Bun.js to production, containerizing with Docker, setting up AWS ECS/Fargate, implementing Redis caching, hardening security, or configuring CI/CD pipelines. See bunjs for basics, bunjs-architecture for patterns.
docker-best-practices
A guide to writing Dockerfiles and building containers, which package an application with what it needs to run. It covers smaller images, faster rebuilds, fixed base versions, safer users, and keeping secrets out.
环境配置决策
A decision guide for installing and configuring development dependencies. It explains when a tool belongs in a shared container image and when it belongs only in a project's workspace, including whether Docker access is available.