Claude-Code-Kompetenzstack eines Senior Engineers

Als ich zum ersten Mal sah, wie ein Claude-Code-Agent ein Jira-Ticket aufnahm, den Bug im echten Browser reproduzierte, ihn diagnostizierte, einen fehlschlagenden Test schrieb, den Fix implementierte, auf den Main-Branch pushte und QA benachrichtigte – und das alles, ohne dass ich zwischen den Schritten die Tastatur berührte – überkam mich dieses diffuse Gefühl, das jeden arbeitenden Engineer irgendwann ereilt. Nicht „das wird mich ersetzen“. Eher: „Ich habe das seit drei Jahren irgendwie falsch gemacht.“

Der Engineer, dem ich zusah, war kein AI-YouTuber. Er war ein ehemaliger Senior bei Amazon und Microsoft, heute bringt er ein Produkt namens BookZ.AI heraus, und er hatte den vielleicht diszipliniertesten Claude-Code-Skillstack aufgebaut, den ich 2026 gesehen habe. Acht Skills. Jeder beseitigt ganz spezifisch eine Failure-Mode im „rohen Claude-Code“-Erlebnis. Zusammen gestapelt leisten sie etwas, das in den offiziellen Dokumentationen kaum zur Sprache kommt: Sie verwandeln Claude Code von einer cleveren Autovervollständigung in etwas, das eher einem Junior- bis Midlevel-Engineering-Team entspricht, das zufällig auch um 3 Uhr morgens arbeitet.

Ich habe das Stack am Wochenende auseinandergenommen, die Teile installiert und sie an einer kleinen SaaS getestet, die ich gerade baue. Einiges hielt, was es versprach. Anderes ist überbewertet. Die Fixed-Ticket-Skill hat mich wirklich überrascht. Der Marketing-Stack – eigentlich der Part, von dem ich annahm, dass er reines Füllmaterial ist – entpuppte sich als das am meisten unterschätzte Element des gesamten Setups.

Hier die vollständige Aufschlüsselung: Was jeder Skill genau macht, wann ich ihn einsetzen würde, wie sie zusammenspielen – und an welchen Stellen das rohen Claude-Code-Erlebnis ohne sie auseinanderfällt.

Warum „Raw“ Claude Code letztlich scheitert

Claude Code ist für sich genommen leistungsfähig. Man zeigt ihm ein Repository, beschreibt das gewünschte Ziel, und es schreibt den Code. Für ein Wochenendprojekt funktioniert das hervorragend. Es beginnt jedoch an dem Punkt zu bröckeln, an dem dein Codebase einen zweiten Mitwirkenden bekommt, in Produktion geht und erste Nutzer anfangen, Bugs zu melden.

Die drei typischen Fehlerquellen, auf die ich immer wieder stoße:

1. Es überspringt Schritte. Raw Claude Code schreibt bereitwillig das Feature und die Tests — allerdings nur, wenn man ausdrücklich darauf besteht, die Reihenfolge einhält und den ersten Entwurf ablehnt. Überlässt man ihm die Kontrolle, gleitet es in den „Vibe-Coding“-Modus ab: Das Feature wird shipped, die Tests kommen später, das Refactoring noch später — und oft bleibt alles offen.
2. Es verliert den Kontext zwischen Sessions. Jede neue Session beginnt ohne Vorwissen. Projektkonventionen, Design-Sprache, Bug-Historie — Claude Code muss alles wieder aus der CLAUDE.md und per Copy-Paste neu entdecken.
3. Es schließt keine Schleifen. Es schreibt Code — aber läuft dieser tatsächlich? Lässt sich der Bug nach wie vor reproduzieren? Hat der Deploy funktioniert? Irgendwer — meist ich — muss das überprüfen, und genau in dieser Verifizierungsphase scheitern die meisten „AI shippt Code“-Demos leise.

Die Skills, die ich im Folgenden beschreibe, sind keine universellen Produktivitäts-Hacks. Jeder einzelne schließt gezielt eine bestimmte Schleife. Gemeinsam sorgen sie dafür, dass Claude Code weniger wie ein Praktikant mit Koffeinproblem agiert und mehr wie ein Team, das Aufgaben wirklich zu Ende bringt.

Falls du das mentale Modell hinter Skills in 2026 noch nicht verinnerlicht hast: Mein Agent Skills Guide für Claude Code erklärt die grundlegenden Mechanismen — dieser Beitrag setzt das Verständnis bereits voraus und zeigt, wie ein Produktions-Stack in der Praxis aussieht.

