ADHD: divergente Ideation als Skill für Coding-Agents

Das Problem ist die Verankerung, nicht die Prompt-Qualität

Das README benennt den Ausgangspunkt klar: Lineare Chain-of-Thought ankert auf dem, was sie zuerst sagt. Tree-of-Thought verbreitert die Suche, läuft aber weiter über einen gemeinsamen Kontext, weshalb die Verankerung über die Zweige hinweg bestehen bleibt. ADHD behandelt das laut eigener Formulierung als architektonisches Problem, nicht als Prompting-Problem. Der Unterschied ist praktisch: Ein besserer Prompt ändert nichts daran, dass alle Zweige denselben Gesprächsverlauf sehen. Isolierte Prozesse ohne geteilten Kontext ändern genau das.

Die Zielgruppe ist enger, als der Name vermuten lässt. Das README nennt Designentscheidungen, unscharfes Debugging, Namensgebung, API-Surface-Design, Strategie und Prompts der Form "give me a few ways to". Das sind Aufgaben, bei denen die erste plausible Antwort nicht die beste ist und der Suchraum nicht durch eine einzige richtige Lösung begrenzt wird. Für eine Rechenaufgabe mit eindeutigem Ergebnis ist das Verfahren strukturell ungeeignet.

Sechs Frames, kein geteilter Kontext, ein separater Critic

Der Ablauf, wie ihn das Repository beschreibt: In der Divergenzphase werden N isolierte Reasoning-Prozesse gestartet, jeder unter einem bewusst verzerrten kognitiven Frame, ohne gemeinsamen Kontext. Im dokumentierten Beispiel sind es sechs Frames, die Cluster tragen Namen wie economic-incentive, async-control-surface, gamification, perceptual-distortion, collective-intelligence und redundancy-race. Danach folgt ein getrennter Critic-Pass, der bewertet, clustert, Fallen pruned und die Überlebenden vertieft.

Bemerkenswert ist die Reihenfolge. Das Pruning kommt nach der Breite, nicht davor. Im Beispiel werden über 30 Ideen erzeugt und anschließend 20 Fallen mit einzeiliger Begründung markiert, darunter Vorschläge wie "stream tokens in reverse" oder "patience-token billing". Der Sinn dieser Anordnung: Eine Idee wird nicht danach beurteilt, ob sie beim ersten Lesen seriös klingt, sondern danach, ob sie einem Frame entsprungen ist, der sie überhaupt hervorbringen konnte. Der Critic-Pass ist damit kein Qualitätsfilter über Ideen, sondern eine zweite Modellrunde über bereits erzeugtem Material.

Die eigentliche Architekturfrage steckt in der Isolation. Ohne geteilten Kontext kann kein Zweig vom Fund eines anderen profitieren. Das ist gewollt, kostet aber Redundanz: Zwei Frames können unabhängig auf dieselbe Lösung kommen, und der Critic-Pass muss diese Dubletten wieder zusammenführen. Genau dafür existiert das Clustering im Bewertungsschritt.

Installation über npx skills add, Node 18 als Untergrenze

Der Installationsweg ist eine Zeile: npx skills add UditAkhourii/adhd. Laut README erkennt der Befehl den Agenten automatisch und unterstützt Claude Code, Cursor, Antigravity, Codex, Cline, Gemini CLI, Windsurf und rund 50 weitere. Aufgerufen wird der Skill anschließend explizit über einen Slash-Befehl, im abgeschnittenen README sichtbar als /ad. Die vollständige Schreibweise lässt sich aus dem vorliegenden Material nicht bestätigen.

Die Laufzeitumgebung ist Node mit Version 18 oder höher, das zeigt das Node-Badge auf ./documentation/install.md. Die Implementierung ist TypeScript, das Paket liegt auf npm unter adhd-agent. Wer die Version prüfen will, findet sie über npm v adhd-agent oder direkt im npm-Paket. Für die Konfiguration selbst nennt das vorliegende Material keine Keys; die Dokumentation liegt unter adhd.mintlify.site, und dort wäre vor einem produktiven Einsatz zu klären, wie viele Frames konfigurierbar sind und ob die Frame-Namen fest verdrahtet oder austauschbar sind.

