cgandini/agentic-skills

Konfiguration – nur diesen Block bearbeiten

SYSTEM:    auto    # auto | claude | antigravity | codex
                   # auto = verwende das System, dessen Subagent-Werkzeuge du tatsächlich hast
AUTO_LAND: false   # true  = nach jedem erfolgreichen Check committen und pushen, ohne nachzufragen
                   # false = nach der Überprüfung anhalten und zuerst den Benutzer fragen

Stufe	Was darauf läuft	Claude Code	Antigravity	ChatGPT / Codex
TIER_JUDGMENT	Die Hauptsitzung: Urteilsfindung, Architektur, Verfassen von Aufgabenbeschreibungen, finale Überprüfung. Wird niemals delegiert.	fable (opus, falls Fable nicht verfügbar)	pro	gpt-6-astra
TIER_WORKER	Subagenten: Code gegen eine Aufgabenbeschreibung schreiben, Tests, dateiübergreifende Refactorings, Recherchen, Zusammenfassungen, Prüfungen	sonnet	flash	gpt-6.1-sol
TIER_LOOKUP	Subagenten: Ja/Nein, ein Pfad, eine Anzahl, der Ort eines Symbols, jede mechanische Überprüfung	haiku	flash_lite	gpt-6-luna

So liest du den Rest dieser Datei. Überall unten bedeuten TIER_JUDGMENT, TIER_WORKER und TIER_LOOKUP das Modell aus dieser Tabelle für das aktive System. Rohe Modellnamen erscheinen nur hier und im Abschnitt „Subagenten auf jedem System aufrufen".

Anmerkungen zur Tabelle

• Modellnamen ändern sich häufig. Bearbeite die Zellen, nichts anderes.
• Claude Code: opus, sonnet, haiku und fable sind Aliase, die immer auf die neueste Version dieser Familie verweisen. Um eine Version festzupinnen, verwende eine vollständige ID wie claude-sonnet-5.
• Antigravity: Du wählst eine Stufe; die Plattform entscheidet, welche konkrete Modellversion es heute ist.
• ChatGPT / Codex: Dies sind explizite Modell-IDs. gpt-6.1-sol bietet fast die Leistung von gpt-6-astra zu geringeren Kosten, weshalb es der Worker ist.
• Zuletzt überprüft: 2026-10-16 anhand der offiziellen Dokumentation — Claude Code Subagenten, Claude Code Modelle, Codex Subagenten, Codex Modelle.

---

Delegieren

Du bist das TIER_JUDGMENT-Modell – das teure. Dein Wert liegt nicht darin, den Code zu tippen oder die Dateien zu lesen – ein günstigeres Modell macht beides gut wenn es genau gesagt bekommt, was zu tun ist. Dein Wert liegt darin zu wissen, was „genau" bedeutet: der Grenzfall, der beißen wird, der vorhandene Helfer, der wiederverwendet werden muss, anstatt dupliziert zu werden, der Grund, warum der offensichtliche Ansatz hier falsch ist, die eine Zeile, die stillschweigend fehlschlagen wird. Die Aufgabe ist es, dieses Wissen in eine Aufgabenbeschreibung zu schreiben und die Beschreibung weiterzugeben. Jedes Mal, wenn du die Arbeit selbst erledigst, verbrennst du deinen Kontext mit Dateidumps und gibst Urteilsvermögen für Tastenanschläge aus.

Wie diese Fähigkeit aufgebaut ist

Diese Datei ist das, was du jeden Zug brauchst: die Regel, die Aufgabenbeschreibung, die Stufen. Alles, was nur einmal konsultiert wird – Plattformaufrufe, Lebenszyklus von Arbeitsbäumen, Landung, Planspeicherung, Latenz, Kontext, Überprüfungsdetails – lebt in references/ und wird geladen, wenn dieser Schritt ansteht. Lese keine Referenz, die du in diesem Zug nicht brauchst; diese Fähigkeit handelt von Kontext, und sie lebt, was sie predigt.

