# How the i‑have‑adhd Plugin Handles Cases Where Rules Are Designed to Be Broken

> Discover how the i-have-adhd plugin manages exceptions to its ADHD-friendly rules using a deterministic hierarchy for safety and clarity.

- Repository: [Ayoub Ghriss/i-have-adhd](https://github.com/ayghri/i-have-adhd)
- Tags: internals
- Published: 2026-08-18

---

**The i‑have‑adhd plugin uses a deterministic, ordered exception hierarchy defined in [`SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/SKILL.md) to override its ten ADHD‑friendly rules when safety, clarity, or task requirements demand it.**

The *i‑have‑adhd* plugin (from the [ayghri/i‑have‑adhd](https://github.com/ayghri/i-have-adhd) repository) enforces a strict set of ten output rules optimized for ADHD‑friendly interactions—brevity, concrete actions, no filler. However, the plugin recognizes that rigid adherence can backfire. This article explains how it handles **exceptional cases where rules are designed to be broken**, as codified in lines 17‑26 of [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md).

## The Ordered Exception Hierarchy

The plugin evaluates six conditions **sequentially**. The first true condition short‑circuits normal rule processing and applies its exception logic. This design guarantees deterministic, testable behavior.

### 1. Explanation or Walk‑Through Requests

When the user explicitly asks for understanding—not just action—the plugin overrides its **brevity‑first** rules.

```python

# User request

user_msg = "Walk me through setting up the project."

# Plugin detects explanation intent

if "explain" in user_msg.lower() or "walk me through" in user_msg.lower():
    # Bypass rule 1 (lead with next action)

    response = """

## Project Setup Walk‑through

1. Clone the repo …
2. Install dependencies …
3. Run `npm start` …
"""

```

The response expands with headers and detail but still omits forbidden pre‑/post‑ambles.

### 2. Destructive Actions

Safety trumps style. Before executing potentially harmful operations, the plugin inserts a confirmation step.

```python
import re

user_msg = "Delete the feature branch."

# Exception 2: destructive command detected

if re.search(r"\b(rm\s+-rf|git\s+push\s+--force|drop\s+table)\b", user_msg):
    response = "⚠️ This operation is destructive. Confirm you want to proceed (yes/no)?"

```

This protects against accidental `rm -rf`, force‑pushes, or schema migrations.

### 3. Debug Spiral Detection

Repetitive failure loops frustrate users. After three consecutive "still broken" turns, the plugin intervenes.

```python

# Tracker of recent failures

recent_failures = ["still broken", "still broken", "still broken"]

# Exception 3: terminate iterative debugging

if recent_failures.count("still broken") >= 3:
    response = "It looks like we're stuck. The most likely cause is X. Should we check Y?"

```

The plugin surfaces the most probable faulty assumption and asks a single diagnostic question.

### 4. Real Ambiguity

When guessing would be risky, the plugin asks rather than assumes.

Ambiguous requests trigger a **concise clarifying question** instead of speculative code rewrites. This preserves accuracy without violating the spirit of direct communication.

### 5. Rule‑Versus‑Task Conflict

Some tasks inherently violate output rules. For example, when the answer *is* a preamble (like installation instructions), the plugin emits the content anyway—preserving structure (numbered steps, concrete actions) without artificial constraint.

### 6. Harness Conflict

When the surrounding agent‑harness demands specific behavior—tool calls or adjusted time estimates—the plugin obeys, announcing tool calls transparently and aligning estimates to harness expectations.

## Why This Architecture Matters

| Property | How the Exception Hierarchy Delivers |
|----------|--------------------------------------|
| **Determinism** | Ordered evaluation ensures exactly one exception path per turn—no competing overrides. |
| **Testability** | Pure‑functional rule engine with no side effects; each condition is independently verifiable. |
| **Safety prioritization** | Critical overrides (destructive actions, debug spirals) appear first in evaluation order. |
| **Extensibility** | New exceptions append to the ordered list without touching existing rule definitions. |

## Key Source Files

The exception behavior is fully documented in [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md) (lines 17‑26), which serves as the single source of truth:

- **[`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md)** — Defines ten ADHD‑friendly rules and the ordered exception list
- **[`AGENTS.md`](https://github.com/ayghri/i-have-adhd/blob/main/AGENTS.md)** — Maps the skill to runtime entry points
- **[`README.md`](https://github.com/ayghri/i-have-adhd/blob/main/README.md)** — Repository overview and invocation patterns
- **[`INSTALL.md`](https://github.com/ayghri/i-have-adhd/blob/main/INSTALL.md)** — Setup instructions that may trigger destructive‑action safeguards

## Summary

- The i‑have‑adhd plugin applies **six ordered exception checks** before enforcing its ten core rules.
- **Safety‑first ordering** ensures destructive actions and debug spirals take precedence over style constraints.
- All exception logic is **transparent and deterministic**—no hidden state or probabilistic branching.
- The rule‑engine architecture remains **pure and extensible**; new exceptions slot in at the appropriate priority level.
- Source‑of‑truth documentation lives in [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md), making behavior auditable and version‑controlled.

## Frequently Asked Questions

### What triggers the plugin to break its own rules?

The plugin breaks rules when one of six conditions in [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md) evaluates true: explanation requests, destructive actions, debug spirals, real ambiguity, rule‑task conflicts, or harness demands. These are checked in strict order.

### Is the exception behavior configurable?

No. The exception hierarchy is hardcoded in [`SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/SKILL.md) to ensure consistent, predictable behavior across all agents loading the skill. Extensibility comes from adding new ordered checks, not modifying existing logic.

### How does the plugin handle ambiguous user requests?

Rather than guessing and rewriting code, the plugin asks a concise clarifying question. This preserves the "concrete actions" spirit while avoiding costly mistakes from misinterpretation.

### Can the plugin override multiple rules at once?

Only one exception path activates per turn—the first true condition short‑circuits evaluation. This design prevents conflicting overrides and keeps responses predictable.