careful

Warn before executing destructive shell commands like rm -rf and kubectl delete.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Safety guardrails that intercept destructive shell commands and warn before execution to prevent accidental data loss in prod, staging, and shared environments.

Core Features & Use Cases

  • Pre-checks destructive patterns such as rm -rf, git reset --hard, kubectl delete, and similar operations.
  • Allows user override to proceed after receiving a warning, enabling safe experimentation and debugging.
  • Logs usage analytics for auditing and improvement of safety policies.

Quick Start

Enable careful mode when you want explicit safeguards during risky operations.

Frequently Asked Questions about careful

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

FAQPage Schema
How do I add a warning prompt before executing destructive shell commands like rm -rf?

To add a warning before destructive shell commands, you can use a PreToolUse hook that intercepts operations like rm -rf, git reset --hard, and kubectl delete, prompting for explicit user override before execution to prevent accidental data loss.

Can I still run git reset --hard if a destructive command warning is triggered?

Yes, you can still run git reset --hard after a destructive command warning is triggered. The safety guardrail allows an explicit user override, enabling you to proceed with necessary debugging or experimentation after acknowledging the risk.

Does this destructive command guardrail work for kubectl delete in production environments?

Yes, this destructive command guardrail works for kubectl delete across development, staging, and production environments, intercepting risky operations to prevent accidental data loss in shared infrastructure.

What is the best way to prevent accidental data loss from automation workflows running rm -rf?

The best way to prevent accidental data loss from automation workflows running rm -rf is to implement a PreToolUse hook that pre-checks destructive patterns and logs usage analytics for auditing before execution proceeds.

Why do I need a safety guardrail for destructive commands in interactive shells?

You need a safety guardrail for destructive commands in interactive shells to prevent irreversible mistakes. It intercepts high-risk commands and requires an explicit override, stopping accidental data loss before it happens.

Are there limitations to using a PreToolUse hook for intercepting destructive shell commands?

A limitation of using a PreToolUse hook for destructive commands is that users can explicitly override the warning, meaning the guardrail prevents accidental data loss but cannot block intentional forced execution.