docker-python
Skill1 starsChanged 53 days agoMITView on GitHub
Dockerfile best practices for Python projects. Covers non-root user (ARG UID/GID/APP_USER), COPY --chown, runtime-writable files, and entrypoint diagnostics.
- Reads credentials
- Installs packages
1 other project uses a version of this.
Adopted by
Most recently taken up by
- ai-enhanced-engineer/aiee-skillstheir own version, first seen Nov 1, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- ai-enhanced-engineer/aiee-skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository28 other files it gives its agents.
- journal-coachSkill
- github-templatesSkill
- node-ciSkill
- renovateSkill
- create-readmeSkill
- markdown-styleSkill
- mermaid-syntaxSkill
- obsidian-vaultSkill
- ste100Skill
- forge-detectSkill
- forgejo-issueSkill
- forgejo-prSkill
- web-frontendSkill
- pyproject-tomlSkill
- python-ciSkill
- python-cliSkill
- python-devcontainerSkill
- python-projectSkill
- architecture-briefSkill
- design-advisorSkill
- saas-anti-pattern-reviewSkill
- saas-transition-chain-reviewSkill
- saas-transition-reviewSkill
- saas-transition-strategySkill
- security-reviewerSkill
- technical-debt-reviewSkill
- commit-messageSkill
- discord-sendSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 5 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 9
Read assets/Dockerfile.tmpl, replace appname, and write it to the project root.
- Very specific: line 51
NPM dependencies: use npm ci --ignore-scripts in Dockerfile stages to block postinstall attacks.
- Distinctive: line 63
When setting up Docker for a project, offer to create a GHCR publish workflow.
- Distinctive: line 67
Ask the user: *"Will this project be hosted on GitHub?"* If no, skip this section.
- Very specific: line 68
Read config.toml from this directory.
- Very specific: line 69
Ask the user for the GitHub owner (default: <github_owner from config>)
- Distinctive: line 70
Ask the user for the URL base for badge links:
- Very specific: line 74
Ask the user for the repo name (read from pyproject.toml [project].name if it's a Python project.
- Very specific: line 76
Read assets/ghcr.yml.tmpl, then write it to .github/workflows/ghcr.yml (no substitutions needed).
- Distinctive: line 78
Add the following badge to README.md:
- Distinctive: line 84
Create the directory before writing:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Dockerfile
Read assets/Dockerfile.tmpl, replace appname, and write it to the project root.
Key patterns:
- uv image pinned to
tag@sha256:digest— guarantees the exact uv version; update the digest when a new stable release has been available for > 30 days ARG UID=1000 GID=1000 APP_USER=appuser— configurable at build time via--build-arg UID=568- Privileged RUN (package installs, user creation, app directory) happens before
USER COPY --chown=${UID}:${GID}sets ownership at build time — no runtimechownneeded/appis pre-created and chowned before any copy so the working directory is writable- Runtime-writable config files (e.g.
config.js) should be pre-created withchmod 666sodocker-compose user:overrides still work USER ${APP_USER}is the last step beforeENTRYPOINT
Bind mounts
For host bind mounts in docker-compose, users must chown the host directory to the container UID:
sudo chown -R 1000:1000 /host/pathTo use a custom UID, add user: "<UID>:<GID>" in docker-compose and ensure runtime-writable files have chmod 666 set at build time.
.dockerignore
.git/
__pycache__/
*.pyc
.venv/
.env
dist/
*.egg-info/
.mypy_cache/
.pytest_cache/
.coverageDependency pinning
- Docker images: pin all
FROMlines totag@sha256:digest. Tags are mutable; digests guarantee the exact image.FROM python:3.13.12-slim@sha256:f1927c75e81efd1e091dbd64b6c0ecaa5630b38635a3d1c04034ac636e1f94c8 AS builder - NPM dependencies: use
npm ci --ignore-scriptsin Dockerfile stages to block postinstall attacks.RUN npm ci --prefer-offline --ignore-scripts - Python dependencies: export from lockfile with
uv exportand install withpip install --require-hashesto verify every package hash.RUN uv export --no-dev --no-emit-project -o requirements.txt RUN pip install --no-cache --require-hashes -r ./requirements.txt
GitHub Actions workflow
When setting up Docker for a project, offer to create a GHCR publish workflow. Ask the user: "Do you want to set up a GitHub Actions workflow to build and push this image to GHCR?"
If yes:
- Ask the user: "Will this project be hosted on GitHub?" If no, skip this section.
- Read
config.tomlfrom this directory. If it exists, extractgithub_ownerandgithub_url_basefor defaults. If not, ask the user for these values and write them toconfig.toml(one-time setup). - Ask the user for the GitHub owner (default:
<github_owner from config>) - Ask the user for the URL base for badge links:
go.<owner>.com/gh(default, e.g.https://<github_url_base from config>)github.com/<owner>(e.g.https://github.com/<github_owner from config>)- Custom — user provides their own
- Ask the user for the repo name (read from
pyproject.toml[project].nameif it's a Python project; otherwise ask directly)
Read assets/ghcr.yml.tmpl, then write it to .github/workflows/ghcr.yml (no substitutions needed).
Add the following badge to README.md:
[](<base>/<repo>/packages)Create the directory before writing:
mkdir -p .github/workflowsDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

