Batch-Features

Was macht Batch-Features?

Aufnahme – die erste Hälfte des Workflows. Die andere Hälfte ist work-issue.

Du archivierst keinen Backlog-Dump. Du verwandelst grobe Ideen in Issues, die ein Agent planen kann, ohne deine Erkundung zu wiederholen. Das bedeutet: eine Debatte pro Eintrag, dann eine Genehmigung, dann einreichen.

Zu Beginn ankündigen: „Ich verwende den Skill batch-features, um diese Liste in Issues zu verwandeln.“

Einrichtung

shared/ ist das Verzeichnis neben diesem Skill – ~/.agents/skills/shared/ bei Installation oder ../shared/ in einem Checkout. Wenn ein Pfad shared/... nicht aufgelöst werden kann, verwende den anderen.

1. Lese das Repository: AGENTS.md (oder CLAUDE.md) im Stammverzeichnis. Es ist verbindlich für Konventionen.
2. Lese .agent-skills/config.json, falls vorhanden; anderenfalls lese shared/config.md, stelle die Fragen für die Ersteinrichtung und schreibe die Datei.
3. Lese shared/tracker-adapter.md, shared/labels.md und shared/issue-template.md.
4. Erkenne den Tracker. Sieh dir vorhandene Labels und Issues an, damit die neuen passen.
5. Templates. Prüfe, ob das Projekt bereits ein Issue-Template hat (.gitlab/issue_templates/*.md, .github/ISSUE_TEMPLATE/*.md). Wenn ja, verwende es und speichere seinen Pfad in der Konfiguration als issueTemplate. Wenn nein, merke dir, dass du am Ende einmal anbieten wirst, shared/issue-template.md in das Projekt zu committen.

Die Debatte

Arbeite die Liste Punkt für Punkt durch. Für jeden:

1. Formuliere es neu in eigenen Worten: Was es ist, wem es dient, warum jetzt. Behalte den ursprünglichen Wortlaut als wörtliches Zitat unter Absicht im Issue-Body – auch wenn der Rest auf Englisch ist.
2. Schlage eine konkrete Interpretation vor. Nicht „Was willst du hier?“ sondern „Ich verstehe das als X, weil Y. Sag Bescheid, wenn du Z gemeint hast.“
3. Stelle höchstens zwei Fragen. Jede muss spezifisch sein und jede muss einen Standardwert enthalten, den der Benutzer mit einem Wort akzeptieren kann. Frage nach dem, dessen Antwort die größte Auswirkung auf die Umsetzung hätte. Wenn der Benutzer eine vollständige Befragung verlangt hat, frage mehr; ansonsten zwei.
4. Lege zwei Dinge fest: Akzeptanzkriterien (jedes beobachtbar und überprüfbar) und die Art (feature / fix / refactor / chore). Nichts weiter – keine Größe, kein Bereich, keine Abhängigkeiten.

Wenn ein Eintrag nach der Debatte nicht festgelegt werden kann, markiere ihn als status::blocked mit einem braucht Spezifikation-Hinweis, anstatt zu raten. Ein vages Issue zu erfassen ist schlimmer, als es nicht zu erfassen.

Gehe erst zum Erfassen über, wenn jeder Eintrag debattiert wurde.

Die Übersichtstabelle

Nach dem letzten Eintrag präsentiere eine Tabelle für die gesamte Charge:

| # | Titel | Art |
|---|-------|------|
| 1 | ...   | feature |

Bitte dann um Genehmigung. Der Benutzer kann Titel bearbeiten, Einträge entfernen oder Arten ändern. Vor dieser Genehmigung wird nichts erfasst.

Die Issues erfassen

Für jeden genehmigten Eintrag in der vom Benutzer bevorzugten Reihenfolge (standardmäßig Erstellungsreihenfolge):

1. Erstelle das Issue mit dem Tracker-CLI, den Body aus dem Template des Projekts, falls vorhanden, sonst aus shared/issue-template.md. Titel und Bodies in der Sprache der Konfiguration (Standard en).
2. Wende Labels an: status::ready und kind::<Art>. Notiere die Issue-Nummer.
3. Gib die Issue-URLs aus.

Wenn die Liste des Benutzers eine Reihenfolge implizierte („X puis Y“), vermerke dies im Issue-Body unter Notizen – erstelle keine Abhängigkeitsbeziehung oder ein Label.

Wenn das Projekt kein Issue-Template hat und der Benutzer dein Angebot angenommen hat, committe shared/issue-template.md einmalig in den vom Tracker erwarteten Pfad, und erfasse dann. Erstelle es nicht stillschweigend.

Bericht

Gib am Ende aus:

• Die Issue-URLs, eine Zeile pro Issue.
• Die Zusammenfassung der Charge: N erfasst, M blockiert.
• Eine Zeile: „Um die Arbeit zu starten, sage work-issue <n>.“

Harte Schranken

• Kein Issue wird ohne die Genehmigung der Übersichtstabelle erstellt.
• Kein Issue wird mit einem leeren Abschnitt Akzeptanzkriterien oder Verifikation erstellt.
• Kein Issue wird mit einem geschätzten Umfang erstellt: Wenn es nach der Debatte vage ist, wird es als status::blocked markiert.
• Beanspruche nie ein Issue oder beginne eine Implementierung aus diesem Skill; das ist Aufgabe von work-issue.