Skill 1: Superkräfte — Die Disziplin-Schicht

Die grundlegende Fähigkeit. Die eine, ohne die die anderen sieben nur angenehmere Wege wären, Chaos zu produzieren.

Superkräfte ist ein Open-Source-Plugin für Claude Code, entwickelt von obra (Jesse Vincent), das innerhalb von drei Monaten nach dem Launch im Januar 2026 unglaubliche 99.000+ GitHub-Stars erreichte — was absurd ist für ein Plugin und zeigt, wie enorm die Nachfrage nach genau dieser Lösung ist. Kurz darauf wurde es offiziell in den Anthropic-Plugin-Marktplatz aufgenommen.

Worum es geht, in einem Satz: Es zwingt Claude Code dazu, einem echten Senior-Engineering-Workflow zu folgen, statt nur dem, was sich am schnellsten anfühlt.

Der von Superkräfte erzwungene Workflow:

1. Brainstorming — eine vage Anfrage in eine Entscheidungs-Spezifikation übersetzen
2. Spezifikation — festhalten, was tatsächlich gebaut wird und was explizit nicht
3. Planen — Zerlegung in Aufgaben von 2–5 Minuten mit exakten Dateipfaden
4. TDD — Red-Green-Refactor; Tests müssen vor der Implementierung fehlschlagen
5. Subagenten-Entwicklung — jede Aufgabe läuft in einem frischen Subagenten, um Kontextverlust bei mehrstündigen Sessions zu verhindern
6. Review — automatisierter Code-Review, bevor irgendetwas als erledigt gilt
7. Abschließen — PR-Erstellung, Branch-Cleanup, Worktree-Management

Der nicht verhandelbare Teil ist der TDD-Zyklus. Superkräfte sagt nicht „Du kannst TDD machen.“ Es sagt: „Du wirst TDD machen.“ Und das durch die Architektur der Skill, nicht durch nett formulierte Anweisungen. Tests werden zuerst geschrieben. Sie müssen fehlschlagen. Erst dann wird die Implementierung geschrieben. Wenn der Test in der Red-Phase nicht tatsächlich fehlschlägt, markiert die Skill das als false green und blockiert den Fortschritt.

Allein diese eine Regel hat etwa 60 % der „Claude hat Code geschrieben, der kompiliert, aber nicht das macht, was ich wollte“-Probleme gelöst. Denn wenn der Test gegen das tatsächliche gewünschte Verhalten geschrieben wurde und fehlschlug, bevor der Code entstand, macht der Code entweder den Test grün oder eben nicht. Es gibt kein Zwischending, in dem Claude eine Funktion halluziniert, die irgendwas Ähnliches zurückgibt.

Wann ich dazu greife: buchstäblich in jeder Session, in der Produktionscode betroffen ist. Das einzige Szenario, in dem ich es nicht nutze, sind Wegwerf-Skripte und explorative Notebooks, bei denen der Overhead größer ist als sein Nutzen.

Wenn du genau eine einzige Skill aus diesem Stack installierst, dann diese. Alles andere in diesem Beitrag baut darauf auf, dass Superkräfte bereits verlässlich dafür sorgt, dass die Entwicklungsschleife ehrlich bleibt. Ich habe eine ausführlichere Rezension zum Superkräfte-Plugin geschrieben, falls du tiefer in die TDD-Erzwingung eintauchen willst.

Fähigkeit 2: Skill Creator — Die Meta-Ebene

Hier kommt der Teil, der mich peinlich lange verwirrt hat: Skill Creator ist eine Fähigkeit, die andere Fähigkeiten erstellt. Im Grunde genommen ist es die Fabrik für die Entwicklung von Skills.

Anthropic hat ihn entwickelt. Er wird mit vier Betriebsmodi ausgeliefert: Create, Eval, Improve und Benchmark. Gemeinsam decken sie den gesamten Lebenszyklus einer Fähigkeit ab — von „Ich habe eine Idee“ bis hin zu „Ich habe diese Fähigkeit unter realer Belastung gemessen und weiß, ob sie tatsächlich hilft.“

Warum ist das wichtig? Weil die wahre Stärke des Skill-Ökosystems nicht darin liegt, die Skills anderer zu installieren. Sie liegt darin, eigene Skills zu komponieren. Der Senior Engineer bei BookZ.AI hat Superpowers nicht als endgültige Lösung angesehen. Er hat Superpowers genommen, Teile von GSD (Get Stuff Done), Teile von GStack, und eine eigene einheitliche Fähigkeit gebaut, die exakt seinen Workflow abbildet: seine bevorzugten Phasen, seine bevorzugten Test-Frameworks, seinen bevorzugten Review-Rhythmus.