Ein Punkt, der in der README-Schreibweise untergeht: Das Projekt beschreibt sich als Skill, nicht als Bibliothek. Der Unterschied ist praktisch relevant. Ein Skill wird vom Agenten aufgerufen, nicht von eigenem Code importiert. Wer ADHD programmatisch in eine eigene Pipeline einbetten will, findet im vorliegenden Material keinen Hinweis auf eine stabile API-Oberfläche dafür. Der Adoptionsweg des Projekts repowire deutet laut README auf eine Portierung auf eigene Mesh-Orchestrator-Primitive hin, nicht auf einen direkten Bibliotheksaufruf.

Was der Eval-Vergleich zeigt und was er nicht zeigt

Das README dokumentiert ein Side-by-side an einem Problem: eine CLI, die einen LLM aufruft und gelegentlich 90 Sekunden hängt, gesucht ist eine Retry-, Timeout- und UX-Strategie. Der Baseline-Ansatz liefert die Lehrbuchantwort mit gestaffelten Timeouts und einem automatischen Retry. Der ADHD-Lauf liefert unter anderem den Vorschlag, den langsamen Aufruf sofort abzubrechen und auf ein schnelleres Modell zu wechseln, mit der Begründung, das langsame Modell könne schlicht das falsche für diesen Prompt sein.

Die Zahlen dazu stammen aus einem unabhängigen LLM-Judge: Breite 9 gegen 6, Neuheit 8 gegen 3, Trap-Erkennung etwa 8 gegen etwa 2. Die Methodik liegt in documentation/evals.md. Das ist ein Einzelfall mit einem Richter, der selbst ein Sprachmodell ist. Wer aus diesen Zahlen eine allgemeine Überlegenheit ableitet, überdehnt die Datenlage. Die Transkripte liegen in bench/results.json und sind damit nachprüfbar, was mehr ist, als viele Projekte dieser Art bieten.

Interessanter als die Punktzahlen ist der qualitative Unterschied. Beide Ansätze finden die vernünftige Lösung. ADHD findet zusätzlich diejenige, die der Baseline-Frame strukturell ausschließt, weil sie die Prämisse "warte und versuche es erneut" in Frage stellt. Ob dieser Zusatznutzen die zusätzlichen Modellaufrufe rechtfertigt, hängt davon ab, wie teuer eine falsche Designentscheidung im jeweiligen Projekt ist.

Die Frames sind der Engpass, nicht die Anzahl der Ideen

Die Methode steht und fällt mit der Qualität der kognitiven Frames. Sechs Frames, die alle aus derselben Denkrichtung stammen, erzeugen sechs Varianten derselben Antwort. Das README nennt die Frame-Namen im Beispiel, macht aber nicht deutlich, woher sie kommen: ob sie fest im Skill hinterlegt sind, pro Aufgabe generiert werden oder vom Nutzer vorgegeben werden können. Das ist die wichtigste offene Frage für jeden, der den Skill produktiv einsetzen will, und sie lässt sich aus dem vorliegenden Material nicht beantworten.

Dazu kommt ein Kostenproblem. Jeder Frame ist ein eigener Reasoning-Prozess, der Critic-Pass ist ein weiterer Durchlauf über das gesamte Material. Bei sechs Frames entstehen mindestens sieben Modellaufrufe für eine Frage, die ein einzelner Aufruf beantworten könnte. Das ist kein Fehler, sondern der Preis der Architektur. Wer den Skill in einem Kontext mit knappem Token-Budget oder harten Latenzgrenzen betreibt, sollte das vorher durchrechnen.

Ein zweiter Grenzfall: Das Verfahren liefert bewusst eine breite Menge statt einer Antwort. Wer eine Entscheidung treffen will, muss sie danach selbst treffen. Das README beschreibt den Critic-Pass als bewertend und prunend, aber die endgültige Auswahl bleibt beim Nutzer. Für Teams, die eine Empfehlung mit klarer Begründung brauchen und nicht einen Ideenraum mit 30 Einträgen, ist das der falsche Werkzeugtyp.

Abgrenzung zu Tree-of-Thought und zu Multi-Agent-Frameworks

