docker-destructive-guardrails

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Docker Destructive Command Guardrails

Docker 破坏性命令防护栏

Overview

概述

This skill provides the cross-product policy for handling destructive or irreversible Docker CLI operations: commands that delete data, remove resources, or otherwise cannot be undone. Use it whenever a task could reasonably lead to running one of these commands, even if the user never names the command directly. It covers the generic Docker CLI commands with no home in a more specific skill, and it indexes where other destructive commands (Compose, sandbox, Desktop) are documented.
此skill提供了跨产品的破坏性或不可逆Docker CLI操作策略:删除数据、移除资源或以其他方式无法撤销的命令。只要任务可能合理导致运行这些命令之一,即使从未直接命名该命令,都应使用它。它涵盖没有归属到更具体skill中的通用Docker CLI命令,并索引其他破坏性命令(Compose、sandbox、Desktop)在何处被文档化。

When to use this skill

何时使用此skill

Activate this skill when:
  • The user asks to "clean up", "clear the cache", "start fresh", "wipe everything", "nuke it", "reset", "force remove", or "tear down" Docker resources without naming a specific command
  • The agent is considering
    docker rm
    ,
    docker rm -f
    ,
    docker container prune
    ,
    docker kill
    ,
    docker stop
    ,
    docker system prune
    ,
    docker rmi
    ,
    docker image rm
    ,
    docker image prune -a
    ,
    docker network rm
    ,
    docker network prune
    ,
    docker builder prune
    ,
    docker buildx rm
    ,
    docker context rm
    , or standalone (non-Compose)
    docker volume rm
    /
    docker volume prune
    as a fix for an unrelated problem (disk space, a stuck container, a stale network, a broken build cache, an old builder or volume)
  • The user wants a cross-product overview of destructive commands across Docker skills
在以下情况下激活此skill:
  • 用户要求"清理"、"清除缓存"、"重新开始"、"全部擦除"、"核平"、"重置"、"强制移除"或"拆掉"Docker资源而未指定具体命令
  • agent正在考虑将
    docker rm
    、
    docker rm -f
    、
    docker container prune
    、
    docker kill
    、
    docker stop
    、
    docker system prune
    、
    docker rmi
    、
    docker image rm
    、
    docker image prune -a
    、
    docker network rm
    、
    docker network prune
    、
    docker builder prune
    、
    docker buildx rm
    、
    docker context rm
    或独立(非Compose)的
    docker volume rm
    /
    docker volume prune
    作为无关问题(磁盘空间、卡住的容器、过时的网络、损坏的构建缓存、旧的builder或volume)的修复方案
  • 用户希望跨Docker skill获得破坏性命令的跨产品概览

Do not use this skill when

不应使用此skill的情况

Do not use this skill when:
  • The destructive command in question is Compose-specific (
    docker compose down -v
    ,
    docker compose rm -v
    ,
    docker volume rm
    /
    docker volume prune
    in a Compose project) — use
    docker-compose-patterns
    directly, which owns that guidance in full detail
  • The task is authoring or reviewing a Dockerfile or
    compose.yaml
    with no cleanup or deletion involved
  • The operation is non-Docker (git, filesystem, cloud resources) — this skill covers Docker CLI operations only
在以下情况下不应使用此skill:
  • 涉及的破坏性命令是Compose特有的(
    docker compose down -v
    、
    docker compose rm -v
    、Compose项目中的
    docker volume rm
    /
    docker volume prune
    )——直接使用
    docker-compose-patterns
    ,它完整地拥有该指南的所有细节
  • 任务是编写或审查Dockerfile或
    compose.yaml
    ,且不涉及清理或删除
  • 操作是非Docker的(git、文件系统、云资源)——此skill仅涵盖Docker CLI操作

Core guidance

核心指南

