Loops und ihre Skills

Ein Loop ist kein einzelner großer Prompt. Jeder Loop ist ein Regal voller Skills: eine kurze Datei, die sagt, was der Loop ist und was in seinem Bereich als Fund zählt, dazu seine Skills, jeder eine in sich geschlossene Methode für eine Art von Frage innerhalb dieses Bereichs: zwei im kleinsten Regal, elf bei Security. Ein Lauf öffnet genau einen Skill und arbeitet ihn von Anfang bis Ende ab.

Diese Seite listet, was in jedem Regal steht. Die Skills sind im offenen Format Agent Skills geschrieben – eine Datei SKILL.md pro Loop, daneben jede Methode als eigene Referenzdatei – und es sind dieselben Dateien, die ein Tekk-Lauf einbindet, wenn er an deinem Code arbeitet.

Dein Board aus deinem Agent heraus steuern

Die zehn Skills, mit denen du Tekk selbst steuerst, werden als ein Plugin installiert, das auch den Tekk-MCP-Server verbindet. Vier arbeiten am Board: die Proposal-Inbox mit sweep abarbeiten, Specs mit blitz auf parallele Coding-Sessions verteilen, das Board mit triage gegen Git abgleichen und Specs schreiben, die sich wirklich schließen lassen. Sechs weitere richten die Loops aus und halten die Arbeit in Gang: grill-to-steer richtet sie auf das aus, was dir wichtig ist, steer-loops legt fest, was wann läuft, feedback sagt ihnen, was die letzte Runde wert war, grill-to-loop und ideate-loops entwerfen neue, und night-shift arbeitet das Board ab, während du schläfst.

/plugin marketplace add guccikudo92615/tekk-skills
/plugin install tekk@tekk

Für Codex, Cursor und andere Agents nimmst du die Skills und fügst den MCP-Server hinzu, wie in der Doku zum MCP-Server beschrieben:

npx skills add guccikudo92615/tekk-skills -a codex

Mit diesen zehn bedienst du Tekk. Die Review-Skills, die unten dokumentiert sind, sind etwas anderes: Sie sind die Methodik, die die Loops auf deinen Code anwenden, sie laufen in Tekk statt in deinem Terminal, und sie werden nicht separat verteilt.

Was die Loops über jede einzelne Methode hinaus beitragen, ist alles drumherum: entscheiden, welcher Loop es wert ist, geweckt zu werden, und wann; das Briefing zusammenstellen, das sagt, was sich geändert hat und was du schon abgelehnt hast; den Skill anhand seiner eigenen Bilanz auf deinem Projekt auswählen; und aus einem Fund eine Spec auf deinem Board machen.

Wie ein Lauf einen Skill wählt

Wenn ein Loop aufwacht, ist seine Methode nicht vorab festgelegt. Der Lauf bekommt sein Briefing – was sich seit seinem letzten Lauf geändert hat, was er und alle anderen Loops zuletzt vorgeschlagen haben und was du jeweils damit gemacht hast, wie jeder seiner Skills auf deinem Projekt abgeschnitten hat, und eine Momentaufnahme der gemessenen Größenordnung deines Produkts – und öffnet dann das Regal. Zwei Dinge geben bei der Wahl den Ausschlag:

• Worum es bei der Änderung wirklich geht. Ein Diff, der einen Webhook-Empfänger berührt, ist eine Frage für retry-safety oder webhooks-and-fulfillment, nicht für render-performance.
• Die Bilanz. Ein Skill, dessen Proposals immer wieder angenommen werden, hat sich eine weitere Runde verdient. Einem Skill, dessen Proposals du immer wieder ablehnst, steht keine Runde zu, nur weil er am längsten nicht dran war.

Der Lauf beginnt mit einer kurzen Standortbestimmung – worum es in diesem Lauf geht, welchen Skill er öffnet und warum, und was er prüfen wird – und liest dann den Code mit genau dieser einen Methode. Ändert er beim Lesen seine Meinung, darf er einmal wechseln. Jeder Lauf hält fest, welchen Skill er tatsächlich bearbeitet hat, damit der nächste Lauf weiß, welche Methoden des Loops wirklich schon zum Einsatz kamen.

Ein Lauf erzeugt höchstens ein Proposal, und ein Lauf, der nichts findet, ist ein vollständiger Lauf – er wird als ehrliches Negativergebnis festgehalten, damit der Loop morgen nicht dasselbe Terrain noch einmal prüft.