Die nächste echte Alternative ist Tree-of-Thought in seiner üblichen Form: mehrere Kandidatenpfade, bewertet und verfolgt in einem gemeinsamen Kontext. Der Unterschied liegt genau in diesem gemeinsamen Kontext. ToT kann einen vielversprechenden Zweig verfolgen und dabei auf Informationen aus anderen Zweigen zurückgreifen, was bei Aufgaben mit Zwischenergebnissen ein Vorteil ist. ADHD gibt diese Möglichkeit bewusst auf, um die Verankerung zu brechen. Für eine Suchaufgabe mit schrittweise verfeinerbarer Lösung ist ToT deshalb die passendere Wahl, für eine offene Designfrage mit mehreren unvereinbaren Grundannahmen eher ADHD.

Die zweite Abgrenzung betrifft Multi-Agent-Orchestrierung. Frameworks wie das im README genannte repowire verteilen Aufgaben auf mehrere Agenten mit eigenen Rollen und einem gemeinsamen Auftrag. ADHD verteilt nicht Aufgaben, sondern Perspektiven auf dieselbe Frage, und die Perspektiven sind absichtlich verzerrt. Der Unterschied ist nicht graduell. Ein Multi-Agent-System, in dem alle Agenten dieselbe Aufgabe aus derselben Richtung bearbeiten, erzeugt keine Divergenz, sondern Parallelität.

Bemerkenswert ist, dass repowire ADHD laut README auf seine eigenen Mesh-Orchestrator-Primitive portiert hat, statt den Skill unverändert zu übernehmen. Das deutet darauf hin, dass die Methode unabhängig von der konkreten Implementierung übertragbar ist. Für Bewertungszwecke heißt das: Wer die Idee prüfen will, ist nicht zwingend an dieses npm-Paket gebunden.

Wartung, Lizenz und offene Punkte vor der Adoption

Der letzte Push liegt bei August 2026, die letzte Release ist v0.1.4 vom Mai 2026 mit den Notizen "Community is open, Codex compatibility, first OSS adopter". Eine 0.1.x-Version mit einer Release in diesem Zeitraum bedeutet: Die Oberfläche kann sich ändern, und Upgrade-Kosten sind einzuplanen. Wer den Skill in einen kritischen Workflow einbaut, sollte die Version pinnen und die Release-Notes vor jedem Sprung lesen.

Die Lizenz ist MIT, angegeben über das LICENSE-File im Repository. Das erlaubt kommerzielle Nutzung und Modifikation unter Beibehaltung des Copyright-Hinweises. Das ist eine technische Einordnung, keine Rechtsberatung; wer den Skill in ein Produkt einbettet, sollte die Haftungs- und Attributionsfragen mit der eigenen Rechtsabteilung klären.

Das Repository verweist auf eine Preprint-Veröffentlichung unter adhdstack.github.io und auf eine unabhängige evidenzbasierte Recherche mit 11 Quellen und 8 Validierungsrunden, deren Ergebnisse als Issues #16 bis #18 offen verfolgt werden. Das ist ein ungewöhnlich transparenter Umgang mit externer Prüfung, aber es bleibt ein Preprint, kein begutachteter Artikel. Wer die Methode wegen ihrer theoretischen Fundierung einsetzen will, sollte diese Einschränkung kennen. Die praktisch wichtigste offene Frage bleibt, ob die Frames konfigurierbar sind; das entscheidet darüber, ob der Skill für ein spezifisches Problem nützlich ist oder nur für die im README genannten Beispielklassen.

Redaktionelles Fazit

ADHD gehört in Workflows, in denen die erste plausible Antwort teuer ist: API-Design, Namensgebung, Strategie, unscharfes Debugging. Wer deterministische, reproduzierbare Ausgaben braucht oder pro Anfrage nur ein knappes Budget hat, sollte es nicht einsetzen, weil der Critic-Pass zusätzliche Modellaufrufe kostet. Vor dem Adoptionstest ist zu prüfen, wie viele Frames der eigene Agent parallel öffnen kann, ob der eigene Agent in der Autodetect-Liste steht, und ob die im Repository dokumentierten Trap-Kategorien zu den eigenen Fehlklassen passen.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. UditAkhourii/adhd on GitHub