The core rule for every command below: state exactly what will be deleted, stopped, or lost, and get explicit confirmation from the user before running it. Never run a destructive command as a default troubleshooting or "just clean it up" reflex — disk space, stuck containers, and stale caches almost always have a narrower, non-destructive fix. See
references/docker-cli-destructive-commands.md
for exact flags and the safe, scoped alternative for each.
The container-lifecycle commands —
docker rm
,
docker rm -f
,
docker container prune
, and
docker kill
— don't all carry the same risk, so they're split into two tiers below instead of one flat rule.
docker stop
follows a related but distinct reversible-action rule right after the tiers. Every other command in this list follows the flat rule stated above with no exceptions: state what's lost, get explicit confirmation, and wait for the user's answer before running it.
以下每个命令的核心规则:**准确说明将被删除、停止或丢失的内容,并在运行之前获得用户的明确确认。**切勿将破坏性命令作为默认的故障排除或"直接清理一下"的反射行为——磁盘空间、卡住的容器和过时的缓存几乎总是有更狭窄、非破坏性的修复方案。参见
references/docker-cli-destructive-commands.md
了解确切标志和每个命令的安全、有范围的替代方案。
容器生命周期命令——
docker rm
、
docker rm -f
、
docker container prune
和
docker kill
——并非都承载相同的风险,因此它们被分为下面的两个层级而不是一个平坦规则。
docker stop
遵循一个相关但不同的可逆操作规则,位于层级之后。此列表中的每个其他命令都遵循上述平坦规则,无例外:说明将丢失的内容,获得明确确认,并在运行之前等待用户的回答。

Tier 1 — low-friction container cleanup

层级 1 — 低摩擦容器清理

Applies only to
docker rm <name>
on an already-stopped container and
docker rm -f <name>
on a container the agent itself created and started earlier in the same session purely for testing or debugging — the
-f
carve-out applies even when the container is still running, since that's the only reason
-f
would be needed. All of the following must hold: the container is already stopped, or was created/started by the agent itself this session for testing/debugging; there's no known unpersisted state at risk; the action targets one specific, identified container rather than an unscoped sweep; and the agent is acting on an explicit user ask this session, not its own initiative. When every condition holds, the agent removes the container, states what it did, and proceeds — no blocking confirmation is required first. Tier 2's
docker rm -f
rule below applies to every other case.
仅适用于对已停止容器的
docker rm <name>
,以及agent在同一会话中先前创建并启动的纯粹用于测试或调试的容器的
docker rm -f <name>
——
-f
例外即使容器仍在运行也适用,因为这是唯一需要
-f
的理由。以下所有条件必须成立:容器已停止,或由agent本会话自行创建/启动用于测试/调试;没有已知的未持久化状态处于风险中;操作针对一个特定的、已识别的容器而不是无范围的清扫;且agent是响应会话中的明确用户请求而行动,而非自行主动。当所有条件都成立时,agent移除容器,说明其做了什么,然后继续——不需要先进行阻塞性确认。层级2的
docker rm -f
规则适用于其他所有情况。

Tier 2 — container commands needing confirmation

层级 2 — 需要确认的容器命令

docker kill
is always Tier 2 (see the reference for why no stopped-container exception exists for it). Also Tier 2:
docker container prune
(it always sweeps every stopped container on the host, never just the one the agent is cleaning up),
docker rm -f
on any container that doesn't meet every Tier 1 condition above (in particular, a running container the agent didn't create/start this session, or one it did but is acting on without an explicit user ask), any other unscoped sweep regardless of container state (e.g.
docker rm -f $(docker ps -aq)
, "remove/kill all containers"), a container the agent didn't create and has no context on, and any action taken on the agent's own initiative rather than an explicit user ask. These carry the same confirmation bar as every flat-rule command in this skill: state exactly what will be lost and get explicit confirmation before running anything — no exception carved out.
docker kill
始终是层级2(参见参考文档了解为什么不存在已停止容器例外)。同样是层级2:
docker container prune
(它总是清扫主机上所有已停止的容器,而不仅仅是agent正在清理的那个),对不满足上述所有层级1条件的任何容器的
docker rm -f
(特别是agent本会话未创建/启动的正在运行的容器,或虽由agent创建/启动但非用户明确要求而操作的情况)、任何其他无范围的清扫无论容器状态如何(例如
docker rm -f $(docker ps -aq)
、"移除/杀死所有容器")、agent未创建且无上下文的容器,以及agent主动采取而非响应明确用户请求的任何行动。这些操作与本文档中每个平坦规则命令承载相同的确认标准:准确说明将丢失的内容并在运行任何命令之前获得明确确认——不设例外。