Dieser „Compose-your-own“-Ansatz ist entscheidend, weil Fähigkeiten stets auf bestimmte Phasen zugeschnitten sind. Man kann zum Beispiel ein anderes Brainstorming-Modul einsetzen, ohne die TDD-Phase zu verlieren. Oder eine eigene Review-Phase hinzufügen, die die Lint-Regeln des Teams anwendet. Der Eval-Modus des Skill Creators ermöglicht es, jede Version an einem Benchmark zu messen – „produziert diese aktualisierte Fähigkeit in meinem echten Code-Repository tatsächlich besseren Code, oder einfach nur mehr Code?“

Was die meisten Tutorials übersehen, ist, wie wichtig der Eval-Loop ist. Eine Fähigkeit zu schreiben, ist leicht. Eine Fähigkeit zu bauen, die nachweislich deine Arbeitsergebnisse verbessert, trennt die Spielerei von dem Skill, den du dauerhaft einsetzt.

Wann ich ihn nutze: Immer dann, wenn ich merke, dass ich dieselbe 5+ Sätze lange Eingabeaufforderung in mehreren Sessions wiederhole. Diese Wiederholung ist das Signal — ein neuer Skill wartet darauf, geboren zu werden.

Skill 3: UI/UX ProMax — Das Design-System auf Abruf

Das war die Fähigkeit, bei der ich am skeptischsten war. „UI/UX Skill“ heißt normalerweise „generisches Tailwind-Dashboard“. ProMax ist das Gegenteil davon.

Laut offizieller Skill-Dokumentation enthält die zugrundeliegende Datenbank über 50 visuelle Stile, 161 Farbpaletten, 57 Schriftkombinationen, 161 Produkttypen, 99 UX-Guidelines und 25 Diagrammtypen, abgedeckt für 10 Ziel-Stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui, Plain HTML/CSS). Das Skill wird automatisch ausgelöst, wenn eine Aufgabe UI-Struktur, Komponenten-Refaktorierung, Farbsystemauswahl oder Typografie betrifft — es muss nicht explizit aufgerufen werden.

Das, was mich überzeugt hat: branchenspezifische Defaults. Wenn du „Fintech Dashboard“ sagst, sind die Stil-, Farb- und Typografieentscheidungen des Skills bereits so eingeschränkt, wie es echte Fintech Dashboards erfordern — hochverdichtete Tabellen, dezente Farbpaletten, die auch in lichtgedämmten Trading-Räumen funktionieren, Monospace-Typografie in numerischen Kontexten. Sagst du „Calm Productivity App“, verschieben sich die Defaults hin zu höherem Kontrast, großzügigen Abständen und Schriften, die das Auge auch bei langen Sessions nicht ermüden.

ProMax arbeitet nach Googles „Stitch“-Pattern: Du gibst dem Skill eine design.md-Datei, die das gewünschte Nutzungserlebnis beschreibt, und erhältst ein vollständiges Design-System zurück: Patterns, Farb-Tokens, Schriftkombinationen, Accessibility-Audit (standardmäßig mindestens WCAG AA), SEO-Metastruktur und Performance-Budgets. Im Awesome Design MD-Repository auf GitHub gibt es vorgefertigte design.md-Beispiele für gängige Produkttypen — du startest also nicht auf einer leeren Seite.

Im Constraint-Modus wird es wirklich praktisch. Du sagst ProMax: „Behalte die bestehende Farbpalette und das Layout-Grid, aber gestalte alles innerhalb dieser Grenzen neu.“ Und das wird tatsächlich eingehalten — nicht im Sinne von „schlägt Änderungen vor und hofft, du merkst's nicht“, sondern als harte Rahmenbedingungen, die niemals verletzt werden. Ich habe das an einer bestehenden Landingpage getestet, bei der ich das Farbsystem liebte, aber den Hero-Abschnitt hasste. ProMax hat fünf Hero-Varianten geliefert, die alle exakt die bestehenden Tokens genutzt haben. Genau an diesem Punkt scheitern andere Design-Tools bei mir meistens.

