focused-fix
von alirezarezvanifocused-fix ist ein Claude Skill für gründliche Feature- oder Modulreparaturen. Er eignet sich, wenn ein Bereich durchgängig nicht funktioniert und vor Codeänderungen Scope-Mapping, Dependency-Tracing, Tests, Logs und ein Reparaturplan nötig sind – nicht für schnelle Einzeilen-Bugs.
Dieser Skill erreicht 70/100 Punkte und ist damit ein akzeptabler, aber eingeschränkter Kandidat für die Aufnahme ins Verzeichnis. Nutzer können erkennen, wann er für systematische Feature- oder Modulreparaturen sinnvoll ist. Sie sollten jedoch eher einen eigenständigen Markdown-Workflow erwarten als einen paketierten Skill mit Begleitdateien, Beispielen oder Installationshinweisen.
- Starke Auslösbarkeit: Frontmatter und der Abschnitt „When to Use“ nennen ausdrücklich Prompts wie „make X work“, „fix the Y feature“ und „focus on [area]“.
- Klare Abgrenzung des Einsatzbereichs: Der Skill unterscheidet Feature- bzw. Modulreparaturen von schnellen Einzelbug-Fixes und betont das Nachverfolgen von Abhängigkeiten, Logs und Tests.
- Umfangreiche SKILL.md-Inhalte mit mehreren Überschriften und Einschränkungen deuten auf mehr operative Anleitung hin als ein minimaler Prompt.
- Es gibt keine Begleitdateien, README, Installationsbefehl, Skripte, Referenzen oder Ressourcen. Die Nutzung stützt sich daher vollständig auf die einzelne SKILL.md.
- Der Skill verweist auf einen alternativen „systematic-debugging“-Workflow und enthält Platzhaltermarkierungen; die vorliegenden Informationen zeigen jedoch keine Begleitmaterialien oder konkreten Beispiele.
Überblick über den focused-fix Skill
Wofür focused-fix gedacht ist
focused-fix ist ein Engineering-Skill für systematische Feature-Reparaturen. Setze ihn ein, wenn ein ganzes Feature, Modul, eine Route, ein Workflow oder eine Integration defekt ist und der Agent zuerst die komplette fachliche und technische Grenze nachvollziehen soll, bevor Code geändert wird. Der Skill ist für Debugging-Aufgaben gedacht, bei denen „fix the login flow“ oder „make billing exports work“ zu breit für einen einzelnen Bug-Prompt ist, aber trotzdem einen klar fokussierten Reparaturplan braucht.
Für wen und welche Situationen focused-fix am besten passt
Der focused-fix Skill ist besonders nützlich für Entwicklerinnen und Entwickler, Tech Leads und AI Coding Agents, die in einer bestehenden Codebasis arbeiten. Er passt zu Aufgaben wie der End-to-End-Reparatur eines fehlerhaften Features, dem Wiederherstellen eines Moduls nach Refactorings, dem Prüfen aller Abhängigkeiten eines Workflows oder dem Produktionsreifmachen eines nur teilweise implementierten Bereichs. Weniger geeignet ist er für Greenfield-Feature-Design, schnelle Syntaxfehler oder isolierte Ein-Zeilen-Defekte.
Was den Workflow anders macht
Der zentrale Unterschied ist die Disziplin „erst Scope, dann Fixes“. Statt vom Symptom direkt zum Patch zu springen, bringt focused-fix den Agent dazu, die Feature-Grenze zu erfassen, abhängige Dateien zu prüfen, Tests und Logs zu verstehen und das Feature anschließend als zusammenhängendes System zu reparieren. Das ist wichtig, wenn der sichtbare Fehler nur ein Symptom für eine tiefere Unstimmigkeit zwischen UI, API, State, Datenbank, Konfiguration und Tests ist.
Hinweise vor der Installation
Installiere focused-fix, wenn du ein langsameres, dafür vollständigeres Reparaturverhalten möchtest. Installiere ihn nicht in der Erwartung, einen leichtgewichtigen Debugging-Shortcut zu bekommen. Der Upstream-Skill ist in SKILL.md konzentriert und scheint keine Helper-Skripte, Reference Packs oder zusätzlichen Rule Files mitzuliefern. Sein Wert liegt daher vor allem in der Qualität des Protokolls, nicht in begleitendem Tooling.
So verwendest du den focused-fix Skill
focused-fix installieren und Repository prüfen
Installiere den Skill in einem kompatiblen Claude Skills Setup mit:
npx skills add alirezarezvani/claude-skills --skill focused-fix
Lies nach der Installation zuerst die Quelle unter engineering/skills/focused-fix/SKILL.md. Die Repository-Vorschau zeigt, dass dieser Skill weitgehend in sich geschlossen ist; es gibt also keine wichtigen Support-Ordner, die du vor der Nutzung prüfen musst. Falls dein Skill Runner Metadaten installierter Skills anzeigt, vergewissere dich, dass die Beschreibung weiterhin Feature-/Modul-Reparatur erwähnt und nicht schnelles Debugging einzelner Bugs.
Welche Inputs der Skill braucht
Ein schwacher Prompt wäre: „Fix checkout.“ Ein nützlicher focused-fix Prompt benennt die Feature-Grenze, das erwartete Verhalten, den beobachteten Fehler, relevante Commands sowie bereits bekannte Dateien oder Logs.
Beispiel:
Use focused-fix for Debugging the checkout flow. Expected: guest users can add an item, enter shipping, pay with Stripe test card, and see an order confirmation. Actual: payment succeeds in Stripe but no order appears in the app. Start with
apps/web/src/checkout,apps/api/src/orders,packages/payments, and the failing testcheckout.e2e.ts. Do not patch until you have mapped the full flow and identified every dependent file.
Damit bekommt der Skill genug Kontext, um keine zufälligen Änderungen vorzunehmen, bleibt aber trotzdem auf einen klaren Reparaturbereich begrenzt.
Empfohlener focused-fix Workflow
Nutze focused-fix, wenn die Aufgabe eine gründliche Analyse verdient:
- Benenne das Feature oder Modul, das repariert werden soll.
- Definiere „funktioniert“ anhand beobachtbarer Kriterien: Tests bestehen, der User Path läuft durch, die API liefert die erwarteten Daten, Logs zeigen einen bekannten Fehler nicht mehr.
- Bitte den Agent, vor dem Editieren die Feature-Grenze zu kartieren.
- Gib Test-Commands, Reproduktionsschritte, aktuelle Refactorings und bekannte riskante Dateien an.
- Verlange vor Codeänderungen einen kurzen Reparaturplan.
- Bitte nach den Änderungen um Validierungsnachweise: ausgeführte Tests, geprüfte Logs, manuell verifizierter Pfad oder eine Liste verbleibender Lücken.
Dieser Workflow entspricht der Absicht des Skills: erst die Untersuchung abschließen, dann den Fix umsetzen.
Prompt-Muster für bessere Ergebnisse
Nutze dieses Muster, wenn du den focused-fix Skill aufrufst:
Use focused-fix on [feature/module].
Goal: [what must work end-to-end].
Current failure: [symptoms, errors, logs, failing tests].
Scope hints: [directories, services, routes, configs, data models].
Constraints: [do not change public API, preserve backward compatibility, avoid migrations, etc.].
Validation: [commands or manual checks that prove the feature works].
Before editing: map the boundary and explain likely dependency points.
Die Zeilen zu Constraints und Validation sind besonders wichtig. Sie verhindern, dass der Agent das Symptom „fixt“, indem er Verhalten ändert, das du eigentlich beibehalten musst.
focused-fix Skill FAQ
Ist focused-fix nur für Debugging?
Er ist vor allem ein focused-fix Skill für Debugging und Reparatur, zielt aber auf mehr als einen einzelnen Stack Trace. Nutze ihn für einen defekten Feature-Bereich, bei dem Abhängigkeiten nachvollzogen werden müssen. Wenn du die exakt fehlschlagende Zeile bereits kennst und die Änderung offensichtlich ist, ist ein normaler Coding-Prompt oder ein kleinerer systematischer Debugging-Skill möglicherweise schneller.
Worin unterscheidet sich focused-fix von einem normalen Prompt?
Ein normaler Prompt optimiert oft auf einen schnellen Patch. Der focused-fix Skill lenkt den Agent stärker auf die Reihenfolge der Untersuchung: Scope definieren, verwandte Dateien prüfen, Abhängigkeiten verstehen, dann reparieren. Das verringert die Wahrscheinlichkeit von Teilreparaturen, bei denen der unmittelbare Test zwar besteht, aber ein anderer Teil des Features weiterhin defekt bleibt.
Ist focused-fix anfängerfreundlich?
Ja, sofern du das defekte Feature beschreiben und Validierungs-Commands ausführen kannst. Einsteiger profitieren oft von der strukturierten Vorgehensweise, weil der Agent die Feature-Grenze erklären soll, bevor Code geändert wird. Trotzdem musst du Änderungen sorgfältig prüfen, besonders in Bereichen wie Authentifizierung, Payments, Datenmigration, Berechtigungen oder Produktionskonfiguration.
Wann sollte ich focused-fix nicht verwenden?
Vermeide focused-fix bei sehr kleinen Defekten, Formatierungsfixes, Dependency-Upgrades, umfassenden Architektur-Redesigns oder vagen Bitten wie „improve the app“. Der Skill funktioniert auch schlecht, wenn du keinen reproduzierbaren Fehler, kein erwartetes Verhalten oder nicht genug Repository-Kontext liefern kannst. Am stärksten ist er, wenn das Problem klar eingegrenzt, aber intern vernetzt ist.
So verbesserst du den focused-fix Skill
focused-fix Inputs vor dem ersten Lauf verbessern
Der beste Weg, focused-fix Ergebnisse zu verbessern, sind präzisere Grenzen. Nenne, sofern relevant, Schritte der User Journey, API-Endpunkte, Background Jobs, Datenbanktabellen, Feature Flags, Environment Variables und Testnamen. Wenn du weißt, dass ein aktueller Merge oder ein Refactoring den Fehler wahrscheinlich ausgelöst hat, sag es dazu. So kann der Agent den richtigen Abhängigkeitsgraphen prüfen, statt das gesamte Repository zu durchsuchen.
Typische Fehlermuster erkennen
Häufige Fehlermuster sind Scope Creep, zu frühe Edits, Überanpassung an einen einzelnen fehlschlagenden Test und das Ignorieren versteckter Abhängigkeiten wie Konfiguration, Seed Data, Berechtigungen, Queues oder Type-Mismatches zwischen Client und Server. Wenn der Agent mit dem Patchen beginnt, bevor das Feature kartiert ist, unterbrich ihn und stelle klar: „Complete the scope map first; no fixes until the full path is understood.“
Nach der ersten Reparatur iterieren
Höre nach der ersten Ausgabe nicht bei „tests pass“ auf. Bitte um eine knappe Zusammenfassung der Änderungen, berührte Dateien, durchgeführte Validierung und verbleibende Risiken. Führe anschließend eigene Checks aus und gib jeden neuen Fehler exakt so zurück, wie du ihn beobachtet hast. focused-fix funktioniert am besten als Schleife: Scope erfassen, reparieren, validieren, Scope nachschärfen und nur dann erneut reparieren, wenn die Evidenz weiterhin einen Fehler zeigt.
Projektspezifische Hinweise ergänzen
Für wiederholte Nutzung solltest du focused-fix mit lokalen Repository-Anweisungen kombinieren. Ergänze Hinweise wie bevorzugte Test-Commands, Code-Ownership-Grenzen, Logging-Konventionen, verbotene Shortcuts und releasekritische Bereiche. Zum Beispiel: „Do not bypass permission checks to make the admin panel pass,“ oder „Use existing service methods rather than direct database writes.“ So wird aus dem allgemeinen focused-fix Leitfaden ein sichererer Reparaturworkflow für deine Codebasis.