I-Have-ADHD Destructive Action Procedure: 6-Step Safety Workflow Explained

The I-Have-ADHD skill enforces a strict 6-step confirmation workflow for destructive actions, requiring explicit user consent before executing any command that could cause data loss.

The I-Have-ADHD repository by ayghri implements a safety-first Agent Skill designed to prevent accidental data destruction. When users request operations that modify or delete data—such as removing files or altering system state—the skill triggers a defensive protocol that prioritizes user verification over execution speed.

---

How the Destructive Action Detection Works

The skill parses every user prompt to flag commands with destructive potential. This detection layer operates before any command execution, ensuring risky operations never run blindly.

According to the evaluation harness in evals/cases.jsonl at line 5, the skill defines explicit acceptance criteria for destructive-action scenarios. The test suite in tests/test_run_evals.py at line 73 automatically scores this behavior, verifying the confirmation flow is respected.

---

The 6-Step I-Have-ADHD Destructive Action Procedure

Step 1: Detect the Request

The skill identifies any command capable of altering or deleting data. This destructive action detection serves as the gatekeeper for the entire safety workflow.

Step 2: Prompt for Confirmation

Before proceeding, the agent replies with a concise confirmation request that explicitly states the risk. The INSTALL.md file at line 53 documents this as the "Confirm before destructive actions" exception to default behavior.

Step 3: Provide a Read-Only Preview

When feasible, the agent displays a non-mutating preview of the pending operation—such as git status output or a list of files marked for deletion. This helps users verify scope without side effects.

Step 4: Await Explicit User Consent

The agent pauses indefinitely until the user responds with clear approval—typically "yes" or equivalent. No destructive command executes without this explicit signal.

Step 5: Execute the Command

Once approved, the actual destructive command emits once and is bounded to a single step. This limits impact to a predictable, controlled action.

Step 6: Stop After Repeated Failures

If three consecutive fix attempts fail, the skill aborts and surfaces the doubtful assumption. This prevents endless loops or cascading damage.

---

Implementation Example

The following Python pattern illustrates how consuming agents implement this I-Have-ADHD destructive action procedure:

def handle_user_request(request: str) -> str:
    if is_destructive(request):
        # Step 2 – ask for confirmation

        return (
            "⚠️ This command will delete files. "
            "Do you want to continue? (yes/no)\n"
            "Preview: `git status` shows the files that would be removed."
        )
    # normal handling …

    return run_safe_command(request)


def process_confirmation(reply: str, pending_command: str) -> str:
    if reply.strip().lower() == "yes":
        # Step 5 – execute single, bounded destructive command

        return run_destructive(pending_command)
    return "❌ Action cancelled."

Example Dialogue

User: Delete all untracked files in this repo.
Agent: ⚠️ This command will delete files. Do you want to continue? (yes/no)
        Preview: `git clean -ndX` (shows which files would be removed)

User: yes
Agent: ✅ Executed: `git clean -fdX`

---

Source Files Defining the Procedure

File	Role
skills/i-have-adhd/SKILL.md	Canonical skill description driving runtime behavior
INSTALL.md	Lists "Confirm before destructive actions" as core policy exception
evals/cases.jsonl	Defines destructive-action test case acceptance criteria
tests/test_run_evals.py	Unit tests verifying destructive-action handling
hooks/hooks.json	Declares session-start hooks enforcing safety rules

---

Summary

• Detection first: Every prompt is screened for destructive potential before execution
• Confirmation required: Explicit "yes" response mandatory for risky operations
• Preview when possible: Read-only scope verification prevents surprises
• Single bounded execution: One command per approval, no batching
• Failure limits: Three-strike rule prevents runaway damage
• Tested and verified: Automated suite validates compliance

---

Frequently Asked Questions

What counts as a destructive action in I-Have-ADHD?

Operations that alter or delete data—including file deletion, system state modification, or any command causing irreversible change. The skill's parser flags these automatically based on command signatures and context.

Does I-Have-ADHD ever skip the confirmation step?

No. According to INSTALL.md line 53, "Confirm before destructive actions" is a non-negotiable exception. The evaluation harness in evals/cases.jsonl rejects any implementation that bypasses confirmation.

What happens if I don't respond to the confirmation prompt?

The agent waits indefinitely. No timeout or automatic execution occurs— the destructive action procedure requires active user consent to proceed.

How does the skill prevent confirmation fatigue?

By combining explicit risk statements with read-only previews (Step 3), users can quickly assess scope without repetitive back-and-forth. The bounded single-step execution (Step 5) also limits how often confirmations are needed.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}