careful

Warn on destructive shell commands and require explicit confirmation before execution.

1|1|Updated Mar 28, 2026
One-click install
npx skills add https://github.com/nuurpro/Converza_ai --skill careful-nuurpro
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: careful
Source: https://github.com/nuurpro/Converza_ai/tree/main/.claude/skills/careful
Command: npx skills add https://github.com/nuurpro/Converza_ai --skill careful-nuurpro

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill prevents unsafe destructive actions in shell environments by detecting dangerous commands and prompting for confirmation before execution.

Core Features & Use Cases

  • Warns on destructive patterns such as rm -rf, git reset --hard, kubectl delete, and similar operations.
  • Enforces an explicit override path when proceeding with warned commands, reducing the risk of accidental data loss.
  • Logs usage metadata to local analytics for auditing and improvement of guardrails.

Quick Start

Use careful mode to have destructive commands warned and require explicit confirmation before proceeding.

Frequently Asked Questions about careful

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

FAQPage Schema
How do I prevent accidental destructive commands like rm -rf in bash?

You can prevent destructive bash actions by using guardrails that warn on dangerous commands and require explicit confirmation before execution. This detects patterns like rm -rf to stop accidental data loss.

What is the best way to require confirmation before executing git reset --hard?

The best way to require confirmation for git reset --hard is implementing a PreToolUse hook that analyzes shell commands. It enforces an explicit override path, ensuring you consciously approve high-risk operations.

Does this destructive command warning system work with kubectl delete operations?

Yes, the destructive command warning system works with kubectl delete operations. It detects these high-risk patterns across development, staging, and production environments, prompting an explicit override to proceed.

How do I override a blocked destructive shell command when I need to run it?

You override a blocked destructive shell command by following the explicit override path enforced by the guardrail. The system warns you first, requiring direct confirmation before allowing the command to execute.

Can I use this safety guardrail across development and production environments?

Yes, you can use this safety guardrail across development, staging, and production environments. It analyzes shell commands universally to prevent unsafe destructive actions regardless of the active environment.

Why do I need an explicit override for destructive shell actions?

You need an explicit override for destructive shell actions to reduce the risk of accidental data loss. Requiring confirmation forces a deliberate decision before proceeding with warned commands like rm -rf or git reset --hard.