dcg
Made by JeffHandle blocked destructive commands. Use when dcg blocks rm -rf, git reset --hard, DROP DATABASE, kubectl delete, or when configuring agent safety guardrails.
Works With
Quality and Utility come from canonical skill metadata. Community ratings appear separately as stars when subscriber reviews exist.
Subscribe to download
Public previews are available, but downloads, CLI sync, and premium content require an active subscription.
Sign In to Subscribe- Full skill content with deterministic versioning
- CLI sync + local search index
- Access to Jeffrey’s premium library
Save to your account
Saved skills live in your cloud list. Run jsm sync on each machine to pull them locally.
What's New with this Skill
1Updates, enhancements, and release notes for this skill.
New: DCG, blocked destructive commands print a recoverable alternative instead of a confirmation prompt
Treats blocked commands as checkpoints, not errors. Most common destructive commands have a recoverable alternative: git reset --hard becomes git stash, git push --force becomes --force-with-lease, rm -rf becomes rm -ri. The block prints the alternative; the agent uses it without asking for an override. 49+ rule packs are available and you enable the ones a project needs, latency is sub-millisecond, it fails open on timeout, and heredoc scanning catches inline scripts in bash -c and python -c.
- The motivating incident: Dec 17 2025, an agent ran git checkout -- on files with hours of uncommitted work. Files were recovered via git fsck --lost-found. The lesson: instructions don't prevent execution; mechanical enforcement does
- Safe Alternatives table: git reset --hard → git stash; git push --force → --force-with-lease; rm -rf → rm -ri; kubectl delete namespace → kubectl delete -l app=X. The agent reads the alternative and uses it
- dcg explain shows the 7-step trace (config allow → config block → heredoc → quick reject → sanitization → normalization → pack evaluation) so a missing block is debuggable; dcg test is a dry-run; dcg scan --staged runs in pre-commit
- Allow-once codes (dcg allow-once ab12) are 4 hex chars, 24h expiry, bound to exact command + directory. Run by the human only. The agent never types them
- 49+ rule packs, enabled per project in .dcg.toml: database.postgresql, kubernetes.kubectl, cloud.aws, containers.docker, and more. Context-aware: rm -rf ./build allowed, rm -rf / blocked
- Heredoc scanning catches inline scripts in bash -c '...' and python -c '...'. An agent can't smuggle a destructive command through a wrapper
- Sub-millisecond latency, fail-open on timeout (a hung DCG logs a warning and lets the command through). It doesn't slow the workflow and it doesn't lock you out
- dcg doctor verifies the hook is registered, and scripts/validate-dcg.sh runs a full installation check. When no safe alternative exists, the agent explains the risk and the human decides
On December 17, 2025, an AI agent ran git checkout -- on files containing hours of uncommitted work. The files were recovered via git fsck --lost-found, but the lesson stuck: instructions don't prevent execution; mechanical enforcement does. DCG is the enforcement layer.
The workflow is mechanical. When DCG blocks a command, the agent runs dcg explain "<cmd>" for the trace, checks the Safe Alternatives table, and uses the alternative without mentioning override codes. If no alternative exists, the agent explains the risk and lets the human decide. Override codes (dcg allow-once ab12)