Die Loops

Sechzehn Loops gibt es heute. Jeder ist pro Workspace Opt-in. Fünfzehn davon kommen allein mit deinem Repository aus; wo einer mit einem verbundenen Tool schärfer wird, steht es in seinem Abschnitt. Die Ausnahme ist Customer feedback: Dieser Loop liest, was deine Kundschaft meldet, und läuft deshalb nur, wenn ein verbundenes Feedback-Tool eine neue Meldung liefert.

Security

Prüft aktuelle Codeänderungen auf Sicherheitslücken – fehlende Auth-Prüfungen, offengelegte Daten, Injection, Lecks zwischen Mandanten – und schlägt Fixes vor. Er prüft so, wie man angreift, um einen Dienst umsonst zu nutzen oder an die Daten eines anderen Mandanten zu kommen, nicht wie eine Checkliste, und belegt jeden Fund mit einem nachverfolgten Request statt mit einem Musterabgleich. Fünf seiner Skills decken je eine Vertrauensgrenze ab; die übrigen sechs gehen unter einem dieser fünf eine Ebene tiefer, für den Fall, dass die erste Prüfung hält und die Frage darunter liegt.

Skill	Was er prüft
auth-and-access	Wer was tun darf – Eigentums- und Rollenprüfungen auf jeder Route, IDOR, Check-then-act-Races, Durchsetzung von Berechtigungen – und die Abläufe für Signup, Login, Passwort-Reset und Sessions, die überhaupt erst Identität vergeben.
identity-protocols	Unter auth-and-access: ob die Schicht unter einer korrekten Zugriffsprüfung einen Request der falschen Person, Session oder dem falschen Token zuordnen kann – CSRF, Session Fixation, JWT-Prüfung, OAuth-Callbacks und Account-Verknüpfung, MFA und Wiederherstellung, vertraute Host- und Origin-Header, CORS mit Credentials.
tenant-isolation	Ob ein Mandant an die Daten eines anderen kommt: Abdeckung durch Row-Level Security, die Umgehung über die Service-Role, Mandanten-Scope aus der Session statt aus dem Request und Lecks über Joins, Caches, Exporte und Admin-Pfade.
rls-patterns	Unter tenant-isolation: welche Form ein korrekter Fix hat, sobald eine Lücke gefunden ist – Isolation durch eine Row-Level-Security-Policy in der Datenbank statt durch einen Filter, an den jemand denken muss, und Rollen mit nicht mehr Rechten als nötig.
data-lifecycle	Unter tenant-isolation: jede Kopie eines Datensatzes, nicht nur die geschützte Tabelle – Cache-Keys und Speicherpfade, signierte Links, Suchindizes und Embeddings, Exporte und Importe und ob Löschen, Widerrufen und Wiederherstellen sie wirklich erreichen.
money-and-webhooks	Ob sich jemand bezahlte Features holen kann, ohne zu zahlen, und ob eingehende Webhooks von Anbietern gefälscht, wiederholt oder auf einen anderen Account umgelenkt werden können.
logic-and-spend	Unter money-and-webhooks: die Umgehungen, die kein Scanner findet – übersprungene oder wiederholte Schritte in einem Ablauf, der mit einer Freischaltung endet, Races, an deren Ende Geld steht, Zahlen, die sich verbiegen lassen, Events in falscher Reihenfolge – und ein gültiger Account, der über unbegrenzte bezahlte Aufrufe zur Rechnung eines anderen wird.
injection-and-input	Nicht vertrauenswürdige Eingaben, die eine gefährliche Senke erreichen – SQL, Shell, SSRF, Path Traversal, unsichere Deserialisierung – und dieselbe Lücke in ihrer Agent-Variante: Prompt Injection, ungeprüfte Tool-Autorisierung, Modellausgaben, denen nachgelagert blind vertraut wird.
agents-and-browsers	Unter injection-and-input: die Senken, die ein Modell oder eine Seite in der Hand hat – Inhalte, die in den Kontext eines anderen Users gelangen, ein Tool, das mehr darf als die Person, die es auslöst, die Identität von MCP-Servern und Sub-Agents, Modellausgaben, auf die ungeprüft gehandelt wird, und Quellen, die nur der Browser sieht.
secrets-and-crypto	Wie Zugangsdaten gespeichert, offengelegt und rotiert werden – Keys im Code, Secrets in Logs, Fehlerantworten und Client-Bundles – dazu Passwort-Hashing, die Zufälligkeit von Tokens und die Supply-Chain-Angriffsfläche darunter.
ci-and-supply-chain	Unter secrets-and-crypto: wessen Code mit welchen Secrets läuft – nicht vertrauenswürdiger Code aus einem Pull Request in einem privilegierten Workflow, Injection in CI-Ausdrücke, Caches und Artefakte, die Vertrauensgrenzen überschreiten, zu weit gefasste Tokens, Dependency Confusion und was tatsächlich in einem Release landet.

