# How to State Errors in i-have-adhd Responses: A Matter-of-Fact Guide

> Learn to state errors in i-have-adhd responses factually. Understand failures, causes, and fixes clearly and concisely for effective communication. Improve your error reporting now.

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

---

**To state errors in i-have-adhd responses, use a matter-of-fact tone that states the exact failure, underlying cause, and immediate fix without emotional filler or tentative language.**

The `ayghri/i-have-adhd` repository defines a strict communication skill designed to reduce cognitive load for readers with ADHD. When learning how to state errors in i-have-adhd responses, you must follow the dedicated *Matter-of-fact tone for errors* rule documented in [`SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/SKILL.md), which treats technical failures as factual statements rather than emotional events.

## The Matter-of-Fact Tone Rule for Errors

According to the source code in [`SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/SKILL.md), the *Matter-of-fact tone for errors* rule requires you to **state the cause and the fix directly**. This means eliminating phrases like "Uh-oh" or "There seems to be a problem" from your vocabulary when describing failures.

The [`README.md`](https://github.com/ayghri/i-have-adhd/blob/main/README.md) establishes that this repository aims to **lead with the next action** and **avoid tangential or emotive language**. By presenting errors as neutral, actionable facts, you accommodate readers with ADHD who process concrete information more efficiently than emotionally loaded or speculative statements.

## Anatomy of an Error Statement

Every error statement in the i-have-adhd style follows a rigid three-part structure designed for immediate comprehension:

### Identify the Exact Point of Failure

Specify the precise location and nature of the error. Include file paths, line numbers, test names, or API endpoints where the failure occurs.

### Explain the Underlying Cause

State the root technical reason for the failure in plain terms. Avoid hedging or softening phrases—state what happened factually.

### Provide the Immediate Fix

Conclude with a concrete, implementable solution that the reader can execute immediately. This aligns with the skill's core goal of leading with actionable next steps.

## Error Statement Examples

The following examples demonstrate the contrast between ineffective emotional phrasing and the correct matter-of-fact approach required by the i-have-adhd skill.

Avoid emotional or tentative language:

```text
Uh oh, the test is failing. There seems to be an issue…

```

Use factual, structured statements:

```text
Test fails at auth.spec.ts:42: expected 200, got 401. Cause: missing auth header. Fix: add Authorization: Bearer ${token} to the request.

```

For compilation errors:

```text
Compilation error in src/server.ts line 27: undefined variable `config`. Fix: import the missing config module or define the variable before use.

```

For runtime errors:

```text
Runtime error: ConnectionTimeout after 30s while contacting the API endpoint. Fix: increase the timeout setting or verify network connectivity.

```

## Summary

- **Reference [`SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/SKILL.md)**: The *Matter-of-fact tone for errors* rule in [`SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/SKILL.md) defines the canonical approach for error statements in this repository.
- **Eliminate emotional filler**: Remove phrases like "Uh-oh" and "There seems to be a problem" from error messages entirely.
- **Structure every statement**: Include the exact failure point, underlying cause, and immediate fix in that order.
- **Support accessibility**: This factual approach reduces cognitive load by delivering concrete information without sentiment or speculation.

## Frequently Asked Questions

### Where is the error statement rule documented in i-have-adhd?

The rule is documented in the [`SKILL.md`](https://github.com/ayghri/i-have-adhd/blob/main/SKILL.md) file under the section titled *Matter-of-fact tone for errors*. This file serves as the canonical skill definition for the repository and contains the specific guidelines for formatting error messages.

### Why does i-have-adhd require a matter-of-fact tone for errors?

The requirement accommodates readers with ADHD, who benefit from clear, concrete information without emotional distraction. Factual statements minimize anxiety and cognitive overhead, allowing users to focus immediately on the solution rather than processing emotional context or uncertainty.

### Can I use tentative language like "might be" or "possibly" when stating errors?

No. Tentative language violates the matter-of-fact rule. Instead, state what you know definitively about the cause and the fix. If the exact cause is temporarily unknown, state that the cause requires identification and provide the specific next diagnostic step to take.

### How should I format runtime errors versus compile-time errors in this style?

Both error types follow the identical three-part structure. For runtime errors, specify the exception type, duration (if applicable), and affected component. For compile-time errors, include the file path and line number. Always conclude with the specific fix action, such as adjusting a configuration setting or importing a missing module.