Erstelle Claude Code IDE Workspace Mods

Dies wird dein Terminal in eine ultraschnelle Claude-Code-App verwandeln <role> Du bist ein leitender TypeScript-Ingenieur. Du baust Claude-Code-Mods. Du schreibst kleine Module, du testest jedes Modul, und du berichtest nur Ergebnisse, die du verifiziert hast. </role> <variables> AUTHOR_NAME = "Dein öffentlicher Name" MARKETPLACE =="dein-marktplatz-name" LICENSE =="MIT" PANE_COLUMNS = 48 </variables> <context> Ein Mod ist ein Claude-Code-Plugin. Die Datei hooks/hooks.json benennt ein Hooks-Modul. Das Hooks-Modul exportiert register(on, options). Jeder Hook ist on('event', matcher, async ($, e, next) => result). "$" ist die Mods-API. "e" ist das Ereignis. "next(e)" führt die anderen Mods aus und dann Claude Code. Ich möchte einen IDE-artigen Arbeitsbereich innerhalb einer Claude-Code-Terminalsitzung. Leute lesen Dateien, suchen, sehen Diffs, führen Aufgaben aus, und wechseln zwischen Sitzungen ohne zweites Fenster. Andere Leute werden diese Mods von einem öffentlichen Marktplatz installieren, also müssen die Mods auf einem sauberen Rechner laden und dürfen nicht fehlschlagen, wenn ein Werkzeug (git, rg, cargo) fehlt. Offizielle Dokumentation (lies die Seiten, die du brauchst): - https://t.co/i4akoKobgO - https://t.co/WPCOsxEplS - https://t.co/IeRIo28W71 - https://t.co/bQM1hlDd5j - Eingebauter Mod-Quellcode: https://t.co/XYpFTigXbE (lies "diff" zuerst; es ist ein Bereich mit Knöpfen und eigenem Scrollen) </context> <source_of_truth> Die Mods-API ändert sich zwischen Versionen. Verwende diese Reihenfolge, wenn zwei Quellen nicht übereinstimmen: 1. Die Typdeklarationen, die Claude Code in .claude-plugin/types/ von jedem Mod schreibt. Diese beschreiben die installierte Version. 2. Die Ausgabe von "claude plugin validate". 3. Die Dokumentationsseiten. 4. Diese Eingabeaufforderung. Führe /plugin-authoring aus, bevor du Code schreibst. Lies claude-code/index.d.ts, bevor du ein Ereignis, eine Methode, ein Element oder eine Eigenschaft verwendest. Suche in dieser Datei nach dem Namen. Verwende keinen Namen, der nicht in dieser Datei ist. Wenn diese Eingabeaufforderung etwas benennt, das die installierte Version nicht hat, erfinde keinen Ersatz. Baue die nächste Version, die die API unterstützt, und notiere den Unterschied in LIMITS.md. </source_of_truth> <api_rules> Claude Code macht statische Analyse am Hooks-Modul. Diese Regeln halten die Validierung grün: - Schreibe jeden API-Aufruf vollständig: $.fs.read(...), $.ui.open(...). Weise "$" oder einen Namensraum keiner Variable zu. Destrukturiere "$" nicht. - Übergib "$" nur an eine Funktion, die auf der obersten Ebene derselben Datei deklariert ist. Übergib "$" nicht an eine importierte Funktion, eine Methode oder eine Funktion, die innerhalb eines Hooks definiert ist. - Schreibe jeden Ereignisnamen als Zeichenfolgenliteral in on(...). Schleife nicht über eine Liste von Ereignisnamen. - Deklariere keine zweite Variable namens "on" innerhalb von register. - Verwende ES-Module. Verwende Importdeklarationen am Anfang der Datei. Kein require. Kein dynamisches import(). - Importiere nur Dateien innerhalb des Plugin-Verzeichnisses, über relative Pfade. Der einzige bloße Import ist "claude-code". - Beginne einen Plugin-Namen nicht mit "claude-". Ergebnis: Behalte jeden "$"-Aufruf im Hooks-Modul. Lege reine Logik (Parser, Baummodell, Suchranking, Formatierer) in separate Dateien, die einfache Daten nehmen und einfache Daten zurückgeben. Teste die reinen Dateien direkt. Grenzen zum Entwerfen: - Ein Hook hat 10 Sekunden eigener Ausführungszeit. - $.fs.read und $.fs.write: 4 MiB für eine Datei. Ein Textstring und ein Code-Element: 10,000 Zeichen. Lange Dateien seitenweise. - $.store: 4 MiB JSON insgesamt, geteilt von allen Sitzungen auf dem Rechner. Gib jedem Element seinen eigenen Schlüssel. Begrenze jede Liste. - $.process.run: 30 Sekunden standardmäßig. - Neuzeichnungen: 30 pro Sekunde für den sichtbaren Bereich, 10 für andere Stellen. - Ein Bereich, den ein Mod von selbst öffnet, erscheint nur bei 144 Spalten oder mehr. Ein Bereich, den ein Benutzerbefehl oder Tastendruck öffnet, erscheint bei jeder Breite. Öffne Bereiche von Befehlen und Tasten. Tastaturregeln: - Ein Mod kann Tab oder die Pfeiltasten nicht binden. Tab bewegt zwischen Steuerelementen. Hoch und Runter bewegen zwischen Steuerelementen oder scrollen. - Ein Schaltflächen-Hotkey ist eine Ziffer oder ein Kleinbuchstabe. Während ein Eingabefeld den Fokus hat, geht jedes druckbare Zeichen zum Eingabefeld. - Gib jedem Steuerelement einen eindeutigen Schlüssel. Tests drücken Steuerelemente per Schlüssel. - Claude Code hat kein Registerkarten-Element. Zeichne Registerkarten als eine Reihe von einfachen Schaltflächen. Zustand: - Modulvariable: bei jedem Neuladen verloren. Verwende für Werte, die verloren gehen können. - $.state: hält für die Sitzung und zeichnet die Stellen neu, die den Wert lesen. Deklariere jeden Wert in types/index.d.ts und benenne diese Datei im Manifest. - $.store: hält zwischen Sitzungen. Verwende für Einstellungen, letzte Sitzungen, und Projekte. </api_rules> <repository_layout> .claude-plugin/marketplace.json ein Eintrag für jedes Plugin, Marktplatzname = MARKETPLACE plugins/file-explorer/ plugins/workspace/ plugins/ide-usage/ plugins/ide-statusbar/ README.md LICENSE PROGRESS.md LIMITS.md tests.json Jedes Plugin: .claude-plugin/plugin.json Name, Version 0.1.0, Beschreibung, Autor = AUTHOR_NAME, Lizenz = LICENSE, Typen bei Bedarf hooks/hooks.json { "modules": ["./register.ts"] } hooks/register.ts die einzige Datei, die "$" aufruft hooks/lib/*.ts reine Logik types/index.d.ts PluginState und jeder Namensraum, den das Mod hinzufügt tests/*.test.ts Tests für "claude plugin test" </repository_layout> <mod name="file-explorer"> Befehl: /explorer öffnet den Bereich (id "explorer", Titel "Explorer", Fokus true, Spalten PANE_COLUMNS. Registriere den Befehl mit immediate: true, damit er während eines Zuges funktioniert. Ein zweites /explorer schließt den Bereich. /explorer <pfad> öffnet diesen Pfad. Kopfzeile: das Wort EXPLORER, dann Zurück, Vorwärts, Hoch, Schließen. Zurück und Vorwärts bewegen sich durch die Geschichte der geöffneten Ordner und Dateien. Ein Eingabefeld unter der Kopfzeile. Sein Zweck ändert sich mit der Registerkarte: - Registerkarte Dateien: Platzhalter "Dateien finden". Eingabe sucht Dateinamen und Pfade unterhalb der Wurzel. Die Suche ignoriert Groß-/Kleinschreibung. Stopp bei 500 Übereinstimmungen und zeige: N Dateien entsprechen "Abfrage" (erste 500, Scan gestoppt. Zeige die Übereinstimmungen als Baum mit ihren übergeordneten Ordnern. Markiere den übereinstimmenden Text. Eine leere Abfrage stellt den Baum wieder her. - Registerkarte Code: Platzhalter "Finden in Datei, :Zeile, oder /regex/". Klartext findet jedes Vorkommen. ":42" geht zu Zeile 42. "/re/" verwendet einen regulären Ausdruck. Zeige "Übereinstimmung 2 von 5". Schaltflächen n und p gehen zur nächsten und zur vorherigen Übereinstimmung. Registerkarten: Dateien, Code, Diff. Registerkarte Dateien: - Wurzellinie: der Ordnername der Wurzel und der vollständige Pfad. Die erste Wurzel ist der Arbeitsordner der Sitzung. Hoch bewegt die Wurzel zum übergeordneten Ordner. - Aktionszeile: Neue Datei, Neuer Ordner, Aktualisieren, Einklappen, Mehr. Neue Datei und Neuer Ordner fragen nach einem Namen mit einem Eingabefeld und erstellen das Element im ausgewählten Ordner. Mehr enthält Umbenennen, Löschen, Pfad kopieren, und Versteckte Dateien zeigen. Löschen fragt nach Bestätigung mit $.ui.ask. - Baum: lies eine Ordnerebene, wenn der Benutzer diesen Ordner öffnet. Sortiere Ordner zuerst, dann Dateien, nach Namen. Zeige einen Marker für den Ordnerzustand, ein kurzes Typ-Tag für bekannte Dateitypen (json, md, ts, js, py, rs, go, sh), und "Name → Ziel" für einen symbolischen Link. Zeige "(leer)" in einem leeren Ordner. Überspringe .git und node_modules, außer versteckte Dateien sind an. - Auswahl und Seitierung: eine ausgewählte Zeile. Schaltflächen bewegen die Auswahl hoch und runter, öffnen einen Ordner, schließen einen Ordner,und öffnen eine Datei. Zeige den Bereich, zum Beispiel "7-49 von 329". Zeichne nur die Zeilen, die in e.props.scroll.bodyRows passen. Registerkarte Code: - Breadcrumb des Pfads, dann "N Zeilen · Größe". - Zeilennummern und Syntaxfarben. Verwende das Code-Element. Seite die Datei, sodass kein Element größer als 10,000 Zeichen ist. - Für eine Datei größer als 4 MiB oder eine Binärdatei, zeige die Größe und eine Nachricht. Lies die Datei nicht. - Markiere die aktuelle Übereinstimmung und die aktuelle Zeile. Registerkarte Diff: - Zeige den nicht committeten Diff der geöffneten Datei (git diff für diesen Pfad. Verwende das Code-Element im Diff-Modus. - Zeige die Anzahl der hinzugefügten und entfernten Zeilen. - Wenn Claude eine Datei mit Edit, Write oder MultiEdit bearbeitet, zeichne den Pfad im https://t.co/Lb6btDn0iW-Hook auf, nachdem next(e) zurückkehrt. Wenn der Bereich offen ist, wähle diese Datei aus und zeige die Registerkarte Diff. Öffne den Bereich nicht von selbst. - Wenn der Ordner kein Git-Repository ist, sage das in einer Zeile. Andere Mods öffnen eine Datei über einen Namensraum, den dieses Mod zur Mods-API hinzufügt: https://t.co/crzRXVIH3H({ pfad, zeile, registerkarte }. Deklariere den Namensraum in types/index.d.ts. Lies das "telemetry"-eingebaute Mod, um zu sehen, wie ein Mod Methoden für andere Mods hinzufügt. </mod> <mod name="workspace"> Hängt von file-explorer ab (liste es unter Abhängigkeiten in plugin.json. Befehl: /workspace öffnet den Navigationsbereich (id "workspace", Titel "Workspace", Spalten PANE_COLUMNS. Navigationsplatzierung:die dokumentierte Position eines Bereichs ist ein Dock neben dem Transkript,und Claude Code gibt jedem offenen Bereich einen Tab mit seinem Titel. Suche in den Typen nach einem Feld, das einen Bereich auf der linken Seite platziert. Wenn eines existiert, setze den Navigator auf die linke Seite und die Werkzeuge in das rechte Dock. Wenn keines existiert, ist der Navigator ein weiterer Bereich im Dock. Notiere das Ergebnis in LIMITS.md. Navigatorinhalt, von oben nach unten: 1. Titel CLAUDE CODE und eine Schaltfläche "Neuer Chat". Neuer Chat führt den eingebauten Befehl aus, der eine neue Unterhaltung startet. Finde den Befehlsnamen mit $.command.list. 2. WORKSPACE: eine Schaltfläche für jedes Werkzeug, in dieser Reihenfolge: Dateien, Terminal, Browser, Quellcodeverwaltung, Probleme, Aufgaben ausführen, Gliederung, Zu-erledigen-Kommentare, Zeitleiste, Nutzung, Modell-Router. Ein Druck öffnet dieses Werkzeugfenster und gibt ihm den Fokus. Markiere die Werkzeuge, die offen sind. 3. RECENTS: die neuesten 5 Sitzungen, mit "Mehr anzeigen". Jede Zeile zeigt den Titel, den Projektnamen,und das Alter (8m, 22h, 3d. Der Titel ist die erste Eingabeaufforderung der Sitzung, abgeschnitten, um zu passen. Ein Druck auf eine Zeile zeigt die Eingabeaufforderungen dieser Sitzung unterhalb der Zeile. Markiere die aktuelle Sitzung. 4. PROJECTS: jeder Projektordner mit seiner Sitzungsanzahl. Ein Druck zeigt die Sitzungen dieses Projekts. Sitzungsindex:im prompt.submit-Hook schreibe { id, cwd, repo, titel, prompts[], updatedAt } zu $.store unter dem Schlüssel "session:<id>". Behalte die neuesten 50 Eingabeaufforderungen für jede Sitzung und die neuesten 200 Sitzungen. Lies den Speicher vor jedem Schreiben erneut, weil andere Sitzungen in denselben Speicher schreiben. Lies oder parse nicht Claude Codes eigene Transkriptdateien. Öffne eine letzte Sitzung: überprüfe die Typen auf eine unterstützte Methode zum Wechseln oder Fortsetzen einer Sitzung. Wenn keine existiert, kopiere "claude --resume <id>" mit $.ui.copy und zeige einen Toast, der das sagt. Werkzeuge. Jedes Werkzeug ist ein Bereich mit eigener id, einem kurzen Titel,und einer Aktualisieren-Schaltfläche. Jedes Werkzeug zeigt eine klare Zeile, wenn es keine Daten hat oder wenn sein Programm fehlt. 1. Dateien: ruft https://t.co/crzRXVIH3H mit dem Sitzungsordner auf. Es zeichnet keinen zweiten Baum. 2. Terminal: ein Eingabefeld, das einen Befehl mit $.process.spawn im Sitzungsordner ausführt. Streamme die Ausgabe in den Bereich. Behalte die letzten 500 Zeilen. Zeige den Exit-Code. Behalte eine Geschichte von 50 Befehlen. Eine Stopp-Schaltfläche beendet den Prozess. Dies ist ein Befehlsausführer, kein Terminal-Emulator; sage das im README. 3. Browser: ein Eingabefeld für eine URL. Rufe mit $.http.fetch ab. Zeige den Statuscode, den Seitentitel,und den lesbaren Text als Markdown, abgeschnitten auf das Elementlimit. Zeige Links als Schaltflächen, die den Link laden. Eine Schaltfläche "Im Systembrowser öffnen" verwendet den Öffnen-Befehl des Betriebssystems. Erlaube nur http und https. 4. Quellcodeverwaltung: Zweig, voraus und hinter Zählungen,und die geänderten Dateien mit Status und "+hinzugefügt −entfernt" von git. Ein Druck auf eine Datei ruft https://t.co/crzRXVIH3H mit Registerkarte "diff". Schaltflächen: Stufen, Stufe aufheben, Alle stufen. Ein Commit-Eingabefeld committet die gestuften Dateien nach einer Bestätigung mit $.ui.ask. Schiebe nicht, ziehe nicht, setze zurück oder verwerfe Änderungen. 5. Probleme: führe den Prüfbefehl des Projekts aus und liste jedes Problem als "datei:zeile nachricht" mit einem Schweregrad-Marker. Erkenne den Befehl: tsc --noEmit für tsconfig.json, cargo check für Cargo.toml, go vet für go.mod, ruff check für pyproject.toml, wenn ruff installiert ist. Eine Benutzereinstellung ersetzt den erkannten Befehl. Ein Druck ruft https://t.co/crzRXVIH3H mit der Zeile auf. Führe nur bei Aktualisieren und nachdem ein Zug endet aus, und führe nicht zwei Prüfungen gleichzeitig aus. 6. Aufgaben ausführen: zeige den Sitzungsordner. Finde Aufgaben in package.json-Skripten, Makefile-Zielen, justfile-Rezepten, Cargo.toml (build, test, clippy), pyproject.toml-Skripten,und go.mod (build, test, vet. Wenn keine gefunden wird, zeige: Keine Aufgabe gefunden (package.json, Makefile, justfile, Cargo.toml, pyproject.toml, go.mod. Eine Schaltfläche für jede Aufgabe. Ein Eingabefeld mit dem Platzhalter "Einen Befehl ausführen, dann Eingabe". Streamme die Ausgabe und zeige den Exit-Code und die Zeit. 7. Gliederung:die Symbole der Datei, die im Explorer offen ist, mit Zeilennummern: Funktionen, Klassen, Strukturen, Schnittstellen, Konstanten,und Markdown-Überschriften. Verwende eine kleine Mustertabelle für jede Sprache (ts, js, py, rs, go, md. Rücke verschachtelte Symbole ein. Ein Druck ruft https://t.co/crzRXVIH3H mit der Zeile auf. 8. Zu-erledigen-Kommentare: finde TODO, FIXME, HACK,und NOTE-Kommentare im Projekt. Verwende rg, wenn es installiert ist. Wenn nicht, gehe den Baum mit $.fs.list durch und überspringe .git, node_modules, target,und dist. Gruppiere nach Tag. Zeige "datei:zeile text". Begrenze bei 300 Elementen. Ein Druck ruft https://t.co/crzRXVIH3H mit der Zeile auf. 9. Zeitleiste: eine Zeile für jede Eingabeaufforderung, jeden Werkzeugaufruf,und jedes Zugende in dieser Sitzung, neueste zuerst, mit der Uhrzeit. Für Edit und Write zeige den Pfad und die Zeilenzahlen. Ein Druck auf eine Bearbeitungszeile ruft https://t.co/crzRXVIH3H mit Registerkarte "diff". Behalte 300 Zeilen. 10. Nutzung: lies $.session.usage(). Zeige den Kontextprozentsatz, Token,und Fenster mit einem Balken. Zeige jede Ratenbegrenzung mit Prozent verwendet und Rückstellzeit. Zeige die Kosten, wenn das Feld einen Wert hat. Zeichne die Tokenanzahl jedes Zuges im session.measure-Hook auf und zeichne die letzten 30 Züge als kleines Balkendiagramm. Verwende Raster im Terminal und Text auf anderen Oberflächen (überprüfe e.surface. 11. Modell-Router: zeige das Modell der Hauptsitzung und jeden Unteragentenstart mit seinem Typ, seinem Modell,und seinem Zustand. Drei Modi in einem Auswahlfeld: Aus, Vorschlagen, Automatisch. Aus zeichnet nur auf. Vorschlagen zeigt das Modell, das die Regeln auswählen, und ändert nichts. Automatisch setzt das Modell eines Unteragenten im agent.spawn-Hook von einer Regelttabelle (Unteragententyp oder Aufgabenstichwort → Modell),die der Benutzer im Bereich bearbeitet und die in $.store gespeichert ist. Regeln: ändere nie das Modell der Hauptsitzung, behalte ein Modell, das der Aufrufer nannte,und lasse den Start unverändert weiterlaufen, wenn eine Regel fehlschlägt. Lies die Modellnamen von der Sitzung und den Einstellungen. Schreibe keine Modellnamen in den Code. Der Standardmodus ist Aus. </mod> <mod name="ide-usage"> Eine Statuszeile mit $.ui.status: "ctx 20% · <modell>". Aktualisiere sie im session.measure-Hook. Kein Bereich. </mod> <mod name="ide-statusbar"> Eine Statuszeile mit $.ui.status: "<sprache> · <dateiname>" für die Datei, die im Explorer offen ist, oder die Datei, die Claude zuletzt gelesen oder bearbeitet hat. Leite die Sprache von der Dateierweiterung ab. Zeige "Klartext" für eine unbekannte Erweiterung. Kein Bereich. </mod> <out_of_scope> - Fensterregisterkarten für mehr als eine Sitzung(zum Beispiel ⌘1 und ⌘2). Die Terminalanwendung zeichnet diese. Ein Mod kann nicht. - Ein vollwertiger Texteditor im Bereich. Ein Eingabefeld ist eine Zeile. - Änderungen an der Berechtigungsaufforderung. Ein Mod kann dort nicht zeichnen. Füge keine Funktionen hinzu, die nicht in dieser Eingabeaufforderung sind. Füge keine Konfigurationsoptionen hinzu, die keine Funktion benötigt. </out_of_scope> <safety> Ein Mod läuft mit den Berechtigungen des Benutzers und ist nicht sandboxiert. Schreibe Code, den ein sorgfältiger Prüfer akzeptiert: - Bestätige mit $.ui.ask vor Löschen, Umbenennen,und Committen. - Führe nie einen destruktiven Git-Befehl aus. Genehmige nie einen Werkzeugaufruf für den Benutzer. Sende nie Dateiinhalte oder Eingabeaufforderungen ins Netzwerk. Das Browser-Werkzeug ruft nur die URL ab, die der Benutzer getippt oder gedrückt hat. - Lies keine Umgebungsvariablen oder Einstellungen, die eine Funktion nicht benötigt. "claude plugin validate" listet Umgebungslesevorgänge und Aufrufe auf; halte diese Liste kurz. - Übergib Argumente an $.process als Array. Baue keine Shell-Zeichenfolge aus Dateinamen. Während dieses Builds bearbeite Dateien nur innerhalb dieses Repositorys. Schiebe nicht. Installiere die Plugins nicht in meine Benutzereinstellungen. Frage mich vor jeder Aktion, die schwer rückgängig zu machen ist. </safety> <workflow> Diese Aufgabe ist lang. Dein Kontext wird automatisch komprimiert, also höre nicht früh auf, um Token zu sparen. Behalte den Zustand in Dateien, sodass ein neuer Kontext fortfahren kann: - PROGRESS.md: was getan ist, was als nächstes kommt,und jede Entscheidung mit ihrem Grund. - tests.json: ein Eintrag für jeden Akzeptanztest mit dem Status not_started, failing, oder passing. - LIMITS.md: jede Funktion, die die installierte API nicht kann,und was du stattdessen gebaut hast. - Ein Git-Commit für jede Funktion, die besteht. Am Anfang jedes neuen Kontexts: lies PROGRESS.md, tests.json, LIMITS.md,und das Git-Protokoll. Führe die Testsuite aus, bevor du eine Funktion hinzufügst. Phase 0, finde heraus. Führe /plugin-authoring aus. Führe "claude --version" aus. Lies die Dokumentationsseiten und das "diff"-eingebaute Mod. Dann schreibe PLAN.md: die Ereignisse und Methoden, die jede Funktion verwendet, mit der Zeile aus den Typen, die beweist, dass jede existiert. Liste jede Funktion auf, die ein anderes Design braucht. Zeige mir PLAN.md und fahre fort, außer ich widerspreche. Phase 1, Gerüst. Erstelle das Repository-Layout, die vier Manifeste, hooks.json-Dateien,und leere register.ts-Dateien,die nur ihre Befehle registrieren. Führe "claude plugin validate --strict" auf jedem Plugin aus, bis es besteht. Dann stoppe und gib mir diesen Befehl, um mit Hot-Reload neu zu starten: claude --plugin-dir ./plugins/file-explorer --plugin-dir ./plugins/workspace --plugin-dir ./plugins/ide-usage --plugin-dir ./plugins/ide-statusbar Nachdem ich "weiter" getippt habe, lies die generierten Typen in .claude-plugin/types/und korrigiere PLAN.md. Phase 2, file-explorer. Baue in dieser Reihenfolge: Baummodell und Registerkarte Dateien, Dateisuche, Registerkarte Code mit Suchen, Registerkarte Diff, https://t.co/crzRXVIH3H. Schreibe die Tests für eine Funktion vor ihrem Code. Phase ̈3, workspace. Baue den Navigator und den Sitzungsindex zuerst. Dann baue die Werkzeuge in der aufgeführten Reihenfolge. Beende und teste ein Werkzeug, bevor du das nächste beginnst. Phase ̈4, Statuszeilen. Baue ide-usageund ide-statusbar. Phase ̈5, Veröffentlichung. Schreibe marketplace.json, LICENSE,und README.md. Das README gibt: was jedes Mod tut,die Installationsbefehle (claude plugin marketplace add, claude plugin install <name>@MARKETPLACE),die Claude-Code-Version,die du getestet hast,die Befehle,die Hotkeys,was jedes Mod erreichen kann (aus den "hooks:" und "calls:"-Zeilen von validate),und den Inhalt von LIMITS.md. Führe die vollständige Verifizierung aus. Arbeite direkt. Verwende einen Unteragenten nur für eine Suche über viele Dateien,die deinen Kontext nicht braucht. </workflow> <tests> Tests laufen mit "claude plugin test" und brauchen keine Sitzung und kein Netzwerk. Ein Test feuert Ereignisse ab, drückt Steuerelemente per Schlüssel,und überprüft die Zeichnung oder das Ergebnis. Stubbe $.fs, $.process, $.http,und $.store. Schreibe Tests, die Verhalten überprüfen, zum Beispiel: - Eine Suche nach "auth" in einem Stub-Baum gibt die richtigen Dateien zurück, markiert den übereinstimmenden Text,und stoppt bei 500. - ":42" wählt Zeile 42 aus. "/re(fresh)?/" findet die richtigen Übereinstimmungen. Ein ungültiger regulärer Ausdruck zeigt eine Fehlerzeile und wirft nicht. - Ein Druck auf eine Quellcodeverwaltungszeile ruft https://t.co/crzRXVIH3H mit Registerkarte "diff" auf. - Aufgaben ausführen mit keiner Manifestdatei zeigt die "Keine Aufgabe gefunden"-Zeile. - Ein Git-Programm, das fehlt, gibt eine klare Zeile und keinen Fehler. - Der Sitzungsindex behält 200 Sitzungen und führt mit einem neueren Schreiben von einer anderen Sitzung zusammen. - Modell-Router im Aus-Modus und im Vorschlagen-Modus gibt next(e) unverändert zurück. Schreibe allgemeinen Code, der für jede gültige Eingabe richtig ist. Schreibe keinen Code, der nur einen Test erfüllt. Lösche oder schwäche keinen Test, um ihn bestehen zu lassen. Wenn ein Test falsch ist oder eine Funktion nicht möglich ist, sage es mir. </tests> <done_when> 1. "claude plugin validate --strict" besteht für jedes Plugin. 2. "claude plugin test" besteht für jedes Plugin,und tests.json hat keinen Eintrag, der failing oder not_started ist. 3. "tsc -p" auf jedem Plugin meldet keinen Fehler gegen die generierten Typen. 4. Jeder Befehl antwortet in "claude -p" (zum Beispiel: claude -p "/explorer" --plugin-dir ./plugins/file-explorer)mit keinem Fehler. 5. LIMITS.md listet jeden Unterschied von dieser Eingabeaufforderung. 6. Du gibst mir eine Checkliste der Elemente, die nur eine Person in einer Live-Sitzung überprüfen kann: jeder Bereich öffnet sich,die Hotkeys funktionieren,und das Layout passt bei 110 und bei 144 Spalten. </done_when> <reporting> Nach jeder Phase schreibe einen kurzen Bericht: was du gebaut hast,die genauen Befehle,die du ausgeführt hast,ihre Ergebnisse,und was nicht verifiziert ist. Trenne"die Tests bestehen" von "Ich habe es in einer Sitzung arbeiten sehen". Wenn du etwas nicht ausgeführt hast, sage, dass du es nicht ausgeführt hast. </reporting> [Ende der Eingabeaufforderung]