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 rules/tazwake/public/docker-buildinggit clone --depth 1 https://github.com/TazWake/PublicWhat 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.00019 | $0.00769 |
| Opus 5 | $0.00010 | $0.00385 |
| Sonnet 5 | $0.00004 | $0.00154 |
| Haiku 4.5 | $0.00002 | $0.00077 |
Grade A, and why
docker-building 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 — 46 lines — stays where its author put it; the contents beside it link to each section on GitHub.
- Apply these rules unless explicitly instructed otherwise in the chat.
- If you are unsure about the applicability of a rule, ask questions for clarity.
Docker files
Use a Minimal Base Image: Start with a lean, minimal base image like alpine, scratch, or distroless to reduce the attack surface. Smaller images contain fewer packages, fewer vulnerabilities, and are faster to download.
Run as a Non-root User: Include a USER instruction to run the application as a non-privileged user. This is a critical security practice to prevent container breakout and limit the impact of a compromised container.
Multi-stage Builds: Use multi-stage builds to create a lean final image. The first stage can include build dependencies (like compilers), while the final stage only contains the application and its runtime dependencies. This drastically reduces the image size.
Pin Image Versions: Always specify a version tag for your base image (e.g., FROM python:3.9-slim-buster) instead of using latest. This ensures reproducible builds and prevents unexpected changes.
Clean Up After Installation: Use a single RUN instruction with chained commands (&&) to install packages and immediately clean up the package manager's cache. This prevents unnecessary layers and reduces the final image size.
Copy Only What's Needed: Use a .dockerignore file to exclude unnecessary files like .git directories, README.md files, or test data. This keeps the build context small and the final image size minimal.
Avoid Sensitive Data: Never hardcode secrets, passwords, or API keys directly in the Dockerfile. Use build arguments with ARG and docker build --secret, or better yet, use a secret management system like Docker Secrets or Kubernetes Secrets at runtime.
One Process Per Container: Design your containers to run a single, primary process. This follows the UNIX philosophy and simplifies monitoring, scaling, and debugging.
Sign and Scan Images: Integrate image signing and scanning into your CI/CD pipeline. Use tools like Docker Content Trust or vulnerability scanners like Trivy or Clair to ensure the integrity and security of your images.
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 · 46 lines · 19 tokens per session scan A 1da20ee3397a
docker-building is a cursor rule published in the GitHub repository TazWake/Public (44 stars, last pushed 12d ago), licensed CC0-1.0. It adds 19 tokens to every session and 769 once invoked, about $0.0001 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-30.
Other cursor rules, from other repositories
project-overview
Project overview and architecture reference.
bundling
The project uses a custom type bundling system to provide full TypeScript IntelliSense support in the Monaco editor for @bubblelab/bubble-core and its dependencies. This is necessary because Monaco cannot directly resolve workspace packages or external dependencies.
case-uco-sdk
CASE/UCO SDK usage patterns for building digital forensics investigation graphs.
extension-authoring
Guidance for authoring CASE/UCO extension ontologies per the CDO Community Playground Guide.
api
For creating tests for the backend in bubblelab-api.
commit
Check commit styling guide at @COMMIT.md at / folder to see best styling practice for git commit messages.