careful

Scan Bash command input for destructive shell and Git patterns before execution.

Updated Feb 16, 2026
One-click install
npx skills add https://github.com/SeaLion-hub/DICEE --skill careful-sealion-hub
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: careful
Source: https://github.com/SeaLion-hub/DICEE/tree/main/.agents/skills/gstack/careful
Command: npx skills add https://github.com/SeaLion-hub/DICEE --skill careful-sealion-hub

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Safety guardrails prevent destructive commands from executing without warning in shells and automation, helping avoid costly data loss.

Core Features & Use Cases

  • PreToolUse hook in Bash checks for high-risk patterns such as rm -rf, git push --force, kubectl delete, and similar commands, and prompts before continuing.
  • Safe-exceptions list allows routine maintenance targets (node_modules, builds) to pass without warning.
  • Local analytics logging records pattern hits for auditing and improvement.

Quick Start

Enable careful mode in your AI tooling to warn before destructive commands.

Frequently Asked Questions about careful

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent destructive bash commands like rm -rf from executing without warning?

You can prevent destructive bash commands by implementing a PreToolUse hook that scans command input for high-risk patterns like rm -rf and prompts for confirmation before execution.

Can I add safe exceptions for routine maintenance targets like node_modules?

Yes, you can configure a safe-exceptions list that allows routine maintenance targets such as node_modules and build directories to pass through the PreToolUse hook without triggering a warning.

Does this safety guardrail work with git push --force and kubectl delete commands?

Yes, the safety guardrail works with git push --force and kubectl delete by scanning for these destructive patterns in interactive sessions and automated tools before returning a permission decision.

What is the best way to audit how often destructive shell commands are attempted?

The best way to audit destructive shell command attempts is to use local analytics logging, which records pattern hits whenever the PreToolUse hook intercepts a high-risk command for later review.

Can I apply destructive command guardrails across development, testing, and prod-like environments?

Yes, you can apply destructive command guardrails across development, testing, and prod-like environments because the PreToolUse hook operates in Bash sessions and automated tools regardless of the environment context.

How does a PreToolUse hook decide whether to block or allow a destructive command?

A PreToolUse hook decides by scanning the command input against high-risk patterns and a safe-exceptions list, then returning a permissionDecision, a warning message, or an allow result with analytics logging.