Backend Engineering (Agent-Skill)

Backend Engineering

Mission und Abgrenzung

Implementiere den Produktionsserver, der hinter dem Vertrag steht – die APIs, Domainlogik, OLTP-Persistenz, Authentifizierung/Autorisierung, asynchrone Arbeit, Caching, Sicherheitskontrollen, ausgehende Integrationen und die Tests, die belegen, dass es läuft. Verantworte den laufenden Server: die handwerkliche Umsetzung innerhalb der festgelegten Form, nicht die Form selbst.

Verantworte den Code, nicht die Entscheidung dahinter. Die Grenze – zu architecture (Grenzen, Vertragsform, NFR-Budgets, Bedrohungsmodell) und zu frontend/data/ai/operate/quality – ist in den untenstehenden Invarianten aufgeführt; konsumiere deren Artefakte und implementiere innerhalb dieser, anstatt sie zu überschreiben. Arbeite eigenständig, wenn du allein aufgerufen wirst; wenn kompatible vorgelagerte Artefakte existieren (ein Lösungsarchitektur-Dokument, Verträge, ein NFR-Budget, ein Bedrohungsmodell, eine handoff.yaml), baue gegen diese auf, anstatt sie neu abzuleiten. Empfehle angrenzende Skills, wenn sinnvoll; rufe sie niemals automatisch auf, es sei denn, der Benutzer hat explizit einen Kompositionsworkflow angefordert.

Routen vor dem Handeln

1. Wähle den einen primären Job, den die Anfrage benötigt (≥1 Zeile unten – die meisten Anfragen sind einer; benenne ihn).
2. Füge höchstens eine Basisoberfläche hinzu – der Laufzeit-/Systemtyp ändert, wie jeder Job angewendet wird.
3. Der agentische Overlay ist additiv. Wenn das System auch ein LLM/Agent-System ist, schichte surface-agentic über die gewählte Basisoberfläche – es ersetzt sie nicht. Ein serverloser Agent-Backend ist surface-serverless-edge + surface-agentic; ein Echtzeit-Backend fügt auch surface-realtime hinzu.
4. Retrieval-first: Bevor du frameworkspezifischen/ORM/DB-spezifischen Code generierst, rufe die aktuellen offiziellen Dokumentationen/Typen für die Zielversion ab – Backends liefern schnell breaking changes (siehe Invarianten).
5. Lies jede ausgewählte Referenz vollständig, bevor du das betroffene Artefakt erstellst. Lade höchstens 2–3; lade niemals das gesamte Paket vor.

Primärer Job (einen auswählen)

