The Practical Boundary of Low-Friction AI
ayghri/i-have-adhd answers the opening question with an engineered compromise: make an assistant’s next useful action, current state, and relevant boundary visible, then carry that response policy through the runtime that can actually preserve it. The project is worth judging as a system, not as a list of ten stylistic preferences. This final synthesis connects the policy, its adapters, its tests, and its recorded evaluation to a practical decision: when does the project reduce execution friction, and when must detail, safety, uncertainty, or user control take precedence?
What the project actually changes
The strongest defensible claim is modest but meaningful. i-have-adhd changes the interface between an assistant’s knowledge and a reader’s next move. It asks the assistant to lead with the action when the action is known, break multi-step work into bounded units, restate state across turns, give concrete estimates, show completed work, suppress unrelated issues, and end with one useful next transition. It does not make the underlying code, environment, or diagnosis more correct. It changes where the information needed for execution appears and how it remains visible.
That policy works as a chain. A first action reduces the work required to begin. A bounded sequence prevents hidden branching. A state report tells the reader what has already changed and what remains. A concrete estimate sizes the immediate commitment. Verification separates a tested result from an intention. A next action keeps the task from falling back into an unranked menu. The project’s response rules are coherent because they address successive transitions through a task rather than optimizing isolated sentences.
The repository then treats the policy as a portable system. A canonical skill owns the behavior. Runtime adapters expose commands, hooks, context files, or extensions. Some integrations inject the rules at session boundaries. Pi/OMP stores a session choice, shows status, and uses active or disabled markers to keep context synchronized. OpenCode registers discovery surfaces and can transform the system prompt on every turn. Tests and CI inspect the seams: whether the host loads, whether a command remains discoverable, whether a mirror is synchronized, whether a reload duplicates the rules, and whether an optional failure blocks startup.
This separation is the project’s central engineering insight. A response rule and a runtime lifecycle are different problems. Keeping them separate lets a policy change remain a policy change, while a host-specific adapter can account for session events, context loss, command discovery, or prompt construction. It also exposes the maintenance cost instead of hiding it. The real Cursor copy must stay synchronized. A new integration needs documentation and an off path. A context API can change the duplicate-prevention logic. A global install can reveal a command-discovery gap that a project-local installation never showed.
The result is not uniform behavior in every host. It is a common policy with host-specific conditions. That distinction matters to both users and maintainers. A reader should know whether the mode is invoked explicitly, activated by an opt-in flag, or applied through a host’s native context mechanism. A maintainer should know which component owns the state and which test can demonstrate that the state survives a reload or compaction.
Where the promise stops
The project’s design is strongest when it removes avoidable friction without treating necessary friction as a defect. A preamble that delays a known command is avoidable. A confirmation before deleting data is necessary. A long explanation that the reader explicitly requested is necessary. A question about an unknown production target is necessary. A state report that repeats the current transition is useful; a recap that merely restates the conclusion is not.