docker stop
— reversible, outside the tier model

docker stop
— 可逆,在层级模型之外

docker stop
doesn't remove anything — the container still exists and can be restarted with
docker start
— so it sits outside the Tier 1/Tier 2 removal model above. It's still in scope for this skill because it interrupts a running process (SIGTERM, then SIGKILL after the timeout) and discards any unpersisted in-container state. On the agent's own test/debug container from this session, treat it like Tier 1: stop it and state what happened, no blocking confirmation required. On any other container, state that it will stop running and any unsaved in-memory state will be lost, then get confirmation first.
  • docker system prune
    — deletes stopped containers, unused networks, dangling images, and build cache;
    -a
    also deletes unused tagged images, and
    --volumes
    also deletes unused anonymous volumes (named volumes are untouched — deleting those needs a separate
    docker volume rm
    ).
  • docker rmi
    /
    docker image rm
    — deletes a specific image; see the reference for
    -f
    's exact (partly unverified) override behavior on multi-tag/referenced images.
  • docker image prune -a
    — deletes every image not referenced by any container, running or stopped, not just dangling ones.
  • docker network rm
    — deletes the specifically named network(s) passed as arguments; see the reference for how its
    -f
    flag differs from
    docker context rm -f
    below.
  • docker network prune
    — deletes every custom network not attached to a container.
  • docker builder prune
    — clears the BuildKit cache;
    -a
    /
    --all
    also removes internal helper/frontend images and cache shared with other build outputs, forcing a cold rebuild for anyone using that cache.
  • docker buildx rm
    — removes a builder instance, distinct from the cache
    docker builder prune
    clears — see the reference for flag details.
  • docker context rm
    — deletes a context's local connection config; doesn't affect remote resources but may not be trivially reconstructable. Unlike
    docker network rm -f
    above,
    docker context rm -f
    genuinely forces removal even if the context is currently in use.
  • docker volume rm
    /
    docker volume prune
    (standalone, no Compose project in play) — deletes volume data directly and irreversibly;
    docker volume prune -a
    /
    --all
    widens the default anonymous-only scope to named volumes too. For a Compose project's own volumes, use
    docker-compose-patterns
    instead (see Related skills); for a volume declared
    external: true
    in a compose.yaml but not managed by that Compose project, this skill's guidance applies since Compose won't touch it via
    down -v
    .
docker stop
不删除任何东西——容器仍然存在,可以用
docker start
重新启动——因此它位于上述层级1/层级2移除模型之外。它仍然属于此skill的范围,因为它中断正在运行的进程(SIGTERM,超时后SIGKILL)并丢弃容器内任何未持久化的状态。对于agent本会话自己的测试/调试容器,像层级1一样对待:停止并说明发生了什么,不需要阻塞性确认。对于任何其他容器,说明它将停止运行且任何未保存的内存中状态将丢失,然后先获得确认。
  • docker system prune
    — 删除已停止的容器、未使用的网络、悬空镜像和构建缓存;
    -a
    还删除未使用的带标签镜像,
    --volumes
    还删除未使用的匿名卷(命名卷不受影响——删除这些需要单独的
    docker volume rm
    )。
  • docker rmi
    /
    docker image rm
    — 删除特定镜像;参见参考文档了解
    -f
    对多标签/被引用镜像的精确(部分未验证的)覆盖行为。
  • docker image prune -a
    — 删除所有未被任何容器引用的镜像(无论运行中还是已停止),不仅仅是悬空镜像。
  • docker network rm
    — 删除作为参数传入的特定命名网络;参见参考文档了解其
    -f
    标志与下面的
    docker context rm -f
    有何不同。
  • docker network prune
    — 删除所有未附加到容器的自定义网络。
  • docker builder prune
    — 清除BuildKit缓存;
    -a
    /
    --all
    还移除内部辅助/frontend镜像以及与其他构建输出共享的缓存,强制任何使用该缓存的人进行冷重建。
  • docker buildx rm
    — 移除builder实例,与
    docker builder prune
    清除的缓存不同——参见参考文档了解标志细节。
  • docker context rm
    — 删除上下文的本地连接配置;不影响远程资源,但可能不容易重建。与上面的
    docker network rm -f
    不同,
    docker context rm -f
    确实强制移除,即使上下文当前正在使用中。
  • docker volume rm
    /
    docker volume prune
    (独立,无Compose项目)——直接且不可逆地删除卷数据;
    docker volume prune -a
    /
    --all
    将默认的仅匿名范围扩展到包括命名卷。对于Compose项目自己的卷,请改用
    docker-compose-patterns
    (参见相关skill);对于在compose.yaml中声明为
    external: true
    但不由该Compose项目管理的卷,此skill的指南适用,因为Compose不会通过
    down -v
    触碰它。