Wann ich darauf zurückgreife: Neue UI-Arbeit, ein Landingpage-Redesign oder jedes Mal, wenn ich eine Designentscheidung treffe, die sich über das ganze Produkt auswirkt. Bei chirurgischen Feinschliffen an einem etablierten Design-System lasse ich es aus — da wären die Meinungen des Skills störend und das Aufrufen würde nur zusätzliche Unruhe bringen.

Falls du jetzt denkst: „Ich habe doch Figma“, — kein Problem. Der Mehrwert liegt nicht darin, Figma zu ersetzen. Das Entscheidende ist: Mit Claude Code können designbewusste Entscheidungen im Code getroffen werden, statt dass du gefragt wirst, welche Farbe ein Button haben soll. In meinem Claude Code AI Design System Workflow-Post beschreibe ich, wie ich ProMax in die restliche Pipeline einbinde.

Skill 4: Playwright — Der Test-Loop-Schließer

Hier hört „AI Engineer“ als Marketingslogan auf — und wird Realität.

Claude Code mit der Playwright-Integration kann tatsächlich einen Browser öffnen, zu deiner App navigieren, Buttons klicken, Formulare ausfüllen, Screenshots machen, das DOM auslesen und prüfen, ob das, was gerade gebaut wurde, wirklich funktioniert. Es existieren zwei Varianten: der Microsoft Playwright MCP Server (Installation mit claude mcp add playwright npx @playwright/mcp@latest) und Community-Skills auf CLI-Basis wie lackeyjb/playwright-skill.

Die Entscheidung zwischen CLI und MCP hat mehr Bedeutung, als viele denken. MCP hält den Browserzustand persistent — ideal für exploratives Testen, sich selbst heilende Tests und lange autonome Loops. CLI-basierte Skills sind hingegen sparsamer im Tokenverbrauch — sie starten Playwright pro Aufgabe und behalten keinen Kontext zwischen den Durchläufen. Für den Loop „Feature implementieren → im realen Browser verifizieren → iterieren“, den die meisten Entwickler tatsächlich fahren, ist CLI in der Regel die bessere Wahl. Für agentengesteuerte QA-Sessions, bei denen viele Seitenzustände miteinander in Beziehung gesetzt werden müssen, hat MCP die Nase vorn.

Das Beispiel im Video des BookZ.AI-Engineers machte das greifbar. Er richtete Claude Code auf eine Replit-App, die ihm nicht gehörte — rohe URL, kein Zugriff auf den Quellcode — und sagte „find bugs.“ Die Skill führte, laut Aussagen des Entwicklers, 16 Testphasen durch. Sie machte 81 Screenshots in diesen Phasen. Sie erzeugte einen QA-Report mit konkreten, reproduzierbaren Fehlern: kaputte Formularvalidierung an einem bestimmten Feld, ein Modal, das den Fokus falsch einsperrte, ein Button, dessen Klickbereich 4 px kleiner war als die sichtbaren Umrisse. (Sämtliche Zahlen stammen aus dem Walkthrough — ich selbst habe mit meiner eigenen App kleinere Tests durchgeführt und die Skill hat drei echte Fehler gefunden, die ich übersehen hatte, aber ich kann hier keine BookZ-Skala vorweisen.)

Danach übernahmen Superpowers und Fixed Ticket: Sub-Agents planten die Korrekturen, schrieben fehlgeschlagene Tests, die jeden Fehler reproduzierten, implementierten die Fixes, prüften, committen und deployten.

Das ist der vollständige Loop. Eine einzige Anweisung — „finde Bugs und behebe sie“ — und die Skills arbeiten Hand in Hand über Rollen hinweg, für die ich normalerweise drei Leute bräuchte.

Wann ich darauf setze: Immer, wenn ein Feature eine UI besitzt. Inzwischen habe ich es auch in die CI eingebunden — ein von Playwright getriebener Smoke-Test ist jetzt mein Deploy-Gate für alles, was das User-Interface berührt.

Skill 5: Telegram — Fernsteuerung

Die Fähigkeit, von der ich sicher war, dass ich sie nie brauchen würde. Drei Wochen später nutze ich sie täglich.

Das Setup ist unkompliziert — starte Claude Code mit claude --channels plugin:telegram@claude-plugins-official, schicke dem Bot eine DM, er antwortet mit einem 6-stelligen Pairing-Code, diesen Code einfügen, fertig. Ab dann wird jede Nachricht, die du vom Handy an den Bot sendest, an deine lokale Claude-Code-Session weitergeleitet, dort gegen deine echten Dateien verarbeitet und die Antwort kommt wieder direkt auf Telegram. Die Arbeit läuft auf deinem Rechner. Die Steuerung trägst du in der Hosentasche.

