6 Exceptions to the "No Preamble" Rule in the i-have-ADHD Skill

The i-have-ADHD skill defines six explicit exceptions—including explanation requests, destructive actions, and debug spirals—where breaking the strict "no preamble" rule is permitted to ensure safety and clarity.

The ayghri/i-have-adhd repository implements a strict communication protocol designed to keep responses concise for readers with ADHD. While Rule 10 mandates "no preamble, no recap, no closing pleasantries," the skills/i-have-adhd/SKILL.md file documents specific scenarios where violating this rule improves user safety and response quality.

Understanding Rule 10 and Its Rationale

According to the source code in skills/i-have-adhd/SKILL.md (lines 109-117), Rule 10 requires assistants to eliminate opening greetings, closing pleasantries, and conversational filler. This constraint minimizes cognitive load by delivering information immediately. However, the document recognizes that absolute brevity can compromise safety and utility in specific edge cases.

The Six Defined Exceptions to the No Preamble Rule

The "When to break the rules" section of SKILL.md (lines 119-128) lists six scenarios where the no-preamble constraint may be relaxed:

1. Explain-or-Walk-Through Requests

When a user explicitly asks you to "explain" or "walk me through" a topic, you may employ longer, header-rich content structures. While opening pleasantries remain prohibited, the body can include detailed breakdowns and hierarchical sections for skimmability.

# ✅ Allowed (exception 1 – explanation request)

def explain_topic(topic):
    # No opening greeting; jump straight into the explanation.

    # Use headers for skimmability.

    return f"""# Overview

{topic} is ...

# Details

- Point 1 …
- Point 2 …"""

# ❌ Disallowed (violates Rule 10)

def disallowed_greeting():
    return "Sure! Let me explain how this works..."

2. Destructive Actions

Before executing risky operations such as rm -rf, force-pushing to Git, running schema migrations, or dropping database tables, you must confirm the action with the user. Safety overrides brevity in these high-stakes scenarios.

# ✅ Allowed (exception 2 – destructive action)

if user_wants_to_drop_table:
    # Confirm before proceeding

    confirm = input("⚠️ This will delete the table. Type 'yes' to continue:")
    if confirm.lower() == "yes":
        run_sql("DROP TABLE …")

3. Debug Spiral

After three consecutive unsuccessful troubleshooting attempts ("still broken" turns), you must stop iterative guessing. Instead, identify a likely faulty assumption and pose a single diagnostic question to break the cycle.

# ✅ Allowed (exception 3 – debug spiral)

def debug_scenario():
    # After three failed attempts, ask a diagnostic question instead of looping.

    return "I suspect the issue is with the environment variable. Is it set correctly?"

4. Real Ambiguity

When a request contains genuine ambiguity that prevents accurate fulfillment, a short clarifying question takes precedence over attempting to guess the user's intent. This exception prevents incorrect implementations that would require extensive rework.

5. Rule-vs-Task Conflict

If applying the no-preamble rule would literally delete the answer itself—for example, when the requested output is an options list or the preamble constitutes the deliverable—the task requirements override the formatting constraint. The response shape remains intact to satisfy the functional goal.

6. Harness-vs-Skill Conflict

When the surrounding agent harness requires specific tool calls, mandatory phrasing, or protocol-mandated formatting, that external constraint supersedes the "no preamble" rule. The harness requirement wins while preserving the intended semantic shape of the response.

Pre-Send Validation

Even when leveraging these exceptions, the skill mandates a pre-send check (documented in SKILL.md lines 130-138) that strips any residual preamble or closing sentences before transmission. This ensures that exceptions are invoked deliberately rather than through oversight.

Summary

• Rule 10 prohibits preambles and closing pleasantries to maintain ADHD-friendly conciseness.
• Six specific exceptions allow preamble-style content: explanation requests, destructive actions, debug spirals, real ambiguity, rule-task conflicts, and harness-skill conflicts.
• Safety-critical confirmations (destructive actions) always override brevity requirements.
• The pre-send validation step ensures accidental preambles are removed before delivery.

Frequently Asked Questions

When should I use a preamble in the i-have-ADHD skill?

You should only use preamble-style content when one of the six defined exceptions applies—specifically when handling explanation requests, confirming destructive actions, breaking debug spirals, resolving ambiguity, or resolving conflicts between rules and task requirements.

What happens if a task requires a preamble but the rule forbids it?

According to exception 5 (rule-vs-task conflict), the task requirements take precedence. If the deliverable itself is an options list or requires introductory context to function, you preserve the response shape rather than strictly adhering to the formatting constraint.

How does the skill handle destructive commands?

Before executing destructive operations like rm -rf or database drops, you must display a warning and receive explicit confirmation. This exception (exception 2) ensures safety protocols override the brevity mandate.

Where are the no preamble exceptions documented?

All six exceptions are defined in the "When to break the rules" section of skills/i-have-adhd/SKILL.md (lines 119-128), with the core rule defined at lines 109-117 and pre-send validation guidelines at lines 130-138.

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