Related skills

相关skill

  • For Compose-specific destructive commands (
    docker compose down -v
    ,
    docker compose rm -v
    ,
    docker volume rm
    /
    docker volume prune
    in a Compose context), use
    docker-compose-patterns
    — it owns that guidance in full detail; this skill only indexes it. This skill owns the standalone (non-Compose) case for
    docker volume rm
    /
    docker volume prune
    itself — see Core guidance and
    references/docker-cli-destructive-commands.md
    .
  • For Dockerfile internals, build caching, and image size optimization (non-destructive concerns), use
    docker-build-strategies
    .
  • For first-time Docker project scaffolding, use
    docker-project-foundations
    .
  • For sandbox (sbx) destructive commands (
    sbx rm
    ,
    sbx prune
    ), use
    docker-sandboxes-lifecycle
    — it owns that guidance in full detail; this skill only indexes it. Docker Desktop destructive-command guardrails will live in their own skill once merged (see
    references/cross-skill-destructive-command-index.md
    for tracking status); do not assume their content until that skill ships.
  • 对于Compose特定的破坏性命令(
    docker compose down -v
    、
    docker compose rm -v
    、Compose上下文中的
    docker volume rm
    /
    docker volume prune
    ),使用
    docker-compose-patterns
    ——它完整地拥有该指南的所有细节;此skill仅索引它。此skill自己拥有独立(非Compose)情况下的
    docker volume rm
    /
    docker volume prune
    ——参见核心指南和
    references/docker-cli-destructive-commands.md
    。
  • 对于Dockerfile内部机制、构建缓存和镜像大小优化(非破坏性问题),使用
    docker-build-strategies
    。
  • 对于首次Docker项目脚手架搭建,使用
    docker-project-foundations
    。
  • 对于sandbox(sbx)破坏性命令(
    sbx rm
    、
    sbx prune
    ),使用
    docker-sandboxes-lifecycle
    ——它完整地拥有该指南的所有细节;此skill仅索引它。Docker Desktop破坏性命令防护栏在合并后将拥有自己的skill(参见
    references/cross-skill-destructive-command-index.md
    了解跟踪状态);在该skill发布之前,不要假设其内容。

References

参考文档

  • references/docker-cli-destructive-commands.md
    — Per-command breakdown of exact flags, what's deleted, and the safe/scoped alternative for each generic Docker CLI destructive command.
  • references/cross-skill-destructive-command-index.md
    — Cross-product table of destructive commands across all Docker skills, including a pending placeholder for Docker Desktop.
  • references/docker-cli-destructive-commands.md
    — 每个通用Docker CLI破坏性命令的逐命令分解:确切标志、删除内容以及安全/有范围的替代方案。
  • references/cross-skill-destructive-command-index.md
    — 所有Docker skill中破坏性命令的跨产品表,包括Docker Desktop的待定占位符。

Assets

资源

This skill has no bundled assets.
此skill没有捆绑资源。

Checks

检查

  • checks/verification.md
    — Manual review runbook, including example bad/good dialogues for handling destructive-command requests.
  • checks/verification.md
    — 手动审查运行手册,包括处理破坏性命令请求的示例不良/良好对话。