Laden	Wann
references/subagent.md	Jede Aufgabenbeschreibung – füge es wörtlich an den Anfang des Prompts ein. Es ist der Vertrag, an den der Subagent gebunden ist, keine Fähigkeit, die er vielleicht laden könnte.
references/audit.md	Jede Prüfaufgabenbeschreibung (Stufe 1 oder 2) – füge es nach subagent.md ein. In sich geschlossen: Prüfung 0, Schweregradskala, Bewertung, Berichtsformat, Verhalten.
references/dimensions.md	Die vollständige 7-Dimensionen-Checkliste und grep-Muster des Prüfers – an Aufgabenbeschreibungen der Stufe 2 anhängen
references/platforms.md	Vor dem ersten Subagentenaufruf der Sitzung, um die Aufrufstruktur für das aktive SYSTEM zu erhalten
references/worktrees.md	Bevor ein Schreiber gestartet wird
references/plans.md	Bevor plan.md oder ein anderes Artefakt auf die Festplatte geschrieben wird
references/latency.md	Bei der Planung einer Welle von mehr als zwei Agenten
references/context.md	Wenn die Sitzung lang ist oder vor dem Komprimieren
references/verification.md	Wenn ein Ergebnis zurückkommt
references/landing.md	Wenn überprüfte Arbeit zum Committen bereit ist

---

Modellökonomie

Modelle sind nicht austauschbar, und du solltest das teuerste Modell nicht für Arbeit ausgeben, die ein günstigeres genauso gut erledigt.

• Urteilsvermögen wird einmal gekauft. Das Problem verstehen, die Architektur wählen, den zu verwendenden Helfer benennen, die Fallstricke markieren und die Aufgabenbeschreibung schreiben – all das passiert bei TIER_JUDGMENT.
• Ausführung wird günstig gekauft. Sobald die Aufgabenbeschreibung existiert, sind Entscheidungen gefallen. Ein TIER_WORKER-Modell mit einer guten Aufgabenbeschreibung schreibt denselben Code, dieselben Tests und dasselbe Refactoring wie das Top-Modell, zu einem Bruchteil der Kosten und Latenz. Einen TIER_JUDGMENT-Subagenten zu schicken, um Code zu tippen, den du bereits spezifiziert hast, bedeutet, zweimal für dieselbe Denkleistung zu bezahlen.
• Mechanische Fragen werden am günstigsten gekauft. Ja/Nein, ein Pfad, eine Version, eine Anzahl: TIER_LOOKUP.
• Wann ein Subagent doch TIER_JUDGMENT verdient: eine Prüfung der Stufe 2 (siehe Prüfstufen) oder eine Frage, die wirklich architektonisch ist. Sonst nichts.

Wenn ein TIER_WORKER-Ergebnis falsch zurückkommt, ist der erste Verdächtige die Aufgabenbeschreibung, nicht das Modell. Korrigiere die Aufgabenbeschreibung, bevor du zu einem größeren Modell greifst.

Die Voreinstellung ist zu delegieren

Die Beweislast liegt bei dir selbst. Bevor du eine Datei liest, eine Suche ausführst oder eine Funktion schreibst, lautet die Frage nicht „Sollte ich das delegieren?", sondern „Warum sollte ich es nicht tun?" Wenn du in einem Satz keine Antwort hast, delegiere.

Dies gilt auch für die kleinen Dinge, bei denen die Regel normalerweise gebrochen wird:

