sigma-create-ticket

/sigma-create-ticket

Übersicht

/sigma-create-ticket erstellt und bearbeitet SPEC-, EPIC- und TICKET-Issues. Es ist das Gateway für /sigma-to-spec und /sigma-to-tickets. /sigma-unslop ruft ihn nicht auf.

Dieser Skill ist der einzige, der gh issue create oder gh issue edit ausführt. Er implementiert nichts, führt keine Reviews durch und führt keine Merges durch.

Lies CONVENTIONS.md vor dem Erstellen oder Bearbeiten. Diese Datei enthält die Details zu Titel, Label und Body.

Wann verwenden

• Verwenden, wenn: der Benutzer /sigma-create-ticket aufruft oder /sigma-to-spec oder /sigma-to-tickets einen Body in dieser Sitzung übergibt.
• Auflisten oder Anzeigen: /sigma-to-spec fragt nach list-specs. /sigma-to-tickets fragt nach view. Führe das Lesen aus und gib zurück. Erstelle nicht.
• Nicht verwenden, wenn: die Arbeit noch ein Lösungsinterview (/sigma-plan), eine Spezifikation (/sigma-to-spec) oder eine Aufteilung (/sigma-to-tickets) ist. Implementiere nichts, führe kein Review durch und merge nicht.

Eingabe

Eine Übergabe enthält caller, action (list-specs, view, create oder update), kind (spec, epic oder ticket), title, body und manchmal number, parent und blocked-by.

Das Ja des Benutzers ist eine Antwort in dieser Sitzung. Diese Antworten zählen als Ja und erhalten keine zweite Frage:

• /sigma-to-spec nachdem der Benutzer der Zusammenfassung zugestimmt hat
• /sigma-to-tickets nachdem der Benutzer den Körnungen und Blockierern zugestimmt hat

Jede andere Gruppe von 2 oder mehr Issues wartet hier auf ein Ja.

Issue-Vertrag

• SPEC: Titel SPEC: <name>, Label spec, kein Parent. Body: Was diese Funktion ist, was sie nicht ist, Akzeptanz-IDs, Skript-Globs unter scripts/, außerhalb des Geltungsbereichs. Keine offenen Fragen.
• EPIC: Titel EPIC: <name>, Label type:epic. Parent ist die SPEC.
• TICKET: Titel TICKET: <name>, Label type:ticket plus agent:hitl oder agent:afk. Parent ist ein EPIC oder die SPEC, wenn /sigma-to-tickets eine benennt. Ein Ticket, das aus einem Review geschnitten wurde, hat keinen SPEC-Parent, es sei denn, diese Übergabe nennt ein Epic. Body-Abschnitte: Kontext, Akzeptanz, Außerhalb des Geltungsbereichs, Branch agent/{N}-{slug}, Mode hitl oder afk.

Labels, die dieser Skill sicherstellt: spec, type:epic, type:ticket, agent:hitl, agent:afk. Das Mode-Label stimmt mit der Mode-Zeile überein.

Schritte

Schritt 1 – Das Arbeits-Repo ermitteln

Führe gh repo view --json nameWithOwner aus. Abgeschlossen, wenn owner/name ausgegeben wird. Wenn es fehlschlägt, sage dem Benutzer, er solle vom Arbeits-Repo aus starten oder gh auth login ausführen, und brich ab.

Wenn der Repo-Name auf sigma-build-factory endet, brich ab. Issues gehören zum Arbeits-Repo.

Schritt 2 – Lesen oder Schreiben

Lies CONVENTIONS.md vor einem Create oder einem Edit.

list-specs führt aus:

gh issue list --repo "$REPO" --label spec --state all --limit 50 \
  --json number,title,state,url,body

view führt gh issue view <N> --repo "$REPO" --json number,title,labels,state,url,body aus.

Gib das JSON an den Aufrufer zurück. Stelle Labels nicht sicher und stelle keine Frage.