Drei reale Anwendungsfälle haben das gerechtfertigt:

1. Lange Jobs von unterwegs starten. „Starte die gesamte Test-Suite und sag Bescheid, wenn etwas kaputtgeht“ – geschickt aus dem Café. Zwanzig Minuten später bekomme ich eine Benachrichtigung mit der Zusammenfassung.
2. Session-Reset und Kontextwechsel. Du kannst die Claude-Code-Session per Telegram zurücksetzen oder das aktive Projektkontext wechseln. Praktisch, wenn mir beim Abendessen auffällt, dass ich Claude im falschen Repository gestartet habe.
3. Kognitive Entlastung. Ich habe eine Idee. Anstatt sie in irgendeine Notiz-App zu schreiben und zu vergessen, schicke ich sie an den Bot. Claude loggt sie im Obsidian-Vault des Projekts (siehe nächste Skill), getaggt und verlinkt, und am nächsten Tag ist sie griffbereit.

Das Sicherheitsmodell ist hier relevant. Nur gepaarte Telegram-Nutzer können Nachrichten senden. Man muss --channels beim Start explizit angeben – es gibt keinen passiven „always listening“-Modus, der wäre fatal. Unautorisierte Nachrichten werden kommentarlos verworfen.

Wann ich es nutze: Jedes Mal, wenn ich das Haus verlasse, während ein lang laufender Job läuft. Und zunehmend, je mehr sich das Entlastungs-Muster etabliert, immer dann, wenn eine Idee auftaucht, die ich nicht verlieren will.

Skill 6: Obsidian — Leichtgewichtiges RAG ohne das RAG

Das ist die Fähigkeit, die meine Sicht auf Projektgedächtnis grundlegend verändert hat.

Die Obsidian-Skill stammt von kepano — dem CEO von Obsidian. Du legst sie in einen Ordner innerhalb deines Vaults ab und Claude Code erhält die Fähigkeit, Markdown-Notizen im gesamten Wissensspeicher zu lesen, zu schreiben, zu taggen und mit Links zu versehen. Keine Vektordatenbank. Keine Embeddings-Pipeline. Keine Chunk-and-Retrieve-Infrastruktur. Einfach nur .md-Dateien mit Wikilinks.

Der Design-Insight ist derselbe, den Andrej Karpathy immer wieder öffentlich macht: Traditionelle RAG-Pipelines sind für das persönliche Wissensmanagement überdimensioniert. Das Problem, das RAG löst — „Finde die drei Absätze in 10.000 Dokumenten, die zu dieser Anfrage am relevantesten sind“ — ist nicht das Problem, das die meisten Entwickler wirklich haben. Die meisten Entwickler haben 200 Meeting-Notizen, 40 Projekt-Briefings und 15 Architektur-Entscheidungsprotokolle und wollen diese miteinander verknüpfen und einen Agenten das Graph-Navigieren lassen.

Die Obsidian-Skill verwandelt Claude Code in einen Agenten, der genau diese Navigation beherrscht. Du fragst: „Was haben wir beim Auth-Refactor entschieden?“ Der Agent durchstreift deinen Vault — liest das ADR, folgt dem Wikilink zur Meeting-Notiz, folgt dem Wikilink zum Ticket, folgt dem Wikilink zum Commit — und liefert eine Zusammenfassung, die die konkreten Notizen zitiert. Lernt er etwas Neues, schreibt er eine neue Notiz und verlinkt sie zurück in den Graphen. Der Graph wächst mit deinem Projekt.

Der Kostenunterschied ist der unspektakuläre, aber entscheidende Punkt. Eine richtige Embeddings-Pipeline in einer mittelgroßen Wissensdatenbank verursacht laufende Compute-Kosten. Ein Markdown-Vault kostet $0 an Compute und ist mit git versionierbar. Karpathys veröffentlichter Vergleich schätzte den Retrieval-Aufwand bei gleicher Qualität auf etwa 95 % günstiger als mit einer herkömmlichen RAG-Architektur ein. Für Solo-Founder oder kleine Teams ist das kein Rundungsfehler — es ist der Unterschied zwischen „Ich habe einen Wissensspeicher“ und „Ich habe keinen“.

Ich nutze das seit etwa sechs Wochen in meinen eigenen Projekten. Es hat Notion für mich abgelöst. Mein Karpathy-style Obsidian RAG Writeup geht tiefer auf die technischen Details ein, wenn du Schritt-für-Schritt-Anleitungen suchst.

