From claude-resources
Container registry push discipline. Use when pushing a built image to a registry (ECR, GCR, GHCR, Docker Hub), tagging an image for a release or deployment, signing images for supply-chain verification (Cosign, Notary), authenticating to a registry, or choosing between immutable (v1.2.3, sha-abc123) and mutable (latest, canary, stable) tag strategies. Trigger on `docker push`, `crane`, registry-auth errors, tag rollouts, image-signing questions, or any task that produces an image destined for a remote registry. Part of the opt-in `ops-skills` plugin — requires `ops_enabled=true` in session context; if disabled, report the intended push as a follow-up with the proposed tag. Pair with core/docker for local image build discipline.
npx claudepluginhub deandum/claude-resources --plugin go-skillsThis skill uses the workspace's default tool permissions.
Pushing an image is publication. Downstream consumers — deployments, CI, other services — pull your images by tag. A bad push can poison production, a missing tag can strand a rollback, a mutable `latest` can make a bug irreproducible. This skill covers the discipline. For local build discipline (multi-stage, non-root, layer caching), see `core/docker`.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides agent creation for Claude Code plugins with file templates, frontmatter specs (name, description, model), triggering examples, system prompts, and best practices.
Pushing an image is publication. Downstream consumers — deployments, CI, other services — pull your images by tag. A bad push can poison production, a missing tag can strand a rollback, a mutable latest can make a bug irreproducible. This skill covers the discipline. For local build discipline (multi-stage, non-root, layer caching), see core/docker.
ops_enabled=false — do not push, report the intended push as a follow-upcore/dockerA push is the end of the build pipeline, not the start. Before docker push:
docker build exits 0)docker run ... then hit /healthz)If any of these fail, do not push — fix the build first. Common size-related causes: dev dependencies not excluded from the runtime stage, wrong base image (alpine/debian when distroless would do), unnecessary intermediate layers copied across stages. Common scan failures: outdated base image with known CVEs — rebuild with a patched base before pushing.
Immutable tags (required). Immutable tags — version (myservice:v1.2.3), commit SHA (myservice:sha-abc123def), or build ID — are your default. Once pushed, they refer to that exact image forever. Production deployments pull by immutable tag. Downstream consumers can pin to them safely. Always push the immutable tag.
Mutable tags (sparingly). Mutable tags — latest, stable, canary — change what they refer to over time. They are convenient for local development and rollout channels, but dangerous for production because "the image that was there yesterday" is not guaranteed to be "the image that is there today".
Rules for mutable tags:
v1.2.3 first, then update latest to point at that same digestNever update a mutable tag without a corresponding immutable tag that pins the content.
Registry authentication is project-specific:
aws ecr get-login-password | docker login --username AWS --password-stdin <account>.dkr.ecr.<region>.amazonaws.com — ECR uses IAM for access control, so credentials come from the AWS CLI sessiongcloud auth configure-docker once, then normal docker push — credentials flow from gcloud's keyringecho $GITHUB_TOKEN | docker login ghcr.io -u <user> --password-stdin — use a PAT with write:packages scope, never a username/passworddocker login with a PAT (never username/password) for CI; interactive for localCredentials come from environment variables or a secrets manager. Never from source code, Dockerfiles, or shell history. See core/security §4.
Image signing (Cosign, Notary v2, GPG) makes supply-chain attacks detectable. If your platform supports it:
Unsigned images are acceptable for scratch work; they are not acceptable for anything that runs in production.
If you push myservice:v1.2.3 a second time with different content, you have created an incident waiting to happen: downstream consumers will get inconsistent results depending on when they pulled. Immutable means immutable.
If v1.2.3 was bad: cut v1.2.4. Do not re-push v1.2.3.
| Shortcut | Reality |
|---|---|
"I'll just push latest and call it good." | latest is convenient and untraceable. Push a version tag too. |
| "The image passed local health check — skip the scan." | Scanners find CVEs health checks don't. Run the scanner. |
| "I'll re-push the version tag with the fix." | Downstream consumers are now in an inconsistent state. Cut a new version. |
| "Credentials in the Dockerfile are fine for CI." | Credentials in layers leak via docker history. Use build secrets. |
| "Signing is overhead; we trust our network." | Supply-chain attacks are in-network attacks. Sign. |
| "The image is 5MB over target — we can push it anyway." | The target is a budget. Budget creep compounds — next quarter you're pulling 200MB images in every deploy. Fix the build. |
docker push myservice:latest without also pushing a version tagdocker push commands in CI scripts without authentication guardsops_enabled=true confirmed in session context before any push commandops_enabled=false: push reported as a follow-up with the proposed tag