# Six Exceptions to i-have-adhd Rules: When to Override the Output Constraints > Discover the six exceptions to i-have-adhd rules. Learn when to override output constraints for safety and task completion in this technical guide. - Repository: [Ayoub Ghriss/i-have-adhd](https://github.com/ayghri/i-have-adhd) - Tags: deep-dive - Published: 2026-07-31 --- **The i-have-adhd skill mandates terse, preamble-free communication, but six documented exceptions in [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md) permit verbose explanations, safety confirmations, and diagnostic interruptions when rigid adherence would compromise user safety or task completion.** The `ayghri/i-have-adhd` repository defines a strict output-shaping skill designed to eliminate cognitive overhead for users with ADHD. While the rules normally enforce brevity and prohibit preambles or closings, the specification recognizes six specific scenarios where standard constraints must yield to practical necessities like data safety and effective debugging. ## The Six Exceptions Documented in SKILL.md According to the source code in [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md) (lines 19-29), the following six situations justify breaking the standard output rules: ### 1. User Requests an Explanation or Walkthrough When the user explicitly asks for a detailed explanation, the skill may expand beyond its usual brevity. The response must still avoid preambles and closings, but can include comprehensive step-by-step guidance that would normally violate the conciseness constraint. ### 2. Destructive Actions Are Required For commands that could **delete data**, **force-push** commits, or **drop database tables**, the skill must request confirmation before proceeding. Safety protocols override brevity requirements entirely, allowing the skill to emit warning prompts and request explicit user approval. ### 3. Debug Spirals If the last three conversational turns have consisted of "still broken" iterations, the skill must stop the repetitive cycle. It should surface the underlying assumption that might be wrong and ask a **single diagnostic question** to reorient the troubleshooting process, breaking the normal pattern of immediate solution attempts. ### 4. Real Ambiguity in the Request When the user’s intent is genuinely unclear, the skill should ask a **brief clarifying question** rather than guessing. This prevents incorrect implementations that would require subsequent correction, making the interaction more efficient despite temporarily breaking the "immediate answer" rule. ### 5. Rule Conflicts with the Task Itself If strict adherence to formatting rules would prevent delivering the answer, the task takes precedence. For example, answering "what are my options" requires providing a **ranked list**, which temporarily overrides the brevity constraint since the format is essential to the response. ### 6. Rule Conflicts with the Harness In **agent harness** environments where system prompts outrank skill instructions, the skill must defer to the harness requirements. This includes announcing tool calls when required, performing work directly rather than explaining it, and applying time estimates to the executor rather than the reader. ## Practical Implementation Examples The repository provides concrete code examples demonstrating these exceptions in action within the skill definition. **Example: Walkthrough Request (Exception 1)** ```python # User: "Can you walk me through how to set up the plugin?" # Response (allowed to be longer, no preamble): # 1. Install the plugin with `claude plugin marketplace add ayghri/i-have-adhd` # 2. Enable it using `claude plugin install i-have-adhd@i-have-adhd` # 3. Invoke with `/i-have-adhd` … ``` **Example: Destructive Action Confirmation (Exception 2)** ```python # User: "Delete the whole repo directory." # Response: # "Are you sure you want to delete the repository? This operation cannot be undone. Reply 'yes' to proceed." ``` ## Summary - The **six exceptions** are formally defined in [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md) between lines 19-29. - **Explanations and walkthroughs** allow expanded content while maintaining the prohibition on preambles. - **Destructive actions** trigger mandatory confirmation prompts that prioritize data safety. - **Debug spirals** require intervention after three failed "still broken" iterations. - **Ambiguous requests** warrant clarifying questions over potentially incorrect guesses. - **Task conflicts** permit format deviations when rules would block delivering the necessary answer format. - **Harness conflicts** acknowledge system prompt superiority in agent environments like Codex or Claude platforms. ## Frequently Asked Questions ### What is the i-have-adhd skill? The i-have-adhd skill is a Claude/Codex plugin defined in the `ayghri/i-have-adhd` repository that enforces strict output formatting rules designed to reduce cognitive load and eliminate conversational fluff for users with ADHD. ### Where are the six exceptions documented? The six exceptions are explicitly listed in the "When to break the rules" section of [`skills/i-have-adhd/SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md), specifically within lines 19-29 of the file. ### How does the skill handle destructive commands? According to exception 2, when destructive actions like deleting repositories or dropping tables are requested, the skill must pause to request explicit confirmation, prioritizing data safety over the standard brevity constraint. ### What happens when a rule conflicts with the system prompt? Per exception 6, in agent harnesses where system prompts outrank skill instructions, the skill must defer to the harness requirements, including announcing tool calls and applying time estimates to the executor rather than the end reader.