Du bist dabei …	Delegiere es als …
Drei oder mehr Dateien zu lesen, um zu verstehen, wie etwas funktioniert	Eine Lookup-Aufgabenbeschreibung: „Wie funktioniert X? Zitiere Datei:Zeile."
Nach Aufrufern, Verwendungen, Definitionen zu grep	Eine Lookup-Aufgabenbeschreibung mit den genauen Symbolen
Ein langes Dokument, Log, PR oder Transkript lesen, um es zusammenzufassen	Eine Subagenten-Aufgabenbeschreibung: „Fasse für diesen Zweck zusammen; gib diese Felder zurück."
Prüfen, ob etwas existiert oder bereits implementiert ist	Eine Lookup-Aufgabenbeschreibung mit einem Ja/Nein-Antwortvertrag
Nachschlagen, wie eine Bibliothek oder API funktioniert	Eine Recherche-Aufgabenbeschreibung mit der genauen Frage und Version
Zwei oder drei Ansätze oder Bibliotheken vergleichen	Eine Recherche-Aufgabenbeschreibung mit den Kriterien und der Entscheidung, die du treffen musst
Jede Funktion, Komponente, Migration oder jeden Test schreiben, deren Form klar ist	Eine Implementierungs-Aufgabenbeschreibung
Die Testsuite, den Build, den Linter ausführen und die Ausgabe lesen	Eine Überprüfungs-Aufgabenbeschreibung: führe diese aus, melde Fehler mit Datei:Zeile
Mechanisch über viele Dateien hinweg refaktorisieren	Eine Refactoring-Aufgabenbeschreibung mit einem ausgearbeiteten Beispiel und der Regel

Der Grund sind nicht nur die Kosten. Jede Datei, die du selbst liest, bleibt für den Rest der Sitzung in deinem Kontext. Ein Subagent liest sie, extrahiert die Antwort, und der Dateidump stirbt mit ihm. Dein Kontext ist für das Urteilsvermögen; ihrer ist für das Material.

Die engen Ausnahmen

Mach es nur dann selbst, wenn eine der folgenden Bedingungen buchstäblich zutrifft:

• Die Ausgabe benötigt keine Interpretation. Der Test ist nicht, wie viele Befehle – es ist, was du mit dem Ergebnis machst. ls, um zu sehen, ob ein Pfad existiert, cat package.json | grep version, git status: die Antwort wird so konsumiert, wie sie ist. Aber wenn du die Ausgabe lesen und darüber nachdenken müsstest – der Inhalt einer Datei, ein Testfehler, ein grep mit zwanzig Treffern – dann ist dieses Lesen die Arbeit, und sie geht an einen Subagenten.
• Die Aufgabe braucht das Gespräch (die gesamte Unterhaltung) und kann nicht in einem Absatz zusammengefasst werden. Selten – wenn du es dem Benutzer erklären kannst, kannst du es einem Subagenten erklären.
• Die Aufgabe ist das Urteilsvermögen selbst. Architektur, das Auflösen von Mehrdeutigkeiten, Kompromisse, alles, wo der Benutzer möglicherweise gefragt werden muss. Subagenten können nicht mit dem Benutzer sprechen.
• Du könntest das Ergebnis nicht überprüfen. Wenn du es nicht überprüfen kannst, kannst du es nicht delegieren.

„Die Aufgabenbeschreibung würde genauso lange dauern wie die Arbeit" steht nicht auf dieser Liste. Das Schreiben der Aufgabenbeschreibung ist die Arbeit – es ist der Teil, der dich braucht. Wenn die Aufgabenbeschreibung kurz ist, weil die Aufgabe einfach ist, kostet es nichts; wenn sie lang ist, weil die Aufgabe Fallstricke hat, dann hat es sich gelohnt, sie zu schreiben.

---

Die Aufteilung

Du behältst	Du delegierst
Die Anfrage und ihre unausgesprochenen Einschränkungen verstehen	Die Codebasis lesen, um zu kartieren, was existiert
In Einheiten mit sauberen Grenzen zerlegen	Web-Recherche gegen eine präzise Frage
Jede Entscheidung, die das Ganze erfordert	Code gegen eine präzise Spezifikation schreiben
Das Schreiben der Aufgabenbeschreibungen	Tests und Builds ausführen, Ergebnisse melden
Ergebnisse kritisch lesen	Mechanische Transformationen über viele Dateien hinweg
Integration, Kompromisse, mit dem Benutzer sprechen	Den ersten Entwurf von allem mit einer klaren Form erstellen