Reliability

Prüft deinen Code darauf, wie er bei echten Ausfällen bricht – eine Abhängigkeit, die ohne Deadline in den Timeout läuft, ein Retry, der eine Zahlung zweimal ausführt, ein verschluckter Fehler, der wie Erfolg aussieht, eine unbegrenzte Operation, die den Speicher erschöpft – und schlägt den Fix vor. Schärfer mit verbundenem Sentry; funktioniert auch ohne.

Skill	Was er prüft
dependency-boundary	Jeden Aufruf, der den Prozess verlässt – HTTP, Datenbank, Cache, Queue – auf Deadlines, Retry-Policy, Backoff und Begrenzung des Schadensradius.
retry-safety	Zustandsänderungen, die mehr als einmal laufen können – ein erneut zugestellter Webhook, ein wiederholter Job, ein doppeltes Absenden – auf die Deduplizierung, die die zweite Ausführung harmlos macht.
resource-limits	Was unter Last ausgeht: erschöpfte Pools, eine Verbindung, die über ein await hinweg gehalten wird, unbegrenzte Queries und Akkumulatoren, Uploads ohne Größenlimit, nicht freigegebene Handles.
failure-handling	Was der Code tut, wenn schon etwas schiefgegangen ist – leere catch-Blöcke, Fehler bei einem Schreibvorgang, die geloggt und dann übergangen werden, ein Fehlschlag, der Erfolg meldet, halb angewendete mehrstufige Arbeit.

Backend

Prüft alles hinter deiner API auf die Bugs, die man als Founder nicht sieht – ungeprüfte Eingaben, ein Retry, der doppelt abbucht, zwei parallele Requests, die ein Duplikat anlegen, ein verschluckter Fehler, eine Query ohne Index, eine Migration, die das nächste Deploy kaputt machen könnte – und schlägt den Fix vor.

Skill	Was er prüft
api-correctness	Die Vertrauensgrenze eines Request-Handlers: Eingaben, die dort validiert werden, wo sie hereinkommen, Fehler, die sichtbar fehlschlagen, statt verschluckt zu werden, und die Defaults, die das Verhalten unter Last bestimmen – Pagination-Limits, Timeouts, Body-Limits, Rate-Limits, CORS.
idempotency-and-jobs	Alles, was zweimal passieren oder sich überschneiden kann – nicht idempotente Schreibvorgänge bei Retries, Check-then-act-Races, mehrstufige Schreibvorgänge ohne Transaktion, Queue- und Cron-Consumer ohne Retry-, Dead-Letter- oder Lock-Disziplin.
query-and-index	Wie die App liest – N+1-Queries, Filter auf nicht indizierten Spalten, unbegrenzte Scans, zu viel geladene Daten und ORM-Aufrufe, die etwas Pathologisches erzeugen.
index-choices	Unter query-and-index: welche Form der Fix hat, sobald ein langsamer Lesezugriff gefunden ist – der Foreign Key, den niemand indiziert hat, die Spaltenreihenfolge zusammengesetzter Indizes, partielle und abdeckende Indizes und Cursor-Pagination statt eines tiefen Offsets.
schema-and-migrations	Die Form der Daten und wie sie sich ändert – Migrationen, die ein nicht atomares Deploy überstehen müssen, Constraints, die fehlerhafte Zeilen fernhalten, Datentypen, Pool-Konfiguration.

Payments

Prüft deinen Billing-Code auf die Bugs, die Geld kosten – eine bezahlte Anmeldung, die nichts freischaltet, ein Retry, der doppelt abbucht, Zugang, der bei einer Kündigung nie entzogen wird, eine abgedriftete Price-ID – und schlägt den Fix vor.

