Wähle das günstigste Modell, das die Aufgabe erfüllt, und halte den Tokenverbrauch niedrig. Verwende dies zu Beginn jeder Aufgabe, vor der Planung, der Delegierung an einen Unteragenten oder dem Lesen vieler Dateien.
Was ist stremio-ai-translator?
Diese Skill-Optimierung für Claude Code, Cursor und Codex priorisiert kosteneffiziente Modellauswahl und Token-Einsparungen ohne Qualitätsverlust. Sie definiert Richtlinien, welches Modell (Sonnet, Opus, Haiku) für welche Art von Arbeit verwendet werden soll, basierend auf Aufgabenkomplexität und wiederholten Fehlversuchen. Zudem enthält sie Strategien wie das sequenzielle Lesen von Dateien (z. B. PLAN.md), das Vermeiden von unnötigen erneuten Lesevorgängen und das Kürzen von Befehlsausgaben, um den Tokenverbrauch zu minimieren. Die Anleitung betont außerdem die Delegation von Such- und Log-Aufgaben an Unteragenten, die Beschränkung auf eine Aufgabe pro Sitzung und die abschließende Ausführung von Prüfungen, um Genauigkeit zu gewährleisten.
Sonnet (Standard, ~90 % der Arbeit): Bearbeitungen, Fehlerbehebungen, Tests, Refactorings von bekanntem Code, Git, Dokumentation, README/TROUBLESHOOTING-Updates, Ausführen von npm run check.
Opus (nur wenn es sich lohnt): Eine neue Funktion, die mehrere Module umfasst, Architektur- oder Datenflussänderungen, ein Fehler, dessen Ursache nach einem Sonnet-Versuch unbekannt ist, Sicherheitsüberprüfung, große Migrationen. Verwende es, um einen kurzen schriftlichen Plan (max. ~30 Zeilen) zu erstellen und führe den Plan dann mit Sonnet aus.
Haiku: Reine Nachschlagen, Grep-and-Report, Zusammenfassen von Logs, Auflisten von Dateien. Delegiere mit einem Unteragenten und model: haiku.
Steige nicht für Stil, Benennung oder Änderungen an einer einzelnen Datei auf Opus um. Wenn ein Sonnet-Versuch zweimal fehlschlägt, steigere einmal herauf und kehre dann zu Sonnet zurück.
Token sparen ohne Qualitätsverlust
Lies zuerst PLAN.md. Lies dann nur die Dateien, die die Aufgabe berührt. Verwende Grep/Glob, bevor du Dateien öffnest; lies Zeilenbereiche, nicht ganze Dateien.
Lies niemals node_modules, dist-electron, release, logs, data, package-lock.json oder .env.
Führe npm run check einmal am Ende aus, nicht nach jeder Bearbeitung. Führe während der Iteration eine einzelne Testdatei aus (npx vitest run tests/<file>).
Leite lange Befehlsausgaben durch Select-Object -First 40 / -Last 40; gib nicht vollständige Logs aus.
Lies eine gerade bearbeitete Datei nicht erneut. Stelle keine bereits im Gespräch etablierten Fakten erneut dar.
Halte Antworten kurz: was geändert wurde, was überprüft wurde, was der Benutzer als Nächstes tun muss.
Lagere breite Such- oder Log-Lesevorgänge an einen Unteragenten aus, sodass nur dessen Schlussfolgerung in den Hauptkontext gelangt.
Eine Aufgabe pro Sitzung. Beginne eine neue Sitzung, wenn sich das Thema ändert, anstatt einen langen Verlauf mitzunehmen.
Überspringe niemals die Prüfung, die Tests oder das Lesen von Dateien, die die Korrektheit beeinflussen, um Token zu sparen.
Individual skills in this repo
This repo contains 1 individual skill — each has its own dedicated page.