Wann ich danach greife: Immer aktiv. Es ist keine "danach greifen"-Fähigkeit — es ist eine ambient verfügbare Infrastruktur. Jedes Projekt, das ich jetzt anpacke, hat ein /vault-Verzeichnis und die Skill ist standardmäßig aktiviert.

Skill 7: Das Marketing Skill Pack — 43 Skills, Die Ich Fast Übersprungen Hätte

Ich dachte, dies wäre das schwächste Glied im Stack. Es ist das stärkste.

Das Pack umfasst etwa 43 Claude Code Skills, die die gesamte Bandbreite von SaaS-Marketing abdecken: SEO-Recherche, Keyword-Planung, Onpage-Optimierung, Landingpage-Texte, CRO-Experimente, E-Mail-Nurture-Sequenzen, Content-Strategie, Analytics (GA4-Integration, Umsatzaufschlüsselungen nach Kanal), Funnel-Monitoring und Performance-Reporting. Anthropics eigenes Marketing-Plugin liefert die Slash-Commands /performance-report, /seo-audit und /email-sequence; das Community-Pack coreyhaines31/marketingskills erweitert die Funktionsoberfläche zusätzlich.

Der BookZ.AI-Engineer behauptet, dass dieses Skill Pack sein Produkt von 0 auf 1.000 Nutzer gebracht hat. Ich kann die Nutzerzahl nicht unabhängig verifizieren — das ist seine interne Angabe, und ich gebe sie als seine Behauptung wieder, nicht als Benchmark. Was ich verifizieren kann, ist die Richtung dessen, was das Pack tatsächlich tut: Es führt echte Audits durch, erzeugt konkrete Onpage-Verbesserungen und integriert sich mit GA4, um den Attributions-Loop zu schließen. Die gemeldeten Lighthouse-Scores seiner Seite — SEO 100, Best Practices 100, Accessibility 100, Performance 97 — sind genau die Werte, die ein kompetenter technischer Marketer in zwei Wochen fokussierter Arbeit erzielt. Das Pack komprimiert das auf wenige Stunden.

Hier seine gemeldete Ergebnisübersicht:

Der Teil, den ich nicht erwartet habe: Die Skills komponieren mit Engineering. Du kannst /seo-audit direkt auf deinen echten Code-Base laufen lassen, und es werden dir konkrete HTML-/Meta-Änderungen vorgeschlagen, die dann von den Engineering Skills über den TDD-Workflow von Superpowers umgesetzt werden — erst Tests, dann Fix, dann redeploy, dann erneutes Audit. Der Cycle ist geschlossen. Marketing ist kein isolierter Workflow, der ans Engineering angeflanscht ist. Es ist derselbe Workflow, andere Skills.

Falls du als Solo-Founder ein SaaS ohne dedizierten Marketing-Mitarbeiter betreibst, erledigt dieses Pack vermutlich mehr Arbeit pro Dollar als jedes andere Tool, das du installiert hast. Ich habe einen ausführlichen Beitrag zum Thema „Marketing-Team mit Claude Code aufbauen“ geschrieben, der genau auf diesem Stack aufbaut.

Wann ich darauf zurückgreife: Im Marketing-Modus, einmal pro Woche, Freitagmorgen. Das Skill Pack führt die Audits durch, reiht die CRO-Experimente ein, verfasst die E-Mails der Woche. Ich überprüfe, gebe frei, und es wird versendet.

Skill 8: Fixed Ticket — Die Bug-Fix-Pipeline

Das Beste kommt zum Schluss. Diese Fähigkeit hat mich dazu gebracht, meine Sichtweise auf die Aufgabenverteilung im Junior-Engineering grundlegend zu überdenken.

Fixed Ticket nimmt eine Jira-Ticket-URL als Eingabe. Es liefert einen ausgerollten Fix sowie die Übergabe an das QA-Team zurück. Jede Zwischenstufe ist automatisiert, mit nur einem einzigen Human-in-the-Loop-Checkpoint in der Freigabephase.

Hier ist der siebenstufige Workflow, direkt aus dem Walkthrough des Entwicklers:

Die Aussage des Entwicklers ist, dass diese Fähigkeit ungefähr 90 % der Bugfix-Arbeit eines Junior Engineers ersetzt. Mit dieser Zahl gehe ich vorsichtig um, denn sie basiert auf seiner Beobachtung in seinem Team — je nach Komplexität der Codebasis, Testabdeckung und Qualität der Jira-Tickets kann es stark variieren. Ein miserables Jira-Ticket („App ist kaputt, bitte fixen“) bringt die Skill bereits in Stufe 1 zum Scheitern.