Skill	Was er prüft
webhooks-and-fulfillment	Ob jedes geldkritische Event des Anbieters behandelt wird und die Bereitstellung genau einmal läuft – At-least-once-Zustellung ohne Deduplizierung, Updates in falscher Reihenfolge, der Trial-Pfad, der nichts freischaltet.
entitlements	Was man nach der Zahlung tatsächlich tun kann – zu jeder Freischaltung ein passender Entzug, Kündigung und fehlgeschlagene Verlängerung, die in einem definierten Zustand enden, Zugang auf Basis des echten Abo-Status statt eines veralteten Caches.
billing-config	Die Konfiguration, die bestimmt, was verkauft wird – Price- und Plan-IDs, verteilt auf Env und Code, Keys für Test- und Live-Modus, Zuordnungen von Plänen zu Features, die vom Anbieter abdriften.

Performance

Spürt langsame Queries, langsame Endpunkte und Latenzspitzen auf und schlägt gezielte Beschleunigungen vor – dazu Infrastrukturkosten, die nichts bringen: ein Polling, das ein Webhook sein sollte, ein Dienst, der ständig läuft, unnötiger ausgehender Traffic. Schärfer mit verbundenem Sentry.

Skill	Was er prüft
query-latency	Wie die App unter Last liest – eine Query in einem Loop, ein Lookup pro Zeile, der eine einzige gebündelte Query sein sollte, nicht indizierte Queries auf einem Hot Path, Pagination, die die ganze Tabelle scannt.
hot-path-blocking	Worauf ein Request wartet – synchrones I/O oder schwere CPU-Last in einem Handler, ein externer Aufruf ohne Timeout, Arbeit, die in eine Queue gehört, eine Antwort, die ohne Cache gebaut wird.
infra-spend	Die Infrastrukturrechnung – ein Cron, wo ein Event genügen würde, ein Zeitplan, der viel enger getaktet ist, als sich seine Eingaben ändern, ein Dienst, der ständig läuft und on demand laufen könnte, bezahlte Dienste, die noch angebunden sind, aber nicht genutzt werden.
algorithmic-cost	Der Code selbst – ein verschachtelter Loop, der aus linear quadratisch macht, eine Liste, die durchsucht wird, wo eine Map indizieren würde, eine ganze Collection, die geladen wird, nur um sie zu zählen, reine Berechnungen, die erneut ausgeführt statt memoisiert werden.

Testing

Findet riskantes geändertes Verhalten ohne Tests, Tests, die nie fehlschlagen können oder nur festschreiben, wie der Code geschrieben ist, Tests, die zufällig fehlschlagen, und Tests, die mehr Zeit kosten, als die Sicherheit wert ist, die sie bringen – und schlägt den Fix vor, wobei er genauso bereitwillig löscht und zusammenlegt wie ergänzt.

Skill	Was er prüft
coverage	Geändertes Verhalten und die Tests, die ihm fehlen – neue Branches und Fehlerpfade, Bugfixes ohne Regressionstest, Verträge, deren Tests sie nicht mehr prüfen.
flakiness	Nichtdeterminismus – feste Sleeps statt Waits, Zustand, der zwischen Tests geteilt wird, Abhängigkeit von der Reihenfolge, echte Uhren, Zufall ohne Seed, echtes Netzwerk-I/O – und eine Stabilisierung oder eine ehrliche Quarantäne.
pruning	Tests, die Pflege kosten und keine Sicherheit bringen – Tests, die nicht fehlschlagen können, Tests, die die Implementierung statt des Verhaltens festschreiben, Mocks, die gegen sich selbst geprüft werden, Duplikate, übersprungene Tests, Snapshots ganzer Bäume – und ob jeder davon gelöscht, zusammengelegt oder umgeschrieben gehört.
suite-speed	Laufzeit, die die Suite nicht braucht – echtes I/O, das gefakt werden sollte, aufwendiges Setup pro Test, das geteilt werden könnte, unabhängige Fälle, die nacheinander laufen –, ohne eine einzige Prüfung zu streichen.

React

Prüft React-Komponenten auf Bugs und verschwendete Renders – veralteten State, falsch eingesetzte Effects, unnötige Re-Renders – und schlägt Fixes vor.

Skill	Was er prüft
state-and-effects	Wo State liegt und wann Effects laufen – Index als Key, fehlende oder instabile Effect-Abhängigkeiten, State, der abgeleitet sein sollte, Effects, die die Arbeit eines Event-Handlers machen, asynchrone Races.
render-performance	Was eine Komponente beim Rendern kostet und wie weit sie andere neu rendern lässt – instabile Props und Context-Werte, zu breite Subscriptions, lange nicht virtualisierte Listen, Updates, die das Tippen blockieren.
markup-safety	Was das gerenderte Markup mit den Menschen macht, die es nutzen – unbereinigtes HTML, das ins DOM eingefügt wird, und Bedienelemente ohne zugänglichen Namen, Tastaturpfad oder korrekte Semantik.

Code quality

Räumt auf, was KI-Coding-Agents in deinem Code hinterlassen – erzählende Kommentare, unnötige Wrapper und defensive Prüfungen, Type-Escapes, liegen gebliebene Debug-Ausgaben, halb fertige Umbenennungen und Migrationen –, ohne zu ändern, was deine App tut, sodass seine Fixes kaum Review brauchen. Wie Module die Arbeit aufteilen, gehört zu Architecture.

Skill	Was er prüft
deslop	Die Anweisungsebene – erzählende und veraltete Kommentare, Debug-Reste, defensive Prüfungen, die keine benachbarte Funktion braucht, Wrapper, die nur durchreichen, Helper mit einer einzigen Verwendung, toter und spekulativer Code, fast doppelte Logik und Kopien, die auseinandergelaufen sind.
propagation	Was eine Umbenennung oder Migration zurückgelassen hat – jede Stelle, die noch die alte Form eines Werts nutzt, dessen Identität sich geändert hat (Umgebungsvariablen, Konstanten, Config-Keys, API-Routen, die Docs, die sie zitieren), und Code, der nach dem Umstieg noch an der alten API oder Library hängt.
types	Type-Escapes – any, um den Compiler zum Schweigen zu bringen, verkettete Assertions, Unterdrückungskommentare ohne Begründung, Enums, die mit rohen Literalen umgangen werden – ersetzt durch den Typ, den der Code tatsächlich angeben könnte, ohne zu ändern, was läuft.

Architecture

Findet die Stellen, an denen die Struktur deiner Codebase jede Änderung teurer macht, als sie sein müsste, gereiht danach, wo Änderungen tatsächlich landen, und schlägt den Umbau vor, der sich auszahlt. Was die App an ihren Rändern tut, bleibt gleich; die Schnittstellen dahinter dürfen sich ändern. Er wacht auf, wenn eine Änderung eine Datei über tausend Zeilen wachsen lässt, einen Import-Zyklus einführt, in die Interna eines anderen Moduls greift oder Logik neu schreibt, die es schon gibt, und wenn ein viel bearbeiteter Bereich länger nicht mehr als Ganzes gelesen wurde.

Skill	Was er prüft
coupling	Die Abhängigkeiten, durch die sich eine Änderung ausbreitet – überschrittene Schichtgrenzen, Anbieterdetails, die durch ihre Schnittstelle sickern, Import-Zyklen, Dateien, die sich immer gemeinsam ändern, ohne einander zu importieren, Knoten, die stark importiert und ständig geändert werden.
decomposition	Dateien und Funktionen, die mehr Aufgaben angesammelt haben, als sie tragen können, aufgeteilt entlang einer Naht, die die Änderungshistorie stützt, und Logik, die in mehreren Modulen oder Einstiegspunkten doppelt geschrieben ist.
deepening	Flache Module, deren Schnittstelle fast so komplex ist wie das, was sie verbergen – Schichten, die nur durchreichen, eine Entscheidung, die an zwei Stellen bekannt ist, ein gemeinsamer Helper, der pro Aufrufer ein Flag dazubekommt – und das tiefere Modul, das übernimmt, was die Aufrufer heute selbst zusammensetzen.

AI engineering

Recherchiert, wie die besten Teams heute mit LLMs bauen – Doku der Anbieter, Engineering-Berichte und Paper – und schlägt das Upgrade vor, das dein Agent-Harness, deine Tools, dein Kontext, deine Memory, dein Retrieval, deine Evals oder Guardrails als Nächstes umsetzen könnten, oder die Änderung, die dasselbe Ergebnis für weniger Geld liefert.

Skill	Was er prüft
harness	Der Agent-Loop selbst – ob der „Agent“ ein echtes Harness mit Tool-Nutzung, Zustand, Planung und Fehlerbehandlung ist und ob die Arbeit richtig zwischen normalem Code, einem Agent und mehreren aufgeteilt ist.
safety	Die Tools, die ein Agent hat, und was ihn in Grenzen hält – die richtigen Tools, so beschrieben und typisiert, dass das Modell sie gut nutzt, nicht vertrauenswürdige Inhalte, die ihn steuern könnten, ungeprüfte Aktionen und Ausgaben und die Guardrail, mit der du ihm mehr Arbeit überlassen könntest.
context-engineering	Was den Kontext des Modells füllt und was es zwischen Aufrufen behält – Ballast im Kontext, Memory, die geschrieben, aber nie gelesen wird, Prompts, die Fakten verlangen, die nichts liefert, Blöcke, die über ihren Nutzen hinausgewachsen sind.
retrieval	Wie Wissen in den Kontext des Modells gelangt – ob Retrieval überhaupt die richtige Form hat und ob es das richtige Material findet oder nur das nächstliegende. Bringt einen Katalog von Retrieval-Methoden mit.
evals	Ob du einen Prompt, ein Modell oder eine Retrieval-Einstellung ändern und wissen kannst, dass es besser geworden ist, ob sich Fehlverhalten in Produktion diagnostizieren lässt und was jeder Aufruf für das kostet, was er bringt – die Steuer pro Agent-Turn, fehlendes Prompt-Caching, ein überdimensioniertes Modell für eine eng umrissene Aufgabe, Retries ohne Obergrenze.

Compliance

Prüft den Code, der personenbezogene Daten berührt, auf die Lücken, die DSGVO-Bußgelder bringen und EU-Deals kosten – Tracking, das vor der Einwilligung feuert, personenbezogene Daten, die ewig gespeichert werden oder sich nicht löschen lassen, Daten, die an einen Anbieter gehen, der sie nicht brauchte, Daten, die außerhalb der EU landen, obwohl deiner Kundschaft versprochen wurde, dass sie dort bleiben – und schlägt den Fix vor. Er wacht auf, wenn sich Code ändert, der personenbezogene Daten verarbeitet: Analytics-Anbindung, eine Tabelle mit personenbezogenen Daten, Lösch- oder Exportcode, ein Aufruf an einen Drittanbieter, eine Region oder ein Host in der Konfiguration.

Skill	Was er prüft
consent	Datenerhebung vor oder ohne Einwilligung – Analytics, Pixel, Cookies, Session Replay und Marketing, die beim Laden der App oder vor der Einwilligungsprüfung starten, eine Einwilligung, die angenommen statt festgehalten wird, keine Möglichkeit zum Widerruf, ein Ablehnen-Pfad, der trotzdem Daten erhebt.
data-residency	Wo personenbezogene Daten gespeichert und verarbeitet werden – Regionen von Datenbank, Bucket, Queue und Functions, SDKs, die auf einem US-Standardhost bleiben, obwohl der Anbieter einen EU-Host hat, Modellanbieter, die Inhalte von Usern bekommen, und eine Konfiguration, die dem „in der EU gehostet“ widerspricht, das deiner Kundschaft versprochen wurde.
retention-and-erasure	Wie lange personenbezogene Daten leben und ob sich jemand wirklich entfernen lässt – Speicher ohne Aufbewahrungsfrist oder Bereinigung, ein fehlender oder unvollständiger Löschpfad, ein Soft Delete, der die Daten stehen lässt, Kopien in Caches, Suchindizes und Exporten, die beim Löschen übersehen werden, und keine Möglichkeit, zu exportieren, was du über jemanden gespeichert hast.
third-party-transfer	Personenbezogene Daten, die das System verlassen – an Analytics, Modellanbieter, Error-Tracking, E-Mail oder Support – in größerer Form, als die Aufgabe braucht: ganze User-Objekte, wo eine ID genügen würde, Identifikatoren in URLs, Inhalte von Usern, die ungekürzt an ein Modell gehen.

Observability

Findet Teile der Produktion, die du nicht siehst – unbeobachtete Dienste, stille Jobs, verschwundene Abstürze, verschluckte Fehler, kritische Pfade ohne Tracing – und schlägt den fehlenden Check, das fehlende Log oder den fehlenden Span vor.

Skill	Was er prüft
uptime-and-heartbeats	Unbeaufsichtigte Arbeit, die niemand beobachtet – ein Dienst ohne Health-Endpunkt oder mit einem oberflächlichen, der immer grün ist, ein geplanter Job ohne Check-in.
crash-reporting	Jeden Einstiegspunkt der Anwendung auf Fehlerberichte – eine Server-, Worker- oder Client-Laufzeit ohne Error-Tracking-SDK, eine Initialisierung, die unbehandelte Rejections verpasst, ein SDK ohne Release oder Environment.
log-quality	Was der Code hinterlässt, wenn er scheitert – ein Fehlerzweig ohne Eintrag, unstrukturierte Meldungen ohne Correlation-ID, Log-Level, die echte Fehler begraben, Secrets, die in eine Logzeile geschrieben werden.
tracing-and-metrics	Ob die kritischsten Pfade – Zahlungen, Auth, ausgehende Aufrufe, Queue-Arbeit – Spans und Metriken ausgeben, die Erfolg, Fehlschlag und Latenz festhalten.

Alerts

Findet kritische Pfade ohne Alert – fehlgeschlagene Zahlungen, kaputte Webhooks, Auth-Fehler – und schlägt die genaue Sentry-Regel vor, die sie abfängt. Am schärfsten mit verbundenem Sentry, weil er dort die Regeln liest, die du schon hast; ohne Sentry meldet er die Lücke und sagt dazu, dass es eine passende Regel womöglich schon gibt.

Skill	Was er prüft
coverage-gaps	Die kritischen Pfade, die es im Code gibt, abzüglich der Alert-Regeln, die es im Projekt gibt, und die fehlende Regel mit konkreter Bedingung und Schwelle.
rule-quality	Alert-Regeln, die es schon gibt – Schwellen, die zu eng sind, um normalen Traffic zu überstehen, oder zu locker, um je auszulösen, doppelte Regeln, Alerts ohne Zuständigkeit oder Routing, Abdeckung, die abgedriftet ist, nachdem sich der Code verschoben hat.

Product analytics

Prüft, ob Analytics überhaupt angebunden ist, und richtet es, falls nicht, für dich ein – was du tracken solltest, wo und mit einem Tracking-Plan –, damit du deinen Funnel siehst. Schärfer mit verbundenem PostHog.

Skill	Was er prüft
event-coverage	Die echten User Journeys des Produkts – Signup, der Aktivierungsmoment, die zentrale wiederkehrende Aktion, Conversion – und ob irgendetwas sie erfasst, mit den konkreten Capture-Aufrufen und wo sie hingehören.
event-hygiene	Ob das Erfasste nutzbar ist – ein SDK, das wirklich initialisiert ist und feuert, konsistente, maschinenlesbare Namen, die Properties, die eine Frage braucht, keine personenbezogenen Daten als Property, ein Tracking-Plan statt eines Haufens.

Documentation

Hält den Text, den deine Coding-Agents lesen, korrekt, kurz und gut zu befolgen – die Instruktionsdateien für Agents, die Karte, wo was liegt, Docs, die nicht mehr zum Code passen, und das fehlende „Warum“ neben Code, der leicht kaputtgeht. Jeder Fund benennt den Irrweg, den er verhindert, und weniger Worte schlagen oft mehr. Er wacht auf, wenn eine Änderung etwas verschiebt, das ein Doc, eine Instruktionsdatei oder ein Kommentar beschreibt, und wenn die Docs eines Bereichs länger nicht mehr gegen seinen Code gelesen wurden.

Skill	Was er prüft
agent-context	Die Instruktionsdateien, die jede Agent-Session als Erstes lädt, etwa CLAUDE.md und AGENTS.md – ob jede Zeile stimmt, ihren Platz verdient und so auf die Details verweist, dass ein Agent dem Verweis auch folgt.
drift	Guides, READMEs und Design-Docs, die etwas behaupten, das der Code nicht mehr tut – Befehle, Pfade, Namen, Zahlen, Abläufe und Verhalten.
wayfinding	Ob man ohne Vorwissen in einen Bereich hineinfindet – ein klarer Einstieg, ein Name für jedes Konzept der Domäne und die bewussten, überraschenden Entscheidungen dort festgehalten, wo der nächste Agent ihnen begegnet.
why-comments	Die fehlende Begründung neben Code, den die naheliegende Änderung kaputt macht – eine Reihenfolge, ein Workaround, ein bewusstes Duplikat – und Kommentare, die Code beschreiben, der sich inzwischen geändert hat.

Customer feedback

Liest, was deine Kundschaft in den verbundenen Tools meldet – Bug-Reports, Support-Chats, Feature-Wünsche, Posts –, fasst die Meldungen zum selben Problem zusammen, verfolgt jedes Problem bis zum Code dahinter und schlägt den Fix, den Ausbau oder die Antwort vor. Er ist der einzige Loop, der nicht allein mit deinem Repository auskommt: Er wacht nur auf, wenn ein verbundenes Feedback-Tool (Jam, Intercom, Gmail, Canny, Zendesk, Freshdesk, Plain oder X) eine neue Meldung liefert, und läuft nie, wenn keines verbunden ist. Eine Beschwerde, die seit Wochen offen ist, zählt genauso wie eine neue.

Skill	Was er prüft
bug-report	Eine Meldung, dass etwas kaputt ist – aus der Konsole, den Netzwerk-Requests und den Klickschritten eines Jams, einem Support-Thread oder einem Ticket –, verfolgt bis zur Zeile, die fehlschlägt, und ob sie bei allen fehlschlägt, die dasselbe tun.
feature-request	Was sich die Kundschaft wünscht, abgeglichen mit dem Code – fehlt, halb gebaut oder gebaut, aber nicht zu finden – und gewichtet danach, wie viele verschiedene Leute es wollen.
repeated-question	Dieselbe Frage, immer wieder gestellt, zu etwas, das das Produkt schon kann – übersetzt in die Änderung, nach der niemand mehr fragen muss: die fehlenden Docs, der Onboarding-Text, der Empty State oder die Fehlermeldung.

Wo die Nahtstellen liegen

Mehrere Skills klingen von außen ähnlich, und die Regale legen bewusst fest, was zu wem gehört:

• Retries. retry-safety (Reliability) verantwortet die Deduplizierung, die eine zweite Ausführung harmlos macht; idempotency-and-jobs (Backend) die Transaktions- und Lock-Disziplin rund um Jobs und Webhook-Handler; webhooks-and-fulfillment (Payments) speziell die geldkritischen Events.
• Queries. Bei query-and-index (Backend) geht es um Korrektheit und den Index, der existieren sollte; bei query-latency (Performance) darum, was dieselbe Query auf einem Hot Path kostet.
• Webhooks und Geld. money-and-webhooks (Security) fragt, ob jemand einen Webhook fälschen oder wiederholen kann; webhooks-and-fulfillment (Payments) fragt, ob ein ehrlicher genau einmal behandelt wird.
• Barrierefreiheit. markup-safety (React) übernimmt die Barrierefreiheits-Hälfte des früheren UX-Loops.
• Struktur und Aufräumen. deslop (Code quality) vereinfacht Anweisungen, ohne zu ändern, was sie tun; coupling, decomposition und deepening (Architecture) ändern, wie Module die Arbeit aufteilen.
• Docs. propagation (Code quality) verantwortet das Nachziehen nach einer Umbenennung; drift (Documentation) die Guides, die nicht mehr zum Code passen. deslop löscht Kommentar-Rauschen; why-comments (Documentation) ergänzt die fehlende Begründung.
• Kopien personenbezogener Daten. data-lifecycle (Security) fragt, ob ein anderer Mandant an eine Kopie eines Datensatzes kommt; retention-and-erasure (Compliance) fragt, ob diese Kopie jemals verschwindet.
• Agents. agents-and-browsers (Security) fragt, ob nicht vertrauenswürdige Inhalte ein Modell über eine Grenze schieben können, die es nicht überschreiten darf; safety (AI engineering) fragt, ob die Tools und Guardrails eines Agents gut genug sind, um ihm mehr Arbeit zu überlassen.

Ein Fund im falschen Regal wird trotzdem gemeldet; die Nahtstelle entscheidet, an den Maßstäben welches Loops er gemessen wird, nicht, ob du davon erfährst.