When Should the i-have-adhd Rules Be Broken?

The i-have-adhd skill defines six specific exceptions—user-requested explanations, destructive actions, debug spirals, request ambiguity, task conflicts, and harness constraints—where strict formatting rules may be temporarily overridden to ensure safety and effectiveness.

The ayghri/i-have-adhd repository implements a rigid set of output-shaping rules designed to minimize cognitive load, but these constraints are not absolute. According to the canonical skill definition in [skills/i-have-adhd/SKILL.md](https://github.com/ayghri/i-have-adhd/blob/main/skills/i-have-adhd/SKILL.md#when-to-break-the-rules), the architecture explicitly defines when adherence to the rules must yield to safety, clarity, or task completion requirements.

The Six Architectural Exceptions

1. User Requests Explanations or Walkthroughs

When the user explicitly asks for an explanation, detailed walkthrough, or conceptual overview, the assistant may provide full contextual detail. While preambles and closing pleasantries remain prohibited, the assistant may add headers for easy skimming and comprehensive technical depth that would normally violate brevity constraints.

2. Destructive Actions Require Confirmation

Before executing irreversible operations—such as rm -rf commands, Git force-pushes, database schema migrations, or dropping production tables—the assistant must pause and request explicit confirmation. This safety override takes precedence over the default "immediate execution" paradigm to prevent accidental data loss.

3. Debug Spiral Detection

If the last three or more consecutive turns result in "still broken" status without resolution, the assistant must stop iterative guessing. Instead of attempting another fix, the assistant identifies a potentially wrong assumption and asks one targeted diagnostic question to break the loop.

4. Genuine Request Ambiguity

When a request contains real ambiguity that would lead to incorrect implementation, the assistant may ask a brief clarifying question. This exception applies only when the cost of guessing wrong exceeds the cost of the interruption; trivial or stylistic uncertainties do not qualify.

5. Rule-Task Direct Conflict

If following a specific rule would literally prevent completing the task—for example, if the rule would delete the answer itself—the task's functional requirements win. The assistant preserves the overall output shape where possible but ignores the conflicting rule for that specific step.

6. Harness Constraint Conflicts

When system prompts, tool-call requirements, or other harness-level constraints conflict with i-have-adhd rules, the harness takes precedence. The assistant announces the tool call, performs the required work, and follows the higher-level constraint while maintaining the overall ADHD-friendly output structure.

Implementation Patterns in Code

These exceptions manifest in the decision logic as explicit conditional checks before applying the standard output formatter.

# Example 1 – Destructive action requires confirmation override

if operation.is_destructive("rm -rf /important-folder"):
    # Break rule #2: safety override for destructive operations

    confirmation = input("⚠️ This will delete everything in /important-folder. Confirm? (yes/no)")
    if confirmation != "yes":
        exit()

# Example 2 – Debug spiral detection logic

attempts = 0
max_attempts = 3

while not task_successful and attempts < max_attempts:
    try_fix()
    attempts += 1

if attempts == max_attempts:
    # Break rule #3: debug spiral exception triggers diagnostic question

    print("We have attempted 3 fixes. What underlying assumption might be wrong?")
    print("Examples: missing env var, incorrect file path, permission issue")

Source File Structure

The exception logic is architected in two primary files:

• skills/i-have-adhd/SKILL.md – Contains the canonical definition of all 10 base rules and the "When to break the rules" section that enumerates these six exceptions with their specific triggering conditions.
• AGENTS.md – The agent guide that references the skill file and explains how the overall repository structure governs when standard formatting constraints may be suspended.

Both files reside in the root and skills/i-have-adhd/ directories of the ayghri/i-have-adhd repository, providing the authoritative source for exception handling behavior.

Summary

• Six explicit conditions allow breaking i-have-adhd rules: user explanations, destructive actions, debug spirals, request ambiguity, task conflicts, and harness constraints.
• Safety overrides brevity when dealing with rm -rf, force-pushes, or schema changes.
• Debug spirals terminate after three failed attempts to prevent infinite loops.
• Source authority for these exceptions is defined in SKILL.md with architecture references in AGENTS.md.
• Format preservation is maintained where possible; exceptions are surgical overrides, not blanket rule abandonment.

Frequently Asked Questions

What constitutes a "debug spiral" that triggers the exception?

A debug spiral occurs when three consecutive turns pass without resolving the issue, each resulting in "still broken" status. Rather than attempting a fourth speculative fix, the assistant must stop and ask one diagnostic question about potentially wrong assumptions, such as missing environment variables or incorrect file paths.

Do all destructive actions require confirmation under i-have-adhd rules?

Yes, any potentially destructive operation—defined as actions that cannot be undone like rm -rf, database table drops, or force-pushed Git changes—requires explicit user confirmation before proceeding. This is a hard safety override that takes precedence over the default terse output style.

How does the assistant handle conflicts between i-have-adhd rules and system prompts?

When the system harness or tool-calling architecture imposes requirements that conflict with i-have-adhd formatting rules, the harness constraints win. The assistant announces the tool call clearly, executes the required operation, and follows the system-level instruction while attempting to preserve the overall ADHD-friendly structure for the remaining output.

Can users request detailed explanations despite the no-preamble rule?

Yes. When a user explicitly requests an explanation, walkthrough, or detailed breakdown, the assistant may provide comprehensive technical content including headers for skimming. However, the output must still avoid conversational preambles ("Sure, I'd be happy to help") and closing pleasantries ("Let me know if you have questions").

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