Was ich nach eigenen Tests an meinem Backlog bestätigen kann: Bei Tickets mit eindeutigem Repro-Schritt und verknüpftem Sentry-Log schloss die Skill diese End-to-End ab — ohne dass ich eine Zeile Code schreiben musste. Bei vagen oder architektonisch unklaren Tickets blieb sie in Stufe 3 (Diagnose) stehen und forderte eine Konkretisierung an — exakt wie es sein soll. Sie hat sich keinen Fix ausgedacht, nichts Falsches ausgeliefert. Sie hat nachgefragt.

Der Freigabe-Checkpoint ist das entscheidende Feature. Jeder Fix-Plan landet auf deinem Schreibtisch, bevor irgendeine Codezeile geschrieben wurde. Du siehst die Hypothese, die vorgeschlagene Änderung, den geplanten Test und das Zielsystem für das Deployment. Du gibst frei oder leitest um. Dieser eine Checkpoint entscheidet, ob es sich um eine „automatisierte Bug-Pipeline“ oder einen „automatisierten Katastrophengenerator“ handelt.

Wann ich sie einsetze: Beim Montags-Triage-Check meines Jira-Backlogs. Ich genehmige in großen Blöcken die klaren Fix-Pläne, leite die unklaren um, und bis Mittwoch ist das Backlog messbar geschrumpft — ohne dass ich für die meisten Tickets eine Zeile Code selbst schreibe.

Wie sich die acht Skills zusammensetzen

Jede einzelne Fähigkeit löst für sich einen bestimmten Fehlermodus. Zusammengestapelt entsteht daraus etwas, das wie ein kleines Engineering-Team funktioniert:

• Superpowers ist die Methodik. Sie ist nicht verhandelbar und bildet das Fundament für alles Weitere.
• Skill Creator individualisiert die Methodik für deinen Workflow statt für den generischen Standard.
• UI/UX ProMax übernimmt die Designentscheidungen, damit du dich nicht darum kümmern musst.
• Playwright schließt die Lücke zwischen „Code ist geschrieben“ und „Code funktioniert“.
• Telegram bindet den Agenten vom Schreibtisch los, sodass lange Jobs im Hintergrund ablaufen können.
• Obsidian verleiht dem Agenten ein Projektgedächtnis, ohne zusätzliche Infrastruktur zu benötigen.
• Das Marketing-Pack schließt die Lücke zwischen „Produkt existiert“ und „Benutzer kommen“.
• Fixed Ticket ist der Kompressor für den Bug-Lifecycle — hier landet der Großteil der Zeitersparnis.

Die entscheidende Erkenntnis: Keine dieser Fähigkeiten sind klassische „Produktivitäts-Skills“. Jede ist chirurgisch präzise. Jede behebt genau ein spezifisches Problem, das im Standard-Claude-Code-Erlebnis auftritt. Der Stack funktioniert als Stack, weil sich die Lösungen nicht überschneiden — jede nimmt sich eine andere Phase der Produkt-Auslieferung vor und sie ergänzen sich statt sich zu behindern.

Wenn du einen ähnlichen Stack aufbaust, würde ich sie in dieser Reihenfolge implementieren:

1. Superpowers (Woche 1 — nichts anderes tun, bis das zur Gewohnheit wird)
2. Playwright (Woche 1 — schließt die wichtigste Schleife)
3. Obsidian (Woche 2 — läuft nebenbei; einmal einrichten und vergessen)
4. Fixed Ticket (Woche 2 — größte Zeitersparnis für bestehende Backlogs)
5. UI/UX ProMax (Woche 3 — sobald UI-Arbeit ansteht)
6. Das Marketing-Pack (Woche 3 — sobald es ein Produkt gibt, das vermarktet werden kann)
7. Telegram (Woche 4 — wenn alles soweit routiniert abläuft, dass es unbeaufsichtigt funktioniert)
8. Skill Creator (fortlaufend — sobald sich eigene Muster abzeichnen, beginnt der Ausbau)

Wo dieser Stack Schwächen hat

Zeit für intellektuelle Ehrlichkeit, denn jeder „Ich habe 8 Skills installiert und bin jetzt ein 10x Engineer“-Post ist eine Lüge.

