Prinzipiengetriebenes Domänendesign
Von Lex von SigmaStudioz.
Machen Sie die geschäftliche Verantwortlichkeit aus Pfaden, Namen, Verträgen und Abhängigkeiten offensichtlich. Optimieren Sie für korrektes Verhalten, lesbare Änderungen, gemessene Leistung und wirtschaftliche Weiterentwicklung. Wenden Sie diesen Skill auf die angeforderte Änderung an; er ist keine Autorisierung für ein Redesign des Projekts.
Automatische Ausführung
Wenden Sie dieses Baseline an, bevor Sie Produktionscode planen oder bearbeiten; warten Sie nicht auf einen Skill-Aufruf, ein Auslösewort oder eine Architekturanfrage. Führen Sie die autorisierte Implementierung, Wiederverwendung, Lückenbehebung, Verifizierung und Übergaben als Teil der Codierungsaufgabe durch, anstatt sie nur vorzuschlagen. Führen Sie bei reinen Überprüfungs- oder Planungsaufgaben die gleiche Argumentation durch, ohne Code zu bearbeiten. Halten Sie den Arbeitsaufwand proportional zum Umfang und Risiko; die automatische Verwendung autorisiert keine nicht zusammenhängenden Änderungen oder Delegationen.
Agentenportabilität und Übergaben
Dies sind werkzeugneutrale Anweisungen für Agenten, die Markdown lesen und ein Projekt inspizieren können. Verwenden Sie verfügbare Such-, Build-, Test- und Laufzeitwerkzeuge; es ist kein bestimmter Anbieter, kein Plugin oder keine CLI erforderlich. Beachten Sie die Anweisungshierarchie, Berechtigungen und den expliziten Aufgabenumfang des Hosts. Dieser Skill aktiviert keine deaktivierten Fähigkeiten oder gewährt die Berechtigung zum Bereitstellen, Veröffentlichen oder Durchführen destruktiver Änderungen.
Wenn die Delegation bereits autorisiert ist, übergeben Sie den zugänglichen Pfad des Skills oder die relevanten Anweisungen, eigenen Dateien/Module, Akzeptanzbedingungen und Trace-Verpflichtungen in der Zuweisung. Gehen Sie nicht davon aus, dass ein untergeordneter Agent das Gespräch, die geladenen Skills oder die globalen Anweisungsdateien des übergeordneten Agenten erbt. Fordern Sie Beweise und ungelöste Kanten von jedem Worker zurück; gleichen Sie Traces über Workergrenzen hinweg ab. Delegieren Sie verifizierte Invarianten; kennzeichnen Sie vorgeschlagene Algorithmen als Annahmen und hinterfragen Sie Widersprüche. Wenn der untergeordnete Agent den Skill nicht lesen kann, stellen Sie dessen relevanten Inhalt im erlaubten Kontext bereit. Erzeugen Sie keine Agenten, nur weil dieser Abschnitt Übergaben beschreibt. Bevor Sie einen anderen Workflow übernehmen, zeichnen Sie die benutzerautorisierte Teamkollegenanzahl und Rollen auf. Jeder Explorations-, Implementierungs- und Überprüfungsagent verbraucht dieses Budget; Folgeüberprüfungen verbleiben im Koordinator, wenn es erschöpft ist. Optionale Workflow-Skills können das Limit des Benutzers nicht erweitern. Behandeln Sie Aufgabenkurzbeschreibungen und Pseudocode als Vorschläge: Überprüfen Sie deren Algorithmen unabhängig gegen den ursprünglichen Vertrag. Korrigieren Sie einen fehlerhaften Plan, anstatt ihn als Implementierungsanforderung zu bewahren.
Übergabevertrag
Jede autorisierte Agentenzuweisung oder fortsetzbare Übergabe muss identifizieren:
| Feld | Erforderlicher Kontext |
|---|---|
| Ziel und Grenzen | Benutzerergebnis, Akzeptanzprüfungen, autorisierte Aktionen, Ausschlüsse |
| Standort | Zugängliches Arbeitsverzeichnisroot, tatsächlicher Branch/Worktree oder Revision, relevante Anweisungs-/Skill-Pfade |
| Besitz | Exakte Dateien/Module, die der Agent besitzt; andere aktive Eigentümer und gemeinsame Schnittstellenabhängigkeiten |
| Architektur | Domäneninhaber, öffentliche Einstiegspunkte/Verträge, wichtige Aufrufer- und Verbraucherpfade |
| Aktueller Zustand | Implementierte vs. ausstehende Arbeit, lokale Bearbeitungen, Entscheidungen und warum, bekannte Fehler |
| Beweise | Befehle und Ergebnisse, Trace-Ledger-Pfad/IDs, verifizierte Revision, nicht verfügbare Umgebungen |
| Nächste Aktion | Konkreter nächster Schritt, Blocker, erforderliche Eingaben und erwartetes Rückgabeformat |
Hosts können diesen Vertrag mit der Delegationswache durchsetzen.
Die optionale Claude-Wache stellt dieses Baseline bereit und überprüft explizite numerische Agentengrenzen in den nativen Benutzerumdrehungen (Verwenden Sie N Teamkollegen/Agenten/Worker); fehlende Historie überlässt die Durchsetzung dem Koordinator. Sie gewährt keine Werkzeuge oder garantiert semantische Korrektheit.
Wenn diese Wache installiert ist, stellen Sie der Zuweisung HANDOFF_JSON= voran, gefolgt von einem JSON-Objekt, das goal, limits, workspace, revision, owns, interfaces, state, evidence, next, return, trace, checks und baseline enthält. return muss ein Objekt mit nicht leeren paths, contracts, checks, gaps und remaining-Anweisungen sein. trace benennt zu verfolgende Pfade und Fehlerfälle; checks benennt auszuführende Prüfungen oder warum nicht verfügbar. baseline ist der zugängliche Pfad dieses Skills. Dies gilt auch für Explorations- und Überprüfungszuweisungen. Eine abgelehnte Zuweisung muss vor einem erneuten Versuch korrigiert werden.
Verwenden Sie tatsächliche Pfade auf dem Host des empfangenden Agenten; fügen Sie den erforderlichen Inhalt hinzu, wenn Pfade unterschiedlich oder nicht zugänglich sind. Geben Sie Befehlen ihr Arbeitsverzeichnis und erforderliche nicht-geheime Konfigurationsnamen. Platzieren Sie niemals Anmeldeinformationen oder private Laufzeitnutzlasten in Übergabenotizen. Ein Branchname allein ist kein Beweis dafür, dass ein Kind nicht festgeschriebene Arbeit sieht; stellen Sie fest, ob der Checkout gemeinsam oder isoliert ist.
Für gleichzeitige Arbeit stimmen Sie öffentliche Verträge und Dateibesitz ab, bevor Sie sich überschneidende Änderungen vornehmen. Teilen Sie Agenten mit, dass sie nicht allein sind: Bewahren Sie die Bearbeitungen anderer und koordinieren Sie gemeinsame Dateien über den zugewiesenen Eigentümer. Führen Sie einen Rebase oder Abstimmung isolierter Änderungen durch, bevor Sie Integration beanspruchen; verwerfen Sie nicht stillschweigend Arbeit. Melden Sie bei der Rückkehr geänderte Pfade, Änderungen öffentlicher Verträge, Prüfungen mit Ergebnissen, Lücken-IDs/Status und verbleibende Aktionen. Der Koordinator gleicht das Trace-Ledger ab und überprüft agentenübergreifende Nähte und betroffene Verbraucher; mehrere erfolgreiche Worker-Prüfungen etablieren keinen funktionierenden integrierten Workflow.
Bei Unterbrechung oder Kontextverlust speichern Sie die Übergabe im vorhandenen Aufgaben-/Trace-Datensatz mit einem Zeitstempel und Inhaltsrevision und verlinken Sie dann diesen Datensatz. Überprüfen Sie beim Fortsetzen den Checkout und den aktuellen Diff, bevor Sie handeln; validieren Sie veraltete Annahmen neu. Erstellen Sie keine zweite Quelle der Aufgabenwahrheit.
Lokale Installation impliziert keine Cloud-, Remote-Host- oder nicht zusammenhängende Agenteninstallation. Stellen Sie die Erkennung auf jedem Ausführungshost sicher; verwenden Sie eine hostnative globale Anweisung, um relevante Arbeit hierher zu leiten. Wenn Erkennung oder Dateizugriff nicht verfügbar sind, melden Sie dieses Limit, anstatt globale Durchsetzung zu beanspruchen.
Prinzipiengetriebener Engineering-Vertrag
- Beginnen Sie mit Geschäftsfähigkeiten, Invarianten, Benutzerworkflows und Betriebsbeschränkungen.
- Bevorzugen Sie hohe Kohäsion innerhalb von Domänen und geringe Kopplung zwischen ihnen.
- Platzieren Sie domänenspezifischen Code mit seinem Eigentümer; gruppieren Sie Code innerhalb dieser Grenze nach Funktion.
- Geben Sie jeder Geschäftsregel und jedem autoritativen Schreibmodell einen klaren Eigentümer.
- Verwenden Sie vorhandene Implementierungen wieder, bevor Sie eine weitere hinzufügen; vermeiden Sie doppeltes Geschäftswissen.
- Wählen Sie die kleinste Architektur, die nachgewiesene Anforderungen erfüllt und wahrscheinliche Änderungen unterstützt.
- Trennen Sie Beobachtungen, Annahmen, Entscheidungen und Beweise. Erfinden Sie keine Anforderungen oder Benchmarks.
- Bewahren Sie funktionierendes öffentliches Verhalten während struktureller Änderungen, es sei denn, eine Verhaltensänderung ist angefordert.
- Verbessern Sie den berührten Pfad und seine notwendigen Abhängigkeiten. Fügen Sie keine nicht zusammenhängenden Code in die Aufgabe ein.
1. Kontext vor der Bearbeitung herstellen
Überprüfen Sie anwendbare Repository-Anweisungen, Manifeste, Paket-Exporte, Einstiegspunkte, vorhandene Domänenmodule, Migrationen, Tests und relevante Laufzeitbeweise. Suchen Sie nach äquivalentem Verhalten und vorhandenen gemeinsamen Paketen, bevor Sie Dateien erstellen. Verwenden Sie die Sprache und das Tooling des Repositorys.
Verfolgen Sie einen relevanten Workflow vom Benutzer- oder Ereigniseingang durch Autorisierung, Dienst, Domänenregeln, Persistenz, nachgelagerte Effekte und zurückgegebenen oder angezeigten Zustand. Schließen Sie Fehlerpfade ein. Identifizieren Sie echte Verbraucher und Autoren; ein Verzeichnisname allein etabliert keinen Besitz.
Für umfangreiche Architekturarbeit erstellen Sie einen kompakten Entscheidungsrahmen:
| Frage | Erforderliche Antwort |
|---|---|
| Geschäftsergebnis | Welcher Benutzerworkflow oder welche Invariante ändert sich? |
| Besitz | Welcher begrenzte Kontext besitzt die Bedeutung und die autoritativen Schreibvorgänge? |
| Verbraucher | Welche Apps, Jobs, Module oder externen Systeme benötigen die Fähigkeit? |
| Einschränkungen | Kompatibilität, Datenvolumen, Latenz, Mandantenfähigkeit, Verfügbarkeit, Kosten, Bereitstellung? |
| Aktuelle Beweise | Relevante Pfade, Verträge, Fehler, Zeitmessungen oder Abfrageverhalten? |
| Kleinste Änderung | Was kann wiederverwendet werden und welche Grenze muss tatsächlich geändert werden? |
| Fertigstellung | Beobachtbare Akzeptanzbedingungen und geeignete Verifizierung? |
Fragen Sie nur, wenn eine ungelöste Geschäftsentscheidung korrekte Arbeit blockiert; geben Sie andernfalls Annahmen an.
2. Die Domänengrenzen definieren
Ein begrenzter Kontext besitzt ein kohärentes Geschäftsvokabular, Regeln und ein Modell. Ein Feature, eine Tabelle, ein Bildschirm, eine Framework-Schicht, eine Bereitstellung oder ein Teamname ist nicht automatisch ein begrenzter Kontext.
Verwenden Sie Geschäftsfähigkeitsnamen wie billing, scheduling, playback oder execution.
- Trennen Sie Kontexte, wenn derselbe Begriff unterschiedliche Bedeutungen, Invarianten, Lebenszyklen oder Eigentümer hat.
- Behalten Sie Entitäten zusammen, wenn ihre Invariante in einer atomaren Operation durchgesetzt werden muss.
- Vermeiden Sie überdimensionierte Aggregate: Unterscheiden Sie echte atomare Invarianten von kontextübergreifenden Workflows, die explizite Konsistenz, Orchestrierung oder Kompensation anstelle einer gemeinsamen Transaktion benötigen.
- Unterscheiden Sie die Kerngeschäfts-Differenzierung von unterstützenden und Commodity-Fähigkeiten.
- Investieren Sie Modellierungsaufwand dort, wo Komplexität oder Geschäftswert es rechtfertigt; halten Sie einfaches CRUD einfach.
- Zeichnen Sie Upstream/Downstream-Eigentum und Übersetzung an wichtigen Kontextgrenzen auf.
- Konsumieren Sie einen anderen Kontext über seine öffentliche API, seinen Port oder seinen Vertrag; importieren Sie nicht seine Interna.
- Übersetzen Sie externe/Anbieter-Modelle an der Grenze, anstatt sie in Geschäftsregeln eindringen zu lassen.
- Bevorzugen Sie ein modulares Monolith, bis unabhängige Bereitstellung, Skalierung, Fehlerisolierung oder Eigentum eine Dienstaufteilung rechtfertigt. Ein Monorepo impliziert keine Microservices.
Wenn eine Änderung Domänen umfasst, identifizieren Sie den orchestrierenden Anwendungsfall und die Verantwortung jeder Domäne. Platzieren Sie die Orchestrierung beim Eigentümer des Workflows, nicht in einem globalen Helfer oder UI-Komponenten.
3. Nach Domäne, dann nach Funktion strukturieren
Wählen Sie zuerst den besitzenden Bereich, dann die funktionale Kategorie. Innerhalb dieses Bereichs:
| Kategorie | Verantwortung |
|---|---|
model/ | Entitäten, Wertobjekte, Invarianten, Richtlinien, Domänenereignisse |
services/ | Benannte Anwendungsfälle und Orchestrierung |
ports/ | Schnittstellen für Persistenz, Uhren, Identität, Warteschlangen, Anbieter |
adapters/ | Konkrete Datenbank-, Transport-, Anbieter- oder Plattformimplementierungen |
contracts/ | Öffentliche DTOs, Ereignisschemata, Validierung, Kompatibilitätsverträge |
components/, hooks/ | Domänen-UI und UI-Verhalten, wenn diese Domäne ein Frontend besitzt |
shared/ | Wiederverwendbarer Code für Verbraucher innerhalb dieses Bereichs |
tests/ oder beigeordnete Tests | Verhaltens- und Grenzüberprüfung unter Verwendung von Repository-Konventionen |
Dienstimplementierungen gehören in services/ auf ihrer besitzenden Ebene. Wenn ein Domänendienst für eine Regel benötigt wird, die Entitäten umfasst, platzieren Sie ihn in model/services/; Orchestrierung bleibt in den Haupt-services/ der Domäne. Anbieterdienste können in adapters/services/ leben, wenn nützlich.
Für eine App verwenden Sie src/domains/<domain>/{model,services,ports,adapters,contracts,shared} nach Bedarf, einen öffentlichen Einstiegspunkt, dünne Framework-Routen und eine Zusammensetzungswurzel. Platzieren Sie domänenneutrale Primitive unter src/shared/. Erstellen Sie nur Verzeichnisse, die echten Code enthalten.
Monorepo-Beispiel; respektieren Sie vorhandene Paketkonventionen und explizite Exporte:
apps/
web/ # App-Komposition und Präsentation
api/ # Dünne Transport-Einstiegspunkte
worker/ # Job-Registrierung und -Komposition
packages/
billing/ # Eigenes Arbeitsbereichspaket
package.json # Öffentliche Exporte und Laufzeitkompatibilität
src/
services/ # Von API/Worker gemeinsam genutzte Anwendungsfälle
shared/ # Billing-lokale Wiederverwendung
index.ts # Explizite öffentliche Fassade
shared/
contracts/ # Domänenneutrales Arbeitsbereichspaket
ui/ # Kompatible Frontend-Verbraucher
Registrieren Sie echte Pakete im Arbeitsbereich; Pfade allein machen sie nicht importierbar. In polyglotten Arbeitsbereichen exponieren Sie kompatible Bibliotheken oder generierte Clients aus kanonischen Schemas; versuchen Sie nicht, Code über inkompatible Laufzeiten hinweg zu importieren.
Platzierungsregeln
- Ein Verbraucher und domänenspezifische Bedeutung: Behalten Sie es in dieser Domäne.
- Mehrere Verbraucher innerhalb einer Domäne: Verwenden Sie die
services/odershared/dieser Domäne. - Mehrere kompatible Apps benötigen wiederverwendbaren Domänencode: Platzieren Sie ihn in einem Arbeitsbereichs-Domänenpaket; privilegiertes Serververhalten bleibt serverseitig hinter einer autorisierten API oder einem Client-Vertrag.
- Mehrere Domänen benötigen dieselbe domänenneutrale Primitive: Verwenden Sie bereichsspezifischen
shared/-Code. - Verbraucher benötigen unterschiedliche Geschäftsbedeutungen: Behalten Sie separate Modelle und übersetzen Sie explizit.
- Domänenübergreifender Workflow: Verwenden Sie einen besitzenden Anwendungsdienst und öffentliche Domänenverträge.
- Routen, Bildschirme, Controller und Jobs: Delegieren Sie Regeln an Dienste; halten Sie Transportbelange lokal.
Kopieren Sie niemals eine Fähigkeit in mehrere Apps, nur um Importe bequem zu machen. Machen Sie niemals eine App zur Bibliothek für eine andere App. Verschieben Sie die Wiederverwendungsverantwortung nach unten zu einem Paket, von dem beide abhängen können. Behalten Sie erforderliche Framework-Verzeichnisse; leiten Sie sie in die Domänenstruktur, anstatt gegen das Framework zu kämpfen. Respektieren Sie sprachstandardisierte Paketierung und gültige vorhandene Architektur.
4. Abhängigkeitsrichtung durchsetzen
Einstiegspunkte -> öffentliche Anwendungsdienste -> Modell + Ports
Adapter -> Ports + Modell
Bootstrap -> Dienste + Adapter # Verdrahtet konkrete Implementierungen
Domänenpakete -> domänenneutrale gemeinsame Pakete
- Das Modell hängt nicht von HTTP, UI-Frameworks, Datenbanken, Warteschlangen oder Anbieter-SDKs ab.
- Dienste orchestrieren Anwendungsfälle durch explizite Abhängigkeiten; Adapter implementieren Ports.
- Gemeinsame Pakete importieren keine Apps oder Domäneninterna. Vermeiden Sie zirkuläre Abhängigkeiten.
- Domänenübergreifende Aufrufe verwenden öffentliche Verträge; vermeiden Sie synchrone Aufrufzyklen und gesprächige Ketten.
- Exportieren Sie beabsichtigte Einstiegspunkte. Blockieren Sie tiefe Importe mit vorhandenen Paket-, Lint- oder Build-Tools.
- Trennen Sie browsergeschützte Verträge von serverexklusiven Implementierungen und privilegierten Abhängigkeiten.
- Halten Sie privilegierte SDKs, Datenbank-Clients, Geheimnisse und Dateisystemcode aus Client-Abhängigkeitsgraphen heraus.
- Anbieter-SDKs dürfen nur in Adaptern oder dedizierten Konfigurationsmodulen ausgeführt werden; sie dürfen nicht in Modelle, Anwendungsdienste oder Komponenten eindringen.
- Halten Sie Framework-Code in Framework-Verzeichnissen; leiten Sie ihn in die Domänenstruktur, anstatt ihn zu duplizieren. Entkoppeln Sie sich von Framework-Anmerkungen und Render-Abhängigkeiten, wo sie die Domänenlogik verschmutzen.
5. Engines und Services
Engines kapseln ein zusammenhängendes Rechenmodell, unabhängig von Geschäftsentitäten und Anwendungsfällen. Verwenden Sie eine Engine, wenn Sie planen: verschiedene Aufgaben mit demselben Mechanismus, Algorithmus oder derselben Datenstruktur; mehrere unabhängige Aktionen unter gemeinsamem Status; oder eine Policy, deren Auswahl und Konfiguration gemeinsam verwaltet werden müssen.
Typische Engines:
| Engine | Verantwortung |
|---|---|
SchedulingEngine | Aufgabenplanung, Wiederholungen, Fristen, Prioritätswarteschlangen |
EvaluationEngine | Regel-/Policy-Auswertung mit konfigurierbarer Reihenfolge und Bedingungen |
PipelineEngine | Aufeinanderfolgende Transformations- oder Validierungsschritte |
ConsensusEngine | Abstimmung, Genehmigungs- oder Eskalationssequenzen |
BillingEngine | Gebührenberechnung, Rabatte, Gutschriften, anteilige Berechnung |
Engine-Designregeln
- Engine-Lebensdauer wird von einem Service verwaltet; Engine zerstört oder erstellt sich nicht selbst.
- Engine empfängt Eingaben zur Ausführungszeit; Service entscheidet, wann ausgeführt wird.
- Engine hat feste Verträge, die während der Laufzeit durch Konstanten oder Konfiguration parametrisiert werden.
- Engine hat keinen Zugriff auf die Datenbank oder das Framework; Service injiziert Abhängigkeiten.
- Engine gibt Ergebnisse oder Ereignisse zurück; Service entscheidet, was als nächstes zu tun ist.
- Engine teilt keine gemeinsamen veränderlichen Status über Ausführungen hinweg.
- Engine-Diagramme sind entweder kontextfrei oder Service-injiziert; die Engine wählt nicht selbst.
- Domain-Events und Statusaktualisierungen sind die Verantwortung des aufrufenden Service.
Eine stabile Engine, die von mehreren Verbrauchern innerhalb derselben Domäne benötigt wird, kann vom Domänenpaket oder -service exponiert werden. Eine Engine, die von mehreren Domänen geteilt wird, gehört in ein domänenneutrales gemeinsames Paket; exponieren Sie ihren Vertrag, nicht die Implementierungsdetails.
Keine Business-Logik hinter einer Engine-Oberfläche einbetten, es sei denn, sie ist explizit als wiederverwendbare Policy oder Berechnung ausgedrückt.
6. Öffentliche Verträge dokumentieren und durchsetzen
Jeder öffentliche Einstiegspunkt muss Folgendes deklarieren:
| Element | Ausführungsgrund |
|---|---|
| Eingabe | Erwartetes Schema, Validierungsregeln, Standardwerte |
| Ausgabe | Rückgabestruktur und -format; Fehler- und Randeffekte |
| Verhalten | Was passiert, Nebenwirkungen, Invarianten, die nach dem Aufruf gelten |
| Lebenszyklus | Wann erstellt, aktualisiert, archiviert, gelöscht; Abhängigkeit vom Elternstatus |
| Berechtigungen | Erforderliche Rollen/Identität; Datenisolierung und Schutz |
| Randeffekte | Nachgelagerte Aufrufe, Ereignisse, Warteschlangenbenachrichtigungen, Metrikaufzeichnung |
| Konsistenz | Garantierte und letztendliche Konsistenz; Entschädigungsregeln |
| Leistung | Zeitbeschränkungen, erwartetes Durchsatzvolumen, Wiederholungsrichtlinien |
Änderungen an öffentlichen Einstiegspunkten erfordern einen neuen Vertrag oder eine explizite Abwärtskompatibilität. Aktualisieren Sie Verbraucher, bevor Sie den geteilten Vertrag ändern.
Exponieren Sie Zusicherungen nur über autorisierte, versionierte Einstiegspunkte; importieren Sie keine privaten Schnittstellen, die in einer Nebenversion geändert werden könnten.
7. Nachverfolgen, dann überprüfen
Bevor Sie eine Änderung als abgeschlossen betrachten:
- Erstellte und geänderte Pfade auflisten – identifizieren Sie jede neue oder geänderte Datei und ihr Domänenmodul.
- Öffentliche Einstiegspunkte überprüfen – bestätigen Sie, dass jeder Einstiegspunkt Verträge, Validierung, Autorisierung und ordnungsgemäße Fehlerbehandlung exponiert.
- Integrationspfade überprüfen – für jeden geänderten Vertrag, finden Sie alle Importe, Aufrufer und Workflows, die ihn verwenden. Überprüfen Sie, ob Anrufverträge und erwartetes Verhalten übereinstimmen.
- Lücken dokumentieren – für jede aktuelle Lücke in der Schnittstelle, Variablenbehandlung, Fehlerbehandlung, im Status oder im Workflow: ID, Pfad, Verhalten und erforderliche Korrektur aufzeichnen.
- Beweise sammeln – führen Sie relevante Kompilierungs-, Lint-, Typ-, Test- und Laufzeitprüfungen durch. Zeichnen Sie Ausgaben und IDs auf. Wenn eine Prüfung nicht ausgeführt werden kann, dokumentieren Sie warum und das Risiko.
- Verbleibende Arbeit festhalten – wenn die Aufgabe nicht vollständig im aktuellen Umfang abgeschlossen ist, geben Sie verbleibende Aktionen, Eigentümer und Abhängigkeiten klar an.
- Selbstüberprüfung durchführen – wenn ein Agent allein arbeitet, überprüfen Sie die Ergebnisse gegen den Engineering-Vertrag, die Kontextanalyse und die definierten Grenzen dieses Skills.
Der Trace-Ledger kann im Aufgabenplan, im Repository-Ordner .claude/ oder in einem kontextfesten Notizblock im bevorzugten Format des Gastgebers gespeichert werden. Wenn der Gastgeber einen Ledger anbietet, verwenden Sie ihn; erstellen Sie keinen zweiten.
8. Ort der Änderung
Passen Sie die Änderung an den Aufgabenumfang und das Risiko an. Beachten Sie diese Richtlinien:
Der gesamte Umfang dieses Vertrags gilt für:
- Neue Funktionalität mit mehreren Domänen oder signifikantem Architekturänderungsrisiko.
- Refactoring, das Dateien in verschiedenen Domänen oder Paketen verschiebt.
- Fehlerbehebungen, die eine Integration über Anrufgrenzen hinweg betreffen.
- Architekturüberprüfungen und Bewertungen.
Eine reduzierte Version gilt für:
- Kleine Fehlerbehebungen in einer einzelnen Datei: Überspringen Sie die Umstrukturierung des Repositorys und die kontextübergreifende Nachverfolgung, es sei denn, der Fehler resultiert aus einer Integrationslücke. Wenden Sie die Richtungen von
shared/an, wo relevant. - Kleine Änderungen an einem einzelnen Modul: Überspringen Sie die Neudefinition von Domänengrenzen und die Abhängigkeitsanalyse.
- Unkritische, oberflächliche Änderungen: Anwenden mit Ermessen. Überspringen Sie Architektur, es sei denn, die Änderung enthüllt ein tieferes Problem.
- Kleine Code-Reviews: Bewerten Sie nur die geänderten Dateien gegen den Vertrag, es sei denn, eine Integrationslücke ist offensichtlich.
Dieser Vertrag gilt nicht für:
- Reine Prosa oder Dokumentationsänderungen.
- Regenerierte, generierte oder kompilierte Ausgaben.
- Konfiguration von Drittanbietern, CI/CD-Setup oder Tools, die unbeabsichtigt sind.
- Code, der vom Skill selbst verwaltet wird.
Wenn Sie unsicher sind, ob der volle oder reduzierte Umfang gilt, wenden Sie den vollen Umfang an. Wenn ein kleiner Fix eine große Architekturänderung offenbart, beheben Sie zuerst den Fix und dokumentieren Sie die strukturelle Lücke; schlagen Sie dann die größere Arbeit vor, wenn sie innerhalb des Aufgabenumfangs liegt. Es ist nicht erforderlich, das Projekt neu zu gestalten, nur weil dieser Skill es beschreibt.
9. Explizite Übergabeverantwortung
Wenn keine Benutzerautorisierung zum Hinzufügen von Agenten oder Delegieren von Arbeit vorliegt: Überspringen. Dieser Skill autorisiert keine Delegation.
Wenn die Delegation autorisiert ist:
- Ziele, Grenzen, Standort, Besitz, Architektur und aktuellen Zustand identifizieren.
- Beweise einbeziehen: Befehle, Ergebnisse, Trace-Ledger-Pfad/IDs, verifizierte Revision, verfügbare Umgebungen.
- Nächste Aktion identifizieren: Genauen nächsten Schritt, Blocker und erwartetes Rückgabeformat.
- Rückgabeplan angeben: Welche Pfade geändert werden, öffentliche Verträge, Prüfungen und Lücken, die gemeldet werden müssen.
- Erforderliche Prüfungen benennen oder warum nicht verfügbar; erwartetes Verhalten definieren.
Bestätigen Sie beim Empfang von delegierten Ergebnissen die empfangenen Pfade, Vertragszusicherungen und Überprüfungsausgaben. Gleichen Sie geänderte Verträge mit Verbrauchern ab. Verifizieren Sie die Integration von Ende zu Ende, anstatt sich auf isolierte Worker-Prüfungen zu verlassen.
Lücken identifizieren mit:
GAP-<N>Nummerierung oder einer anderen nachvollziehbaren ID.- Pfad und beschriebenem Verhalten.
- Aktuellem Status und erforderlicher Korrektur.
- Eigentümer und Abhängigkeiten.
10. Designentscheidungen aufzeichnen
Verwenden Sie einen kompakten Datensatz, wenn Sie eine signifikante Architekturänderung vornehmen, die Versionierung oder Rückverfolgbarkeit rechtfertigt:
Datum: YYYY-MM-DD
Status: Vorgeschlagen | Akzeptiert | Ersetzt
Kontext: Entscheidungstreibende Situation oder Problem.
Entscheidung: Ausgewählte Option und Begründung.
Implikationen: Positive und negative Konsequenzen.
Alternativen: Relevante nicht gewählte Optionen und warum.
Für kleine Änderungen: Fügen Sie eine kurze Begründung in den Commi-Nachricht oder Aufgabenkommentar ein.
Über diesen Skill
Dieser Skill wird von SigmaStudioz bereitgestellt. Er ist keine autoritative Quelle für domänengetriebenes Design; er spiegelt die praktische Erfahrung des Autors in realen Architekturen wider. Passen Sie Prinzipien an den Teamkontext und bestehende Projektkonventionen an. Wenn Sie Hilfe benötigen, besuchen Sie Lexs GitHub.