eai-org/agent-toolkit

Übergabe

Verpacken Sie eine abgeschlossene Änderung so, dass ihre Prüfer niemals die Absicht aus dem Diff rekonstruieren müssen. Schreiben Sie für einen Prüfer, der nur den Diff und nichts anderes in Händen hält – keine Planungsdokumente, keine Sitzung, kein Wissen, dass beides existiert.

Aufgabe lösen

Die Eingabe ist eine beliebige partielle Referenz – Ticket-ID, Slug, Pfad eines Planungsartefakts – oder nichts, was die Sitzungsaufgabe bedeutet; bei einer neuen Sitzung wird sie aus Branchnamen und letzten Commits abgeleitet. Lösen Sie sie in die Planungsheimat der Aufgabe auf: ihr <id>-<slug>/-Verzeichnis im Planungsverzeichnis des Projekts oder ihre flachen <id>-<slug>.*-Dateien in einem gemeinsamen Familienverzeichnis. Ein eindeutiger Treffer → fortfahren, mit Angabe der Heimat und der gefundenen Artefakte. Abgeleitet oder mehrere Kandidaten (-vN, …) → zuerst bestätigen. Eine explizite Referenz, die lokal nichts findet → anhalten und fragen; niemals raten.

Sammeln

Lesen Sie dies, überspringen Sie, was nicht existiert:

1. Aufgabenartefakte – jede <id>-<slug>*.md in der Planungsheimat: Ticket, Anforderungen, Plan, Entscheidungsprotokoll, vorherige Review- und Übergaberunden, alles Weitere, das passt.
2. Verknüpfte Tickets – nur einen Hop: Eltern (höher nur über dünne Container), direkte Vorgänger/Nachfolger, explizite Beziehungen, Familienverzeichnis-Geschwister; niemals deren eigene Beziehungen erweitern. Lokale .TICKET.mds zuerst; vom Tracker nur abrufen, wenn eine Beziehung keine lokale Datei hat und für ein "Warum" wichtig erscheint – bei Zweifel, ob abgerufen werden soll, fragen.
3. Die Sitzung, wenn sie die Änderung hervorgebracht hat: Entscheidungen, Wendepunkte, Einschränkungen.
4. Der Diff gegen das Ziel, plus Commit-Betreffs.

Jede Quelle einmal, nicht tiefer als das Artefakt benötigt: Überfliegen Sie den Diff als Ganzes, tief lesen Sie nur die Dateien, die Sie im Review-Leitfaden nennen werden, und bauen Sie niemals die Historie Commit für Commit wieder auf – welcher Commit was geändert hat, ist die Aufgabe des Diffs, nicht Ihre.

Dann gleichen Sie die Schritte und Akzeptanzkriterien des Plans auf beide Arten gegen den Diff ab – geplant, aber nicht vorhanden, sowie vorhanden, aber nicht geplant. Erledigt, wenn jede Quelle gelesen oder als nicht vorhanden bestätigt wurde und jedes geplante Element abgeglichen ist.

Niemals Begründung erfinden

Geben Sie ein "Warum" nur an, wenn eine Quelle es liefert. Eine Abweichung, die nichts erklärt, wird dem Autor einmal vorgelegt; unbeantwortet oder nicht erfragbar, wird sie in klaren Worten gekennzeichnet ("nichts dokumentiert, warum – Bestätigung lohnt sich") ausgeliefert, da es sich um eine unbeabsichtigte Lücke und nicht um eine Entscheidung handeln kann. Die Quellenangabe ist Ihr Tor, nicht das Lesen des Prüfers: Sie entscheidet, was Sie schreiben dürfen, und erscheint niemals im Text. Fragen Sie bei Unsicherheit immer. Raten Sie niemals.

Das Artefakt

<slug>.HANDOVER.md in der Planungsheimat; bereits vorhanden → <slug>.HANDOVER-2.md, -3, … – niemals überschreiben. Keine Planungsheimat → den Inhalt präsentieren und fragen, wo gespeichert werden soll. Sein Text ist einfügebereit als PR-Beschreibung und steht für sich allein:

• Nur das erwähnen, was der Prüfer öffnen kann – eine Tracker-URL oder eine Datei, von der Sie überprüft haben, dass sie auf dem Branch eingecheckt ist. Alles andere – Planungsdokumente, Entscheidungsprotokolle, Sitzung, Commit-Hashes – wird weder verlinkt noch genannt: Schreiben Sie, was es sagt ("dies sollte …"), niemals, wo es das sagt.
• Verknüpfte Tickets bleiben unerwähnt, es sei denn, ein "Warum" hängt von einem ab ("so gebaut, um sich auf vorzubereiten") – dann zitieren Sie dessen Tracker-URL.
• Unter einem Bildschirm, ~400 Wörter; die folgenden Obergrenzen sind Grenzen, keine Ziele.
• Klare, für den Prüfer bestimmte Formulierung, niemals das Vokabular dieses Skills. Halten Sie vor dem Entwurf tatsächlich use-conversational-language an – das Aufsagen seiner Regeln aus dem Gedächtnis zählt nicht.

Abschnitte, die nur übersprungen werden, wenn sie wirklich leer sind:

1. Was und warum – 2–3 Zeilen.
2. Wissenswerte Entscheidungen – höchstens 5 Zeilen, jede: was gewählt wurde oder was vom Plan abweicht, sein "Warum" oder die "fehlendes-Warum"-Markierung und wo im Code es zu sehen ist.
3. Review-Leitfaden – die wenigen Dateien, bei denen Beurteilung zählt und warum; der Rest als mechanisch benannt.
4. Bekannte Lücken – höchstens 3: Mängel, Annahmen, offene Fragen.

Erledigt, wenn jeder Abschnitt gefüllt oder wissentlich übersprungen ist, nichts als verifiziert gelesen wird, was es nicht war, und nichts im Text auf etwas zeigt, das der Prüfer nicht öffnen kann.

Grenzen

• Keine Quelldateien ändern; das Übergabedokument ist die einzige geschriebene Datei.
• Niemals pushen oder eine PR öffnen/kommentieren – das Veröffentlichen ist der ausdrückliche Aufruf des Benutzers.