i-have-adhd Time Estimation Guidelines: The Rule for Concrete Duration Estimates

The i-have-adhd skill requires all time estimates to use specific units like minutes or hours, explicitly banning vague phrases such as "a bit" or "some time" to make plans actionable for readers with ADHD.

The ayghri/i-have-adhd repository defines strict communication guidelines designed to reduce cognitive friction for developers with ADHD. One of the most critical constraints involves i-have-adhd time estimation guidelines, which enforce concrete duration statements instead of ambiguous temporal language.

Rule 6: Give Specific Time Estimates

According to the authoritative skill definition in skills/i-have-adhd/SKILL.md (lines 84-90), the sixth rule mandates that all estimates must be expressed in concrete units. The guideline explicitly states: "Give specific time estimates."

This requirement means you must use minutes, hours, days, or other measurable units. The documentation in README.md (lines 94-95) reinforces this by summarizing the rule as "Specific time estimates (minutes, not 'a bit')".

What to Avoid in Time Estimates

The guidelines prohibit ambiguous adjectives that create uncertainty. Terms like "a bit," "some work," "a while," or "soon" violate the concrete unit requirement.

As noted in the skill configuration files, this rule is stringent. The skills/i-have-adhd/agents/gemini.toml file (line 15) reiterates the same requirement for AI agents, ensuring automated responses also comply with the specific duration format.

The Reference Pattern for Good Estimates

The canonical example provided in skills/i-have-adhd/SKILL.md demonstrates the expected format:

About 15 minutes if tests already cover this. An afternoon if not.

This pattern shows three critical elements:

  • Specific units (minutes, afternoon as shorthand for hours)
  • Conditional branches (if tests exist vs. if not)
  • Concrete ranges (15 minutes vs. implied 3-4 hours)

How to Write Compliant Time Estimates

In practice, every time estimate should follow this structure:

  1. State the precise unit (minutes / hours / days)
  2. Eliminate ambiguous adjectives ("quick," "short," "long")
  3. Provide concrete ranges when uncertainty exists

Examples of Correct and Incorrect Usage

Correct: Specific duration with units

1. Open `src/auth.ts`
2. Replace the `verifyToken` function
3. Run `npm test`

⏱️ About 12 minutes if tests already exist; up to 30 minutes if you need to write new tests.

Incorrect: Vague phrasing

⏱️ A bit of work.

Correct: Hours for larger tasks

⏱️ Roughly 2 hours to refactor the middleware and update the documentation.

Implementation Across the Repository

The time estimation rule is enforced across multiple files in the codebase:

  • skills/i-have-adhd/SKILL.md (lines 84-90): Contains the authoritative Rule 6 definition and the reference example using the 15-minute/afternoon pattern.
  • README.md (lines 94-95): Summarizes the requirement for end users, explicitly contrasting "minutes" against prohibited vague terms.
  • skills/i-have-adhd/agents/gemini.toml (line 15): Repeats the guideline to ensure the Gemini agent generates compliant time estimates in automated responses.

Summary

  • i-have-adhd time estimation guidelines require concrete units (minutes, hours, days) in all duration statements.
  • Vague descriptors like "a bit" or "some time" are explicitly prohibited according to README.md and SKILL.md.
  • Good estimates provide specific ranges and conditional branches, such as "About 15 minutes if tests already cover this."
  • The rule is enforced across the repository in skill definitions, documentation, and agent configuration files.

Frequently Asked Questions

What units are acceptable under the i-have-adhd time estimation guidelines?

The guidelines accept any concrete temporal unit including minutes, hours, days, or weeks. According to skills/i-have-adhd/SKILL.md, the key requirement is specificity—you must avoid abstract terms in favor of measurable durations.

How should I estimate time when I am uncertain about the scope?

Provide a concrete range with conditions. The reference implementation in SKILL.md recommends the pattern: "About 15 minutes if tests already cover this. An afternoon if not." This gives two specific anchors based on different scenarios.

Where is the time estimation rule formally defined?

Rule 6 is formally defined in skills/i-have-adhd/SKILL.md at lines 84-90, with additional reinforcement in README.md (lines 94-95) and the Gemini agent configuration at skills/i-have-adhd/agents/gemini.toml (line 15).

Why does the i-have-adhd skill ban vague time estimates?

Vague temporal language ("a bit," "some work") creates cognitive friction for individuals with ADHD by failing to provide concrete planning anchors. Specific units (minutes, hours) make plans immediately actionable and reduce the decision paralysis associated with ambiguous timeframes.

Have a question about this repo?

These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:

Share the following with your agent to get started:
curl -s "https://instagit.com/install.md"

Works with
Claude Codex Cursor VS Code OpenClaw Any MCP Client

Maintain an open-source project? Get it listed too →