careful

Inspect shell commands for destructive patterns before execution.

Updated Apr 5, 2026
One-click install
npx skills add https://github.com/GTC6244/ToolBridge --skill careful-gtc6244
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: careful
Source: https://github.com/GTC6244/ToolBridge/tree/main/.claude/skills/gstack/careful
Command: npx skills add https://github.com/GTC6244/ToolBridge --skill careful-gtc6244

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Destructive actions in shell can cause data loss or service disruption. This skill adds pre-execution guardrails and warnings, giving you an opportunity to cancel dangerous commands.

Core Features & Use Cases

  • Pre-execution checks: Scans commands for destructive patterns like rm -rf, git reset --hard, kubectl delete, and more, before they run.
  • Override-safe prompts: Allows you to confirm or override warnings to proceed when you accept the risk.
  • Audit logging: Records risky command attempts locally for safety reviews without sending sensitive data externally.

Quick Start

Enable careful mode in your session and run a risky command to see a warning prompt.

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 accidentally?

Prevent destructive bash commands by implementing a pre-execution hook that scans for patterns like rm -rf and prompts for confirmation before allowing the shell to run them.

Can I override the warning prompt if I accept the risks of a risky git reset command?

You can override the warning prompt for a risky git reset command by accepting the risk, which allows the destructive operation to proceed while still logging the attempt locally.

Does the pre-execution guardrail work for automated shell scripts or only interactive sessions?

The pre-execution guardrail works for both interactive Bash sessions and automated scripts, inspecting risky operations like kubectl delete or docker prune before execution regardless of context.

How are destructive command attempts logged for safety auditing?

Destructive command attempts are logged locally by recording risky command patterns during pre-execution checks, providing safety audit data without sending sensitive information externally.

What are the limitations of using pre-run warnings for risk-management in shell sessions?

A limitation of pre-run warnings is that they rely on pattern matching for known destructive commands, meaning novel or obfuscated risky operations might bypass the predefined guardrails.

What is the best way to add guardrails for destructive kubectl delete operations?

The best way to add guardrails for destructive kubectl delete operations is to intercept commands before execution, checking them against destructive patterns and prompting for override confirmation.