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 sairam0424/MindForge --skill s6-container-supervisiongit clone --depth 1 https://github.com/sairam0424/MindForgeWrote 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/sairam0424/mindforge/s6-container-supervision)<a href="https://agentmods.dev/skills/sairam0424/mindforge/s6-container-supervision"><img src="https://agentmods.dev/badge/skills/sairam0424/mindforge/s6-container-supervision/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/sairam0424/mindforge/s6-container-supervision"><img src="https://agentmods.dev/badge/skills/sairam0424/mindforge/s6-container-supervision.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.00020 | $0.02871 |
| Opus 5 | $0.00010 | $0.01435 |
| Sonnet 5 | $0.00004 | $0.00574 |
| Haiku 4.5 | $0.00002 | $0.00287 |
Grade A, and why
s6-container-supervision 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 6d 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.
This is a copy
91% identical to hermes-s6-container-supervision — 30 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 172 lines — stays where its author put it; the contents beside it link to each section on GitHub.
the agent s6-overlay Container Supervision
When to use this skill
Load this skill when you're working on:
- Adding or removing a static service in the the agent Docker image (something that should be supervised at every container start, like the dashboard)
- Diagnosing why a per-profile gateway isn't starting, restarting, or surviving
docker restart - Understanding why the container's CMD is
/opt/hermes/docker/main-wrapper.shand how leading-dash args reach the user's program - Modifying
cont-init.dboot scripts (UID remap, volume seeding, profile reconciliation) - Changing the rendered run-script for per-profile gateways (Phase 4)
If you're just running the
Architecture at a glance
/init ← PID 1 (s6-overlay v3.2.3.0)
├── cont-init.d ← oneshot setup, runs as root
│ ├── 01-hermes-setup ← docker/stage2-hook.sh
│ │ ├── UID/GID remap
│ │ ├── chown /opt/data
│ │ ├── chown /opt/data/profiles (every boot)
│ │ ├── seed .env / config.yaml / SOUL.md
│ │ └── skills_sync.py
│ └── 02-reconcile-profiles ← hermes_cli.container_boot
│ ├── chown /run/service (hermes-writable for runtime register)
│ └── walk $HERMES_HOME/profiles/<name>/gateway_state.json
│ → recreate /run/service/gateway-<name>/
│ → auto-start only those with prior_state == "running"
│
├── s6-rc.d (static services, in /etc/s6-overlay/s6-rc.d/)
│ ├── main-hermes/run ← exec sleep infinity (no-op slot)
│ └── dashboard/run ← if HERMES_DASHBOARD=1, runs `hermes dashboard`
│
├── /run/service (s6-svscan watches; tmpfs)
│ ├── gateway-coder/ ← runtime-registered per-profile
│ │ ├── type ("longrun")
│ │ ├── run ("#!/command/with-contenv sh ... exec s6-setuidgid hermes hermes -p coder gateway run")
│ │ ├── down (marker — present means "registered but don't auto-start")
│ │ └── log/run (s6-log → $HERMES_HOME/logs/gateways/coder/current)
│ └── ...
│
└── CMD ("main program") ← /opt/hermes/docker/main-wrapper.sh
└── routes user args: bare exec | hermes subcommand | hermes (no args)
— exec'd by /init with stdin/stdout/stderr inherited (TTY for --tui)
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.
- 6d ago First seen · 172 lines · 20 tokens per session scan A 36ea28e91f08
s6-container-supervision is a skill published in the GitHub repository sairam0424/MindForge (0 stars, last pushed today), licensed MIT. It adds 20 tokens to every session and 2,871 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 91% identical to hermes-s6-container-supervision, differing in 30 lines, and is treated as a copy.
Other skills, from other repositories
odoo-docker-deployment
Production-ready Docker and docker-compose setup for Odoo with PostgreSQL, persistent volumes, environment-based configuration, and Nginx reverse proxy.
container-docker-ops
Canonical container workflows: Docker/Compose development plus MCP-style container management patterns.
docker-image-hardening
Use when you need to review or author a Dockerfile for multi-stage builds, minimal or distroless base images, non-root runtime, layer caching, .dockerignore hygiene, pinned digests, image vulnerability scanning, and SBOM generation.
multi-stage-dockerfile
Create optimized multi-stage Dockerfiles for any language or framework.
apify-actorization
Actorization converts existing software into reusable serverless applications compatible with the Apify platform. Actors are programs packaged as Docker images that accept well-defined JSON input, perform an action, and optionally produce structured JSON output.
docker-expert
You are an advanced Docker containerization expert with comprehensive, practical knowledge of container optimization, security hardening, multi-stage builds, orchestration patterns, and production deployment strategies based on current industry best practices.