Der Stack ist Claude-Ökosystem-spezifisch. Wenn dein Team mehrere Coding Agents einsetzt oder du Wert auf Anbieter-Portabilität legst, bist du bei einigen Skills (Superpowers, Skill Creator, die Claude-spezifischen Plugins) festgelegt. Die Skills, die dem offenen Agent Skills-Standard folgen, sind deutlich portabler.

Die Einrichtung kostet wirklich Zeit. Nicht die Installation — die geht in Minuten. Die Kosten entstehen durch das Erlernen der Konventionen jedes Skills, das Schreiben der design.md-Dateien, die Anbindung von Sentry an Jira, den Aufbau der Obsidian Vault-Struktur, die Erstellung der Marketing-Grundlagen. Plane mindestens eine Woche konzentrierter Einrichtung ein, bevor sich der Stack auszahlt. Wenn du das für einen 3-Tage-Sprint evaluierst, lass es.

Die „90%-Junior-Developer-Ersetzung“ von Fixed Ticket ist die Zahl des Erfinders, kein universeller Fakt. In meiner Codebase waren es anfangs eher 60% und stieg vielleicht auf 75%, nachdem ich mein Jira-Management und die Sentry-Anbindung optimiert hatte. Das ist immer noch enorm. Aber es sind keine 90%, und ich wäre skeptisch gegenüber jedem, der dir sagt, dass du ab Tag eins 90% erreichst.

Die Marketing-Skills sind nur so gut wie dein Analytics-Setup. Wenn GA4 nicht sauber eingebunden ist, sind die Funnel-Reports wertlos. Ohne Revenue-by-Channel-Tracking beruhen alle Optimierungsempfehlungen auf Vermutungen. Das Skill-Pack verstärkt eine saubere Einrichtung — es repariert aber kein kaputtes Setup.

Playwright ist fehleranfällig. Echte Browser verhalten sich manchmal unzuverlässig. Jede CI-Gate-Konfiguration, die sich darauf verlässt, braucht Retry-Logik und Screenshot-Aufnahme bei Fehlern, sonst verbringst du deine Fehlergewinne mit dem Debuggen von False Positives.

Was passiert, wenn du nichts installierst

Du bleibst beim Vibe Coding. Du lieferst Features ohne Tests aus. Dein Jira-Backlog wächst schneller, als du ihn abarbeiten kannst. Deine Landing Page erreicht in Lighthouse "Best Practices: 78" und du redest dir ein, das nächsten Quartal zu beheben. Dein Obsidian-Vault enthält 14 Notizen und wächst langsamer, als du Kontext verlierst. Du schickst dir selbst Telegram-Nachrichten, auf die du nie reagierst, weil am anderen Ende kein Agent wartet.

Das ist die Claude-Code-Erfahrung, die die meisten Engineers 2026 machen. Sie ist produktiv. Sie ist tatsächlich schneller als Coden ohne KI. Aber sie unterscheidet sich qualitativ nicht von dem, was ein erfahrener Engineer 2023 mit einer guten Autovervollständigung leisten könnte. Der Skills Stack sorgt für den qualitativen Sprung – von „KI hilft mir, schneller zu coden“ zum „KI liefert Produkte aus, während ich schlafe.“

Ich erinnere mich noch genau an den Moment, den ich am Anfang erwähnt habe – die Fixed Ticket skill, die selbstständig ein Deploy auslöst, während ich zuschaue. Das anfängliche Unbehagen ist verschwunden. Das nachhaltigere Gefühl, das an seine Stelle getreten ist: Jede Stunde, in der ich diesen Stack nicht laufen habe, ist eine Stunde, in der ich Arbeit mache, die ein gut konfigurierter Agent für mich erledigen könnte. Das ist die Rechnung, auf die ich immer wieder zurückkomme. Wenn du als Solo-Engineer 2026 ein Produkt shipst, stellt sich nicht die Frage, ob du einen Skills Stack installierst. Sondern welchen – und wie schnell.

Wähle diese Woche drei Skills von dieser Liste aus. Superpowers, Playwright und Obsidian sind meine Empfehlung, wenn du das stärkste Start-Set möchtest. Installiere sie heute Abend. Nutze sie am Montag. Komm in zwei Wochen wieder hierher und sag mir, was du ändern würdest.

Lass uns zusammenarbeiten

Möchten Sie KI-Systeme entwickeln, Workflows automatisieren oder Ihre Tech-Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

• Fiverr (maßgeschneiderte Lösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Security Services): xcybersecurity.io