Abgeschlossen, wenn der Aufrufer die Liste oder das Issue hat, oder der Schreibpfad bei Schritt 3 fortgesetzt wird.

Schritt 3 – Ja-Tor

Eine Übergabe aus den drei Ja-Fällen unter Eingabe ist bereit zum Einreichen.

Ein direkter Batch (2 oder mehr Issues) ohne Ja in dieser Sitzung: Zeige für jede Zeile Titel, Art, Parent und Mode an. Frage einmal: „Diese Issues einreichen?" Warte. Schweigen reicht nicht ein.

Ein einzelnes direktes Issue: Frage einmal, wenn Titel, Art oder ein Feature-Lane-Parent fehlen. Wenn diese Felder vorhanden sind, reiche ein.

Ein Update ohne Ja in dieser Sitzung: Zeige die Issue-Nummer und den Titel an, frage einmal, dann bearbeite. Erstelle kein zweites Issue.

Abgeschlossen, wenn das Ja aufgezeichnet ist oder ein einzelner vollständiger Create bereit zum Einreichen ist.

Schritt 4 – Labels sicherstellen

Im Schreibpfad liste Labels auf und erstelle alle fehlenden Namen aus dem Vertrag:

gh label list --repo "$REPO" --limit 100 --json name
gh label create <name> --repo "$REPO" --description "<from CONVENTIONS.md>"

Abgeschlossen, wenn gh label list spec, type:epic, type:ticket, agent:hitl und agent:afk anzeigt.

Schritt 5 – Vorhandenes Issue abgleichen

Liste Issues auf und vergleiche den genauen Titel SPEC: <name>, EPIC: <name> oder TICKET: <name>.

gh issue list --repo "$REPO" --state all --limit 200 --json number,title,state,url

Ein bestätigtes Update bearbeitet diese Nummer. Es erstellt nicht. Wenn der neue Titel bereits bei einem anderen Issue existiert, stoppe diesen Eintrag und melde beide Nummern.

Ein Create, das einen genauen Titel findet, meldet exists und verwendet die Nummer wieder. Es erstellt kein zweites Issue und bearbeitet den Body nicht. Zwei genaue Titel stoppen diesen Eintrag.

Abgeschlossen, wenn jeder Eintrag create, update, reuse oder collision ist.

Schritt 6 – Erstellen oder Bearbeiten

Schreibe den Body in eine temporäre Datei. Schreibe ihn nicht in das Arbeits-Repo.

Setze das Titel-Präfix, wenn der Kurzname es nicht enthält. Verdopple das Präfix nicht.

Erstelle in Reihenfolge: Epics vor ihren Tickets, Blockierer vor Abhängigen. Füge --parent hinzu, wenn die Übergabe einen benennt. Füge --blocked-by hinzu, wenn die Blockierer-Nummern bereits existieren. Lasse jedes Flag weg, wenn es keinen Wert hat.

gh issue create --repo "$REPO" --title "<title>" --label "<labels>" --body-file "$f"

Parse N aus der URL. Ein Ticket-Body, dessen Branch-Zeile fehlt oder noch {N} enthält, wird bearbeitet, sodass die Zeile agent/<N>-<slug> lautet. Der Slug ist der Name nach dem Präfix, klein geschrieben, Leerzeichen durch Bindestriche ersetzt.

gh issue edit <N> --repo "$REPO" --body-file "$f"

Bei einem bestätigten Update ersetzt gh issue edit Titel und Body und korrigiert Labels. Entferne das andere Mode-Label, sodass nur das passende übrig bleibt. Ändere den Parent beim Edit nicht.

Eine SPEC erhält nur Label spec. Ein EPIC erhält nur type:epic. Ein TICKET erhält type:ticket und das eine Mode-Label.

Protokolliere einen gh-Fehler und fahre mit unabhängigen Einträgen fort. Erstelle keine Kinder eines fehlgeschlagenen Epics. Schließe den Parent nicht.