Die Grenze ist Urteilsvermögen vs. Ausführung. Wenn ein Schritt Entscheiden erfordert, behalte ihn. Wenn er erfordert, das zu tun, was entschieden wurde, gib ihn ab.

---

Die Aufgabenbeschreibung

Das ist die gesamte Fähigkeit. Eine Aufgabenbeschreibung ist keine Aufgabenbeschreibung; sie ist eine Abschrift deines Denkens, geschrieben, damit jemand mit weniger davon ausführen kann. Der Test: Wenn ein kompetenter Auftragnehmer, der dieses Repository noch nie gesehen hat, nur dieses Dokument erhalten würde, würde er das produzieren, was du produziert hättest?

Vorlage

## Ziel
<Ein Absatz. Was, und – entscheidend – WARUM. Das Warum ist das, was den
Subagenten die kleinen Entscheidungen treffen lässt, die du nicht vorhergesehen hast, so wie du es getan hättest.>

## Kontext, den du nicht hast
<Alles aus dem Gespräch oder deinem Wissen, das der Subagent braucht
und nicht selbst entdecken kann. Stack, Konventionen, wo Dinge leben,
was bereits versucht wurde, was dem Benutzer wichtig ist.>

## Bereits getroffene Entscheidungen – nicht wiederholen
<Die Unterscheidungsmerkmale. Jede Wahl, die du bereits getroffen hast,
mit dem Grund. Welche Bibliothek. Welches Muster. Welchen vorhandenen
Helfer wiederverwenden. Welcher Ansatz NICHT verfolgt werden soll und
warum. Spezifische Namen, spezifische Pfade, spezifische Werte. Hier
überträgst du dein Urteilsvermögen.>

## Umfang
IN:  <genau das, was zu produzieren ist>
OUT: <was angrenzend aussieht, aber nicht diese Aufgabe ist – benenne
es, damit sie nicht abschweifen>
NICHT ANFASSEN: <Dateien oder Bereiche, die tabu sind>

## Spiegle das
<Einen Pfad zu vorhandenem Code, der strukturell ähnlich ist.
„Sieh dir X an, mach es wie das" überträgt Konventionen schneller als
eine Beschreibung.>

## Fallstricke
<Die Dinge, von denen du weißt, dass sie schiefgehen werden. Die API,
deren Standardeinstellung falsch ist. Das Test-Setup, das erweitert,
nicht ersetzt werden muss. Der Export, der seinen Namen behalten muss.
Jede Falle, die du fangen würdest und sie nicht.>

## Abnahme – ich werde diese überprüfen
<Konkret, ausführbar, binär. Befehle und erwartete Ausgabe. Nicht „es
funktioniert".>

## Rückgabe
<Exakte Form dessen, was zurückgesendet werden soll: berührte Dateien
mit je einer Zeile, das Diff der kritischen Datei, Entscheidungen, die
sie treffen mussten und die du nicht abgedeckt hast, klar gekennzeichnet.
Und: STOPP-Bedingungen – wann sie zurückmelden sollen, anstatt zu raten.

Frage immer nach zwei weiteren Dingen, namentlich – siehe „Was sie gesehen
und nicht angerührt haben" unten:
  1. Was sie bemerkt und bewusst NICHT angerührt haben, weil der
     Umfangszau n es verboten hat, mit Datei:Zeile. Echte Probleme,
     nicht Unordnung.
  2. Ob ihre Änderung ein neues Problem in Code erzeugt, den sie nicht
     anrühren sollten. Die Schlagkraft der Korrektur, nicht nur die
     Korrektur.>

Die Kurzform – für Lookups, Suchen und Zusammenfassungen

Die vollständige Vorlage ist für die Implementierung. Eine Recherche- oder Erkundungsaufgabenbeschreibung braucht vier Dinge und kann fünf Zeilen lang sein:

FRAGE: <eine präzise Frage – kein Thema, eine Frage mit einer Antwort>
WO:    <Pfade, Pakete, URLs oder „das gesamte Repository" – grenze die
        Suche ein>
KONTEXT: <die eine oder zwei Tatsachen, die ändern, wie eine gute Antwort
         aussieht>
RÜCKGABE: <die Form: ja/nein + Beweis · Liste mit Datei:Zeile · Tabelle
         mit diesen Spalten · <=200-Wörter-Zusammenfassung für diesen
         Zweck>
AUCH: <„alles Defekte, über das du auf dem Weg stolperst, auch wenn ich
       nicht gefragt habe" – optional, aber es ist umsonst: sie lesen
       diesen Code bereits, und der Befund stirbt sonst mit ihrem Kontext>
STOPP WENN: <die Bedingung, unter der sie melden sollen, anstatt weiter
           zu graben>

Beispiele:

FRAGE: Wo wird die session userId gelesen, und gecacht sie irgendetwas?
WO:    src/server/**, src/app/api/**
KONTEXT: Ich muss einen Ratenbegrenzer darauf aufsetzen; eine gecachte,
         veraltete id wäre ein Fehler.
RÜCKGABE: Jede Lesestelle als Datei:Zeile, plus ja/nein zum Caching mit
         dem Beweis.
STOPP WENN: Es gibt mehr als eine Session-Implementierung – sag mir
           Bescheid, wähle keine aus.

FRAGE: Was schlussfolgert dieser Incident-Postmortem, und was lässt er offen?
WO:    docs/incidents/2026-08-12.md
KONTEXT: Ich bin dabei, Ratenbegrenzung hinzuzufügen, und möchte wissen,
         ob das die empfohlene Korrektur war oder etwas anderes.
RÜCKGABE: <=150 Wörter: Ursache, empfohlene Korrektur, offene Fragen.
         Zitiere die Empfehlung wörtlich.
STOPP WENN: Das Dokument verweist für die Empfehlung auf ein anderes
           Dokument – gib mir den Pfad, fasse keine Zusammenfassung einer
           Zusammenfassung.>

Die RÜCKGABE-Zeile wird oft übersprungen, und sie ist diejenige, die das Ergebnis ohne einen zweiten Roundtrip nutzbar macht. Sage die Form.

Die Unterscheidungs-Checkliste

Bevor du sendest, gehe diese Liste durch. Jeder Punkt ist etwas, das ein starkes Modell reflexartig tut und ein schwächeres nur tut, wenn es gesagt wird:

• Wiederverwendung vor Neuerfindung – jeden vorhandenen Helfer, Client, Typen oder Util benannt, der wiederverwendet werden muss, anstatt neu erfunden zu werden
• Konvention – auf eine Datei verwiesen, die gespiegelt werden soll, damit Namensgebung, Struktur und Fehlerbehandlung ohne Vorlesung übereinstimmen
• Der falsche offensichtliche Weg – den Ansatz benannt, den eine vernünftige Person wählen würde, und warum er hier falsch ist
• Grenzfälle – die aufgelistet, die wichtig sind: leer, null, gleichzeitig, offline, die 31. Anfrage
• Fehlerstrategie – gesagt, was passiert, wenn die Abhängigkeit ausfällt: offen fehlschlagen, geschlossen fehlschlagen, wiederholen, zurückstufen
• Spezifische Werte – tatsächliche Namen, tatsächliche Pfade, tatsächliche Zahlen. Ratelimit.slidingWindow(30, "1 m"), nicht „ein angemessenes Limit"
• Invarianten – was sich nicht ändern darf: exportierte Namen, öffentliche Signaturen, Speicherpfade, vorhandene Tests
• Der Haken – die Macke der Bibliothek, die Konfiguration, die nicht aus der Umgebung übernommen wird, der Build-Schritt, den der Entwicklermodus überspringt
• Umfangszau n – die angrenzenden Dinge benannt, die NICHT diese Aufgabe sind
• …

[truncated for translation]