careful

Warn before executing destructive commands like rm -rf and git reset --hard.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Safety guardrails that warn before destructive commands, reducing the risk of accidental data loss in production or shared environments.

Core Features & Use Cases

  • Per-command detection of destructive actions (e.g., rm -rf, git reset --hard, kubectl delete) with a clear warning.
  • Allow overrides to proceed when users accept the risk, enabling controlled workflows.
  • Seamless integration with shell workflows via a PreToolUse hook to enforce safety in automated tasks.

Quick Start

Enable careful mode in your workflow to prompt before executing potentially 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 accidental destructive commands like rm -rf or git push --force in bash?

You can prevent accidental destructive commands by using a shell hook that warns before executing dangerous patterns like rm -rf or git push --force, requiring you to explicitly accept the risk before execution proceeds.

How do I add safety guardrails to intercept kubectl delete and git reset --hard during deployment?

Safety guardrails intercept kubectl delete and git reset --hard during deployment by applying a PreToolUse hook that matches destructive patterns and prompts for an override before allowing the command to run.

Can I configure custom matching patterns for destructive commands in my automated shell workflow?

Yes, you can configure custom matching patterns for destructive commands in your shell workflow, allowing the guardrail system to target specific risks unique to your codebase management or system administration tasks.

How does the override workflow balance risk-management protection with deployment productivity?

The override workflow balances risk-management and productivity by warning you before destructive actions and allowing you to proceed with the command once you explicitly accept the risk, ensuring controlled workflows without permanent blocking.

Does this destructive command guardrail require any external dependencies to intercept bash commands?

No external dependencies are required to intercept bash commands, as the destructive command guardrail operates seamlessly via a built-in PreToolUse hook to enforce safety directly within your existing environment.