Abgeschlossen, wenn gh issue view <N> --json title,labels,body den Titel, die Labels und bei einem Ticket Branch agent/<N>-<slug> mit passendem Mode-Label anzeigt.

Schritt 7 – Rückgabe

Gib Nummer, Titel und URL für jeden Eintrag zurück, einschließlich exists und Fehlern.

Wenn der Aufrufer ein anderer Skill ist, höre hier auf. Dieser Skill nennt den nächsten Befehl. Wenn der Benutzer /sigma-create-ticket aufgerufen hat, nenne den nächsten Befehl und führe ihn nicht aus. Eine SPEC geht an /sigma-to-tickets <N>. Ein Ticket geht an /sigma-implement <N>. Für ein Epic sage, dass /sigma-implement ein Epic ablehnt.

Harte Regeln

Regel	Warum / Wie eine Verletzung aussieht
Dieser Skill ist der einzige, der gh issue create oder gh issue edit ausführt. List- und View-Aufrufe für die anderen Skills werden ebenfalls hier ausgeführt.	Ein zweiter Schreibpfad driftet Titel, Label und Parent ab.
Stelle die fünf Labels sicher, dann erstelle oder bearbeite.	Ein fehlendes Label führt zum Fehlschlag des nächsten Issues im Batch.
Ein bestätigtes Update bearbeitet dieses Issue. Ein exakter Titel-Match erstellt kein Duplikat.	Ein zweiter SPEC: oder TICKET: spaltet ein Feature.
Ein direkter Batch wartet auf ein Ja. Ein Body, der bereits von /sigma-to-spec oder /sigma-to-tickets in dieser Sitzung bestätigt wurde, erhält keine zweite Frage.	Erneutes Fragen blockiert die Übergabe. Das Einreichen eines direkten Batchs bei Schweigen erstellt Issues, die der Benutzer nicht gesehen hat.
Nach dem Erstellen bearbeite ein Ticket, sodass Branch agent/<N>-<slug> ist. Das Mode-Label stimmt mit der Mode-Zeile überein.	Ein übrig gebliebenes {N} oder afk mit agent:hitl schickt den Builder zum falschen Branch oder zur falschen Mode.
Setze den Parent beim Erstellen, wenn die Übergabe einen nennt. Ein Ticket aus einer Spezifikation parentet an ein EPIC oder die SPEC. Ein Ticket aus einem Review lässt den Parent weg, es sei denn, die Übergabe nennt ein Epic.	Das Erfinden eines SPEC-Parents kopiert die Akzeptanz, die das Review-Ticket nicht implementiert.
Implementiere nichts, führe kein Review durch und merge nicht.	Dieser Skill erstellt das Issue und stoppt.

Verifikation

• gh repo view gab das Arbeits-Repo zurück, und der Repo-Name endet nicht mit sigma-build-factory.
• CONVENTIONS.md wurde vor jedem Create oder Edit gelesen.
• list-specs und view gaben JSON zurück und erstellten nichts.
• Die fünf Labels existieren vor dem Create oder Edit.
• Ein direkter Batch hatte ein explizites Ja. Ein vorgelagertes Ja in dieser Sitzung erhielt keine zweite Frage.
• Ein bestätigtes Update bearbeitete das genannte Issue. Kein zweites Issue teilt diesen exakten Titel.
• Die Branch-Zeile eines neuen Tickets ist agent/<N>-<slug>, und das Mode-Label stimmt mit der Mode-Zeile überein.
• Ein Epics parentet an diese SPEC. Ein Ticket aus einer SPEC parentet an ein EPIC oder die SPEC. Ein Ticket aus einem Review hat keinen SPEC-Parent, es sei denn, die Übergabe nannte ein Epic.
• Die Rückgabe ist Nummer, Titel und URL. Dieser Skill hat nichts implementiert, kein Review durchgeführt und nichts gemergt.