Sie erhalten von Claude Code zwar Antworten, aber oft erst nach langen Erklärungen, unklaren Annahmen und mehreren Rückfragen.
Die schnellste Lösung: Den i-have-adhd Claude Code Skill zunächst persönlich und mit ungefährlichen Aufgaben testen; migrieren Sie den Workflow erst, wenn Regeln, Projektkontext, Berechtigungen und reproduzierbare Ergebnisse geprüft sind.
Für wen diese Einordnung gedacht ist
Claude-Code-Nutzer erfahren, ob ein „Antwort zuerst, weniger Umwege“-Stil zur eigenen Arbeitsweise passt. Leser, die den AI-Coding-Workflow beobachten, erhalten eine Einordnung der Aufmerksamkeit rund um i-have-adhd statt einer weiteren Installationsanleitung. Kleine Teams können prüfen, ob eine persönliche Regel tatsächlich als gemeinsame Arbeitsnorm taugt.
Stand der Prüfung: 23.09.2026. Der konkrete Ausgangspunkt dieses Beitrags ist das öffentliche Repository ayghri/i-have-adhd. Da mehrere Projekte unter einem ähnlichen Namen kursieren können, dürfen Beschreibung, Skill-Datei, Lizenz und aktuelle Änderungen nicht ungeprüft auf andere Projekte übertragen werden.
Was der i-have-adhd Claude Code Skill tatsächlich verändert
Der Skill ist am besten als Vorgabe für Ausgabe und Interaktion zu verstehen. Er kann beeinflussen, ob Claude Code zuerst eine verwertbare Antwort, eine Entscheidung oder einen nächsten Schritt nennt, bevor ausführliche Begründungen folgen. Genau diese Veränderung erklärt die Aufmerksamkeit: Viele Entwickler verlieren nicht an der Syntax Zeit, sondern an langen Dialogschleifen, wiederholten Kontextangaben und unklaren Abschlussfragen.
Das ist jedoch keine neue Modellfähigkeit. Der Skill trainiert kein Modell, erweitert nicht automatisch das Repository-Verständnis und ersetzt weder Tests noch Code-Review. Die offizielle Einführung in Skills beschreibt sie als wiederverwendbare Anleitungen und Fähigkeiten, die ein Agent bei passenden Aufgaben verwenden kann; sie sind daher eine Steuerungsschicht, keine Garantie für bessere Implementierungen. Die grundlegende Skill-Erklärung ist für diese Abgrenzung wichtiger als Community-Reaktionen.
| Ebene | Wofür sie zuständig ist | Was i-have-adhd davon berührt |
|---|---|---|
| Ausgabe-Stil | Reihenfolge, Kürze, nächste Aktion und Dialogverhalten | Ja, unmittelbar |
| Projektregeln | Architektur, Dateien, Testbefehle und Konventionen | Nur, wenn die Regeln separat hinterlegt und geladen werden |
| Agent Harness | Werkzeuge, Zustände, Schleifen, Berechtigungen und Ausführung | Nein, nicht automatisch |
| Aufgabenverwaltung | Prioritäten, Abhängigkeiten, Status und Übergaben | Nein, dafür ist ein eigener Prozess nötig |
Die zentrale Kauf- und Einführungsentscheidung lautet deshalb nicht „Ist dieser Skill intelligent?“, sondern: Verringert die gewünschte Ausgabeform in Ihrem Projekt nachweisbar Interaktionskosten, ohne wichtige Hinweise zu verlieren?
Kein direkter Beleg für bessere Codequalität
Ein knapperer Einstieg kann die Arbeit angenehmer machen. Er beweist aber nicht, dass der erzeugte Code robuster, sicherer oder wartbarer ist. Ob sich die Qualität verbessert, müssen Sie mit Ihren eigenen Aufgaben prüfen: etwa mit Fehlerbehandlung, bestehenden Tests, Änderungen an mehreren Dateien und einer Aufgabe, deren Anforderungen nicht vollständig im Prompt stehen.
Die offiziellen Hinweise zu CLAUDE.md und zusätzlichem Kontext machen diese Grenze deutlich: Projektkontext muss ausdrücklich und passend bereitgestellt werden. Ein Skill für die Gesprächsform kann fehlende Architekturinformationen nicht ersetzen.
Für Einzelentwickler: weniger Reibung, aber keine Universalantwort
Für eine einzelne Person ist i-have-adhd besonders dann interessant, wenn die eigentliche Blockade in der Kommunikation liegt. Drei typische Situationen sprechen für einen risikoarmen Versuch:
- Sie möchten nach einer Anfrage zuerst eine konkrete Handlungsempfehlung statt einer langen Einleitung.
- Sie benötigen bei kleinen Änderungen einen klaren nächsten Schritt und keine Wiederholung bereits bekannter Informationen.
- Sie arbeiten häufig interaktiv und können sofort erkennen, ob die verkürzte Antwort wichtige Annahmen unterschlägt.
Ein Beispiel: Sie bitten um eine Änderung an einem kleinen API-Modul. Ein gut passender Ausgabestil nennt zuerst die betroffenen Dateien, den vorgeschlagenen Eingriff und den Testbefehl. Danach folgen Begründung und offene Risiken. Das kann die Entscheidung beschleunigen. Es ändert aber nichts daran, ob der Test tatsächlich aussagekräftig ist oder ob eine Randbedingung im Projekt fehlt.
Was ändert i-have-adhd im Claude-Code-Einsatz wirklich? Vor allem die Priorisierung der Information. Der Skill kann Antworten stärker auf Ergebnis, Entscheidung und nächsten Arbeitsschritt ausrichten. Er liefert dadurch nicht automatisch mehr Kontext, bessere Tool-Auswahl oder zuverlässigere Änderungen.
Bevor Sie den Stil übernehmen, sollten Sie Ihr eigentliches Problem bestimmen:
| Beobachtung bei Ihrer Arbeit | Wahrscheinliche Ursache | Passendere Maßnahme |
|---|---|---|
| Antworten sind zu lang, obwohl die Aufgabe klar ist | Ausgabe- und Dialogstil | Skill persönlich testen |
| Claude Code vergisst Architekturentscheidungen | Fehlender oder unklarer Projektkontext | Projektregeln und Kontextdatei überarbeiten |
| Viele Aufgaben bleiben halb fertig | Fehlende Zerlegung und Priorisierung | Aufgabenmanagement oder feste Arbeitsabläufe einführen |
| Shell-Befehle und Sitzungen gehen verloren | Fehlende Terminal- oder Sitzungsorganisation | Arbeitsumgebung und Sitzungsverwaltung prüfen |
| Ergebnisse unterscheiden sich stark | Unklare Anforderungen oder fehlende Tests | Akzeptanzkriterien und Prüfungen definieren |
Die Hinweise zu verifizierbaren Claude-Code-Arbeitsabläufen sind dafür eine bessere Ergänzung als ein blindes Übernehmen von Community-Voreinstellungen. Nutzen Sie den Skill zuerst für Dokumentation, kleine Refactorings oder Testentwürfe. Beginnen Sie nicht mit einer kritischen Migration, einer Bereinigung von Geheimnissen oder einer Änderung an Produktionszugängen.
Für kleine Teams: persönliche Vorliebe wird schnell zur Regel
Ist i-have-adhd für ein Team geeignet? Ja, als kontrollierter Versuch; nein, als sofort verbindlicher Standard. Der Unterschied liegt in der Verbindlichkeit. Ein persönlicher Skill beschreibt, wie Sie Antworten bevorzugen. Eine Teamregel muss zusätzlich erklären, welche Informationen zwingend erscheinen müssen, wann Rückfragen erforderlich sind und wie eine Änderung überprüft wird.
In einem kleinen Team entstehen typischerweise vier Konfliktflächen:
- Die persönliche Skill-Regel verlangt Kürze, während die Projektregel eine ausführliche Begründung für sicherheitsrelevante Änderungen fordert.
- Eine globale Vorgabe wird von einer projektspezifischen
CLAUDE.mdergänzt oder widersprochen. - Weitere Skills bringen eigene Ausgabeformate, Tool-Regeln oder Abschlussbedingungen mit.
- Teammitglieder interpretieren „Antwort zuerst“ unterschiedlich und erhalten dadurch nicht reproduzierbare Ergebnisse.
Die Dokumentation zu Skills, Hooks, Regeln und Subagents hilft bei der Zuständigkeitsklärung. Eine Ausgabepräferenz sollte nicht stillschweigend Architektur, Berechtigungen oder Freigabeprozesse überschreiben.
Ein begrenzter Teamversuch statt Vollmigration
Für einen belastbaren Versuch gehen Sie in dieser Reihenfolge vor:
- Ziel festlegen: Schreiben Sie auf, welche Reibung verschwinden soll: lange Antworten, fehlende nächste Schritte oder unnötige Rückfragen.
- Aufgabenklasse abgrenzen: Wählen Sie eine ungefährliche, wiederkehrende Aufgabe mit vorhandenen Tests. Produktionszugriffe und vertrauliche Daten bleiben zunächst ausgeschlossen.
- Regelbestand aufnehmen: Sichern Sie die aktuelle Projekt-
CLAUDE.md, vorhandene Skills, Hooks und lokale Vorgaben. Ändern Sie nicht mehrere Steuerungsebenen gleichzeitig. - Ausgaben vergleichen: Lassen Sie dieselbe Aufgabenart mit und ohne Skill bearbeiten. Bewerten Sie nicht nur Kürze, sondern auch Annahmen, betroffene Dateien, Testvorschläge und Warnungen.
- Review erzwingen: Eine zweite Person prüft die Änderungen unabhängig vom bevorzugten Antwortstil. Entscheidend ist der Code, nicht das angenehme Gespräch.
- Rollback vorbereiten: Entfernen Sie die Skill-Datei oder deaktivieren Sie ihre Einbindung, falls Regeln kollidieren oder wichtige Hinweise verschwinden.
- Entscheidung dokumentieren: Halten Sie fest, für welche Aufgaben der Skill erlaubt, optional oder ausgeschlossen ist.
| Teamentscheidung | Voraussetzungen | Nächster Schritt |
|---|---|---|
| Persönlich behalten | Die Ausgabe wird klarer, ohne Warnungen zu verlieren | Nur im persönlichen Arbeitsbereich einsetzen |
| Begrenzter Teamversuch | Regeln sind dokumentiert, Reviews bleiben unverändert und Aufgaben sind reproduzierbar | Mit einer definierten Aufgabenklasse starten |
| Als Projektstandard übernehmen | Konflikte sind getestet, Ausnahmen sind beschrieben und Rollback ist möglich | Versionieren und Änderungen reviewen |
| Nicht weiterverwenden | Ergebnisse werden oberflächlicher oder Regeln widersprechen sich | Skill entfernen und Ursache anders lösen |
Kann der Claude Code Skill mit Projektregeln kollidieren? Ja. Besonders kritisch ist eine knappe Antwortvorgabe, wenn das Projekt für Datenbankänderungen, Berechtigungen oder Sicherheitsprüfungen eine vollständige Begründung fordert. In diesem Fall gewinnt nicht die persönlich angenehmere Ausgabeform, sondern die explizite Projektanforderung.
Für Plattformverantwortliche: Cloud-Arbeitsplatz ist kein Sicherheitsautomat
Die Frage nach der Cloud entsteht meist, wenn Sitzungen lange laufen sollen, mehrere Personen dieselbe Umgebung benötigen oder ein Entwickler nicht an einen bestimmten Rechner gebunden sein soll. Ein Cloud-Arbeitsplatz kann dafür Vorteile bieten:
- Eine definierte Entwicklungsumgebung bleibt unabhängig vom lokalen Gerät erreichbar.
- Lang laufende Prozesse müssen nicht an ein offenes Notebook gebunden sein.
- Zugänge, Protokolle und Arbeitsbereiche lassen sich zentraler verwalten.
- Teammitglieder können klarer getrennte Projekte und Berechtigungen erhalten.
- Wiederholbare Umgebungen erleichtern den Vergleich eines AI-Coding-Workflows.
Das ist ein Infrastrukturvorteil, aber keine automatische Übernahme des Arbeitszustands.
Muss ein AI-Coding-Workflow in die Cloud umziehen? Nur wenn kontinuierliche Erreichbarkeit, zentrale Verwaltung, Umgebungsstabilität oder kontrollierte Zusammenarbeit ein konkretes Problem lösen. Wenn Sie lediglich kürzere Antworten wünschen, ist die Cloud die falsche erste Maßnahme.
| Migrationsobjekt | Wird durch das Kopieren einer Skill-Datei gelöst? | Was separat geprüft werden muss |
|---|---|---|
| Ausgabepräferenz | Ja, sofern der Skill korrekt geladen wird | Priorität gegenüber Projekt- und Teamregeln |
| Sitzungszustand | Nein | Wiederaufnahme, Verlauf und lokale Zwischenstände |
| Geheimnisse | Nein | Secret-Management, Rotation und Zugriffstrennung |
| Projektdateien | Nein | Synchronisierung, Git-Strategie und Datenstand |
| Berechtigungen | Nein | Rollen, Netzwerkzugriff und Freigaben |
| Auditierbarkeit | Nein | Protokollierung, Aufbewahrung und Datenschutz |
| Tool-Verfügbarkeit | Nicht automatisch | CLI-Version, Pfade und erlaubte Werkzeuge |
Die CLI-Dokumentation zu Claude Code zeigt, dass Kommandozeilenoptionen und Ausführungsumgebung getrennte Fragen sind. Ebenso warnt die Anleitung zur sicheren Nutzung von Skills davor, fremde oder nicht geprüfte Anweisungen ungeprüft mit weitreichenden Zugriffen zu verbinden.
Hinweis: Eine kopierte Skill-Datei ist kein Migrationsnachweis. Vor der Freigabe müssen Sie testen, welche Dateien geladen werden, welche Werkzeuge erreichbar sind, welche Geheimnisse verfügbar sind und ob Sitzungsprotokolle den Anforderungen der DSGVO entsprechen.
Ein sicherer Übergang in einen entfernten Arbeitsbereich
Wenn die Cloud aus betrieblichen Gründen sinnvoll ist, gehen Sie schrittweise vor:
- Erfassen Sie zuerst die lokale Umgebung: Projektpfade, CLI-Version, installierte Skills, Hooks, Umgebungsvariablen und Git-Zustand.
- Trennen Sie Skill-Dateien von Geheimnissen. API-Schlüssel, Tokens und Zertifikate gehören nicht in ein Repository oder in eine gemeinsam kopierte Konfigurationsdatei.
- Erstellen Sie einen isolierten Arbeitsbereich mit minimalen Rechten. Beginnen Sie ohne Produktionszugriff und ohne unnötige Netzwerkfreigaben.
- Übertragen Sie nur die Projektregeln, die tatsächlich benötigt werden. Persönliche Präferenzen bleiben zunächst außerhalb des Teamstandards.
- Prüfen Sie die Wiederaufnahme einer Sitzung mit einer ungefährlichen Aufgabe. Vergleichen Sie Dateistand, Tool-Verfügbarkeit und Protokollierung.
- Führen Sie einen manuellen Review der ersten Änderungen durch. Automatische Ausführung darf den Review nicht ersetzen.
- Definieren Sie Löschung, Zugriffsentzug und Rückkehr zum lokalen Ablauf, bevor der Arbeitsbereich für weitere Personen geöffnet wird.
Für die organisatorische Seite sollten Sie außerdem dokumentieren, welche Quelltexte, Protokolle und Zugangsdaten einen entfernten Arbeitsbereich betreten dürfen. Die Datenschutzhinweise von Kvmjet können dabei als ergänzende Informationsquelle dienen; sie ersetzen jedoch keine interne Freigabe- und Datenschutzprüfung.
Entscheidung nach Bedingungen statt nach Community-Hitze
Die folgende Entscheidungslogik trennt den persönlichen Versuch vom Teamstandard und von der Cloud-Migration:
- Wenn Sie hauptsächlich unter langen, unpriorisierten Antworten leiden und keine kritischen Zugriffe betroffen sind, dann testen Sie i-have-adhd persönlich.
- Wenn die Antworten zwar angenehmer, aber Projektregeln oder Warnhinweise unvollständig werden, dann behalten Sie den Skill höchstens als persönliche Option und überarbeiten zuerst den Kontext.
- Wenn Ihr Team dieselben Aufgaben mit vergleichbaren Ergebnissen bearbeiten muss, dann führen Sie einen begrenzten Versuch mit Review, dokumentierten Ausnahmen und Rollback durch.
- Wenn persönliche Regeln mit
CLAUDE.md, anderen Skills oder Hooks kollidieren, dann hat die dokumentierte Projektanforderung Vorrang; migrieren Sie nicht einfach die persönliche Datei. - Wenn nur entfernte Erreichbarkeit das Problem ist, dann prüfen Sie einen Cloud-Arbeitsplatz ohne den Skill zum zentralen Sicherheitsmechanismus zu erklären.
- Wenn Geheimnisse, Produktionsdaten oder personenbezogene Informationen betroffen sind, dann stoppen Sie die Migration, bis Berechtigungen, Protokolle und Löschprozesse geprüft sind.
- Wenn eine Aufgabe ohne den Skill genauso zuverlässig und mit weniger Pflegeaufwand gelingt, dann verzichten Sie auf die zusätzliche Regel.
Ein Skill sollte außerdem nicht allein wegen öffentlicher Aufmerksamkeit zum Standard werden. Community-Interesse zeigt, dass ein Problem viele Menschen erkennen; es belegt weder eine bessere Codequalität noch eine passende Teamarchitektur. Für die Produktionsfreigabe brauchen Sie eigene Aufgaben, klare Akzeptanzkriterien und eine nachvollziehbare Prüfung. Eine solche Abnahme sollte als dokumentierter Prozess mit Testfällen, Review und Rückfalloption organisiert werden.
Vom Trend-Skill zum belastbaren AI-Coding-Workflow
i-have-adhd löst eine schmale, aber reale Aufgabe: Es verändert die Kommunikation zwischen Ihnen und Claude Code. Projektregeln definieren dagegen, wie ein Repository bearbeitet werden soll. Skills bündeln wiederverwendbare Arbeitsanweisungen. Ein Agent Harness steuert Werkzeuge, Zustände und Ausführung. Der Cloud-Arbeitsplatz stellt Erreichbarkeit und Umgebungsverwaltung bereit. Code-Review prüft schließlich, ob das Ergebnis akzeptabel ist.
Diese Ebenen sollten Sie nicht vermischen. Wenn ein Entwickler mehr Kontextgedächtnis benötigt, hilft keine reine Stilregel. Wenn mehrere Agenten parallel arbeiten sollen, reicht ein kürzeres Antwortformat nicht aus. Wenn ein Team Geheimnisse und Quelltext zentral verwalten muss, ist eine Skill-Datei kein Ersatz für Zugriffskontrolle und Protokollierung.
Für die nachhaltige Einführung sollten Sie drei Dinge getrennt versionieren: erstens die Skill- und Regeldateien, zweitens die Projektanforderungen und Prüfungen, drittens die Infrastruktur- und Berechtigungsdefinitionen. So können Sie bei einem Konflikt feststellen, ob die Ausgabeform, der Projektkontext oder die Umgebung die Ursache war. Die Verwaltung von Agent-Skills sollte deshalb nicht als Installationsliste, sondern als Änderungs- und Freigabeprozess gelesen werden.
Wenn Ihr aktueller Ablauf auf einem lokalen Rechner funktioniert, die Aufgaben überschaubar sind und keine gemeinsame Sitzung benötigt wird, ist eine Cloud-Migration wahrscheinlich nicht der nächste sinnvolle Schritt. Sie gewinnen dann eher durch klare Aufgaben, geprüfte Projektregeln und einen definierten Review-Prozess. Wenn dagegen Sitzungen dauerhaft erreichbar, Umgebungen einheitlich und Zugriffe zentral steuerbar sein müssen, kann ein zentral verwalteter Cloud-Arbeitsbereich die Infrastrukturseite abdecken. Die Arbeitsregeln, Geheimnisse und Abnahmen müssen Sie trotzdem selbst sauber gestalten.
Die vernünftigste Entscheidung für 2026 lautet daher: i-have-adhd persönlich ausprobieren, seine Wirkung auf Ausgabe und Interaktion messen, es nicht mit besserer Programmierfähigkeit verwechseln und erst nach einem dokumentierten Teamversuch über eine gemeinsame oder cloudbasierte Nutzung entscheiden.
Ihr nächster Schritt: Workflow und Sicherheitsgrenzen prüfen
Lesen Sie als Nächstes unsere technischen Leitfäden zu Agenten-Workflows und prüfen Sie, welche Aufgaben in Ihrem Entwicklungsprozess tatsächlich Reibung verursachen.
Testen Sie Sitzungswiederherstellung, Versionsverwaltung und Backups zunächst mit einem kleinen, klar abgegrenzten Projekt, bevor Sie den gesamten Workflow migrieren.