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

> Learn the I-Have-ADHD destructive action procedure. This 6-step safety workflow ensures explicit user consent for data loss prevention. Protect your data with this essential guide.

- Repository: [Ayoub Ghriss/i-have-adhd](https://github.com/ayghri/i-have-adhd)
- Tags: how-to-guide
- Published: 2026-08-27

---

**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`](https://github.com/ayghri/i-have-adhd/blob/main/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`](https://github.com/ayghri/i-have-adhd/blob/main/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**:

```python
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`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md) | Canonical skill description driving runtime behavior |
| [`INSTALL.md`](https://github.com/ayghri/i-have-adhd/blob/main/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`](https://github.com/ayghri/i-have-adhd/blob/main/tests/test_run_evals.py) | Unit tests verifying destructive-action handling |
| [`hooks/hooks.json`](https://github.com/ayghri/i-have-adhd/blob/main/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`](https://github.com/ayghri/i-have-adhd/blob/main/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.