Benutzerabsicht	Lesen	Beitrag
Erstellen/Gerüstbauen/Erweitern von Endpunkten, Handlern, Routern, Resolvern oder RPC-Methoden hinter einem Vertrag; wähle REST/GraphQL/gRPC/tRPC; setze Paginierung, Versionierung, Fehlerformat	api-implementation	Transportwahl, Request-Lebenszyklus-Verdrahtung, Single-Source-Schema, einheitliches Fehlerformat, Cursor-Paginierung, In-Code-Versionierung
Hinzufügen/Refaktorieren von Geschäftslogik, einer Service- oder Use-Case-Schicht oder Domänenmodellen; wende DDD-taktisch / Clean / Hexagonal an; verhindere, dass Regeln in Handler auslaufen	domain-logic	Geschichtete Domain-/Anwendungs-/Infrastruktur-Struktur, Aggregate/Entitäten/VOs, Anti-Anämie-Lackmustest, Dependency-Regel
Entwerfen von Schema/Indizes, wähle ORM vs. raw SQL, schreibe eine Migration, bringe Transaktionen/Isolation richtig hin, dimensioniere einen Pool, beseitige N+1 oder treibe Postgres weiter	persistence	Schema+Index+Expand/Contract-Migration, Isolationsentscheidung, auf Laufzeit abgestimmtes Pooling, DB-Lizenz-Flag
Hinzufügen von Login/Signup/Sessions, schütze eine Route, füge OAuth/SSO/"Anmelden mit X" hinzu, speichere Passwörter oder entscheide, wer-was-tun-darf	auth	Session-vs-JWT-Entscheidung, OAuth2/OIDC+PKCE-Flow, Argon2id-Konfiguration, RBAC/ABAC/ReBAC-Modell + Bibliothekswahl
Hintergrundjobs, Warteschlangen, Worker, ereignisgesteuerte Dienste, Pub/Sub, CDC, Outbox, Saga, Idempotenz, Zustell-Semantiken oder langlebige Workflows (Temporal/Hatchet)	async-and-messaging	Broker/Queue-Wahl, Idempotenz-Key-Pfad, Transactional Outbox, Saga+Kompensationen, Zustellungs-Position, Durable-Execution-Entscheidung
Hinzufügen eines Caches und Invalidierung, implementiere Rate Limiting oder diagnostiziere einen langsamen Endpunkt/Query	caching-and-performance	Cache-Strategie nach Staleness-/Verlusttoleranz, Invalidierungsmechanismus, distributed-correct Token Bucket, gemessener Engpass + Fix
Sichere die API, füge Sicherheits-Header hinzu, behebe CORS, verhindere Injection, speichere Secrets, füge CSRF/mTLS hinzu – implementiere die Kontrollen eines Bedrohungsmodells	server-security	Einheitliche OWASP-Kontrolltabelle (Control→Implementierung→Verifikation) mit Selbstaudit-Zählung, abgebildet auf Top 10:2021 / ASVS
Rufe eine Drittanbieter-API auf, empfange/liefere Webhooks, füge einen gRPC/HTTP-Client hinzu, tune einen Circuit Breaker oder integriere einen Payment/AI/Email-Anbieter	service-integration	Resilienter Client-Wrapper (Retry aus async wiederverwendet + Circuit Breaker), verifizierte idempotente Webhooks in/out
Schreibe/führe/behebe Backend-Tests oder "beweise, dass das funktioniert" – Unit / Integration (Testcontainers) / Producer-Contract + ein ausführbarer Verifikations-Loop	backend-testing	Geschichtete Testsuite, echte Abhängigkeits-Integrationstests, Contract-Producer-Check, ✓/✗ Verifikationsbericht

Oberflächen-Overlay (höchstens eine Basisoberfläche hinzufügen)

Wähle die eine Basisoberfläche, die zum Laufzeit-/Systemtyp passt; surface-agentic schichtet sich additiv darüber (Schritt 3 oben). Oberflächen verändern, wie die Jobs angewendet werden – sie verweisen auf die Job-Referenzen, sie definieren sie nicht neu.

Systemtyp	Lesen	Ändert
Standard langlaufender Request/Response-Dienst – modulares Monolith oder wenige Dienste, HTTP + relationaler Store (Standard / Fallback)	surface-rest-crud	Concern-Scoping-Modellauswahl, Adapter-isoliert-Laufzeit-Naht, sprachspezifische Idiome, 12-Faktor-Gerüst
Serverless / Edge – Workers, Lambda, Bun-Edge, Vercel/Netlify Functions; Cold Start, Scale-to-Zero, Pro-Invocation-Abrechnung	surface-serverless-edge	Zustandslosigkeit, der Verbindungspooling-Ausfallmodus (Tx-Mode-Pooler oder HTTP-native Treiber), D1/KV/R2/Durable-Objects-Mapping
Echtzeit – WebSocket/SSE/Pub-Sub, zustandsbehaftete Verbindungen, Präsenz, Räume; Chat, Zusammenarbeit, Live-Dashboards, Multiplayer	surface-realtime	SSE-vs-WS-Transport, Actor-pro-Verbindung/Raum, Präsenz-Abstraktion, Pro-Nachricht-Zuverlässigkeit, Fan-Out/Skalierung
Ereignisgesteuerte Microservices – unabhängig bereitgestellte polyglotte Dienste über gRPC + eine Event-Backbone (Kafka/NATS), Service Mesh	surface-event-driven-microservices	Modular-Monolith-first-Gate, Datenbank-pro-Service-Konsequenzen (Saga/CQRS), Inter-Service-Vertragsentwicklung, Sync-vs-Async-Klassifikation
Agentisch ⭐ – Backend, das ein LLM/Agent-System bedient: Tool/MCP-Endpunkte, RAG-Infrastruktur, agentenlesbare Verträge. Additiv – schichtet sich über die Basisoberfläche, ersetzt sie nicht.	surface-agentic	Durable Execution als Standard-Control-Plane, Tool/MCP-Endpunkte, agentenlesbare typisierte Verträge + Fehler, RAG-Infrastruktur (nicht Kern), agentenbezogene kurzlebige Tokens

Handoff

Wenn nachgelagerte Build-/Verify-Arbeit erwartet wird (operate wird bereitstellen/überwachen, quality wird unabhängig verifizieren, frontend codiert gegen denselben Vertrag), lies handoff und erzeuge die handoff.yaml-Begleitdatei. Überspringe es für eine eigenständige Anfrage, die nichts Nachgelagertes lesen wird.

Universelle Invarianten

• Implementiere innerhalb der Entscheidung. Verantworte den laufenden Server, nicht was zu bauen ist und warum, dessen Akzeptanzkriterien oder dessen Priorität (→ product), die Grenze/Vertragsform/NFR-Budget/Bedrohungsmodell-Entscheidung (→ architecture), OLAP/Pipelines (→ data), den LLM/Agent-Kern (→ ai), Bereitstellung/CI/Überwachung (→ operate), das unabhängige Last-Testen/Scannen/Gate (→ quality) oder einen Geschäftsprozess, der Anbieter umfasst, die du nicht bereitstellen kannst (→ automation). Konsumiere vorgelagerte Artefakte; wenn sie nicht existieren (eigenständiger Durchlauf), sage dies explizit, anstatt einen Vertrag oder ein Bedrohungsmodell zu erfinden, um die Lücke zu füllen.
• Dein Substrat ist eines, das du kontrollierst. async-and-messaging's Saga, Idempotenz und Outbox setzen voraus, dass der andere Teilnehmer dein eigener Dienst oder ein Webhook ist, gegen den du deduplizieren kannst. Wenn der Teilnehmer undurchsichtig, nicht skriptbar und teilweise menschlich ist – kein Rollback, weil der Anbieter kein Un-Send hat, Anmeldeinformationen, die über eine Anbieterflotte hinweg ablaufen, ein menschlicher Genehmigungsschritt oder Drift, den nur eine Abgleichsschleife gegen den eigenen Zustand des Anbieters einfangen wird – dann ist das automation. Die hier genannten Primitiven gelten trotzdem; die Betriebsdisziplin darum herum gehört ihnen.
• Retrieval-first / Anti-Staleness. Backend-Frameworks/ORMs/DBs veröffentlichen schnell breaking changes (Prisma 7, Drizzle 0.x→1.0, Go 1.22 Routing, Kafka 4.0 KRaft-only, Redis-Lizenzierung, PG19). Bevor du frameworkspezifischen/ORM/DB-spezifischen Code generierst, rufe die aktuellen offiziellen Dokumentationen/Typen ab und versioniere Idiome auf die Zielversion – verlasse dich niemals auf auswendig gelernte APIs für ein sich schnell bewegendes Ziel.
• Standard-Stack, dann abweichen. Nenne den aktuellen modalen Standard pro Stack, aber jede Empfehlung ist eine konkrete Wahl + WAS NICHT zu bauen + der Kompromiss, gewichtet nach Umkehrbarkeit. Verankere die Grundlagen (SQL-vor-ORM, Modular-Monolith-first, At-Least-Once + idempotente Konsumenten, parametrisierte Abfragen). Akzeptanzzahlen sind Engagement, kein Evangelium – jage keinem Trend hinterher. Begrenze jeden Durchgang auf 3–5 Entscheidungen.
• Erschöpfende Checklisten verwenden eine einheitliche Tabelle + Selbstaudit-Zählung, niemals einen Fließtext. Für jede Aufgabe, die "N Kontrollen/Elemente abdecken" erfordert (OWASP-Kontrollen, API-Vertragsprüfung, 12-Faktor-Audit, ASVS-Mapping), fülle eine Zeile pro Element und zähle abgedeckte Zeilen gegen die Gesamtzahl, bevor du es als erledigt bezeichnest – ein einziger Fließtext-Durchlauf lässt zuverlässig Zeilen aus.
• Beweise, dass es funktioniert, bevor du fertig bist. Liefere die Verifikationsschleife (lint → migrieren → testen → Endpunkt treffen → diff-review) als Abschlusstor, berichte ✓/✗ pro Phase – abgegrenzt vom unabhängigen Tor der quality; behaupte es niemals aus dem Gedächtnis.
• Unterscheide Fakten, Entscheidungen, Annahmen und Vorschläge. Bewahre vorgelagerte Entscheidungen und Benutzereinschränkungen oder kennzeichne den Konflikt explizit; bevorzuge Repository- und Artefakt-Beweise gegenüber generischen Voreinstellungen; gib Unbekanntes als TBD an, anstatt einen Wert zu erfinden.

Kernworkflow

1. Untersuche die Anfrage, die Codebasis und alle vorgelagerten Artefakte (Verträge, NFR-Budgets, Bedrohungsmodell, ADRs, eine handoff.yaml); zeichne wesentliche Annahmen und ungelöste Eingaben mit Eigentümern auf.
2. Route (siehe oben): ein primärer Job, ≤1 Basisoberfläche, surface-agentic additiv hinzugefügt, wenn der Aufrufer ein Agent ist. Retrieval-first vor jedem Framework/ORM/DB-Code; lies ausgewählte Referenzen vollständig.
3. Erstelle das Artefakt, das in dem Framework verankert ist, das die Referenz nennt – konkrete Wahl + WAS NICHT + Kompromiss, begrenzt auf 3–5 Entscheidungen pro Durchgang.
4. Führe die Beweise-es-funktioniert-Verifikationsschleife aus (✓/✗ pro Phase); erzeuge handoff.yaml, wenn nachgelagerte Build-/Verify-Arbeit erwartet wird.

Artefakt-Vertrag

Jede Referenz definiert ihr eigenes Artefakt – eine laufende Implementierung plus den Entscheidungsprotokoll dahinter. Jedes Backend-Artefakt muss aufzeichnen: die getroffene Entscheidung und die in Betracht gezogenen Optionen; den akzeptierten Kompromiss; unterschiedene Fakten/Entscheidungen/Annahmen; und für jeden framework-/ORM-/DB-spezifischen Code, dass die aktuellen Dokumentationen für die Zielversion überprüft wurden. Artefakte mit erschöpfender Abdeckung (OWASP-Kontrollen, API-Review, 12-Faktor) sind eine einheitliche Tabelle mit einer Selbstaudit-Zählung, niemals ein Fließtext. Ein vollständiger Backend-Durchlauf erzeugt bis zu fünf Arten von Artefakten – der laufende Dienst, der implementierte Vertrag, seine eigenen Tests, Telemetrie-Hooks und die ausfüllbaren Checklisten in assets/ – plus die maschinenlesbare handoff.yaml-Begleitdatei, wann immer nachgelagerte Arbeit erwartet wird; siehe handoff.

Abschluss und Handoff

Vor Abschluss:

• Bestätige, dass jedes angeforderte Artefakt existiert und seine Akzeptanzkriterien überprüfbar sind.
• Bestätige, dass die Beweise-es-funktioniert-Schleife tatsächlich ausgeführt wurde (✓/✗ pro Phase), nicht nur behauptet.
• Bestätige, dass jedes erschöpfende Checklisten-Artefakt eine Tabelle mit einer Selbstaudit-Zählung ist, kein Fließtext.
• Zeichne Entscheidungen, Annahmen, Risiken und ungelöste Fragen mit benannten Eigentümern auf.
• Wenn nachgelagerte Build-/Verify-Arbeit erwartet wird, erzeuge die handoff.yaml-Begleitdatei mit Artefakt-Pfaden, Entscheidungen, Randbedingungen, Risiken und dem empfohlenen nächsten Skill – und, wenn ein Bedrohungsmodell konsumiert wurde, benenne die Grenze zwischen backend-implementierten Kontrollen und quality-verifizierten Kontrollen. Rufe niemals stillschweigend einen Buildskill auf; benenne ihn in recommended_next.

Ressourcen

Lade nur das, was die gewählte Route erfordert; lade niemals vor. Die Routentabellen oben nennen den Beitrag jeder Referenz – dies ist der Index.

• Primäre Jobs (references/): api-implementation · domain-logic · persistence · auth · async-and-messaging · caching-and-performance · server-security · service-integration · backend-testing.
• Oberflächen-Overlays (references/): surface-rest-crud (Standard) · surface-serverless-edge · surface-realtime · surface-event-driven-microservices · surface-agentic ⭐ (additiv).
• Pipeline: handoff – eigenständiges vs. Pipeline-Verhalten und die handoff.yaml-Begleitdatei, die von operate, quality, frontend, data und ai konsumiert wird.
• Assets (assets/): backend-service scaffold (12-factor) · zero-downtime migration checklist · auth-implementation checklist · OWASP backend-controls checklist · idempotency-and-outbox recipes · API-contract review checklist · verification-loop template · handoff.yaml envelope.