Project Flow Ops
Dieser Skill verwandelt isolierte GitHub Issues, Pull-Requests und Linear-Aufgaben in einen einzigen Ausführungsfluss.
Verwende ihn, wenn das Problem Koordination ist, nicht Programmierung.
Wann verwenden
- Triage von offenen PR- oder Issue-Backlogs
- Entscheiden, was in Linear gehört und was GitHub-exklusiv bleiben sollte
- Aktive GitHub-Arbeit mit internen Ausführungsspuren verknüpfen
- PRs in Merge, Port/Neubau, Schließen oder Parken klassifizieren
- Prüfen, ob Review-Kommentare, CI-Fehler oder veraltete Issues den Fortschritt blockieren
Betriebsmodell
- GitHub ist die öffentliche und Community-Wahrheit
- Linear ist die interne Ausführungswahrheit für aktive geplante Arbeit
- Nicht jedes GitHub Issue benötigt ein Linear Issue
- Linear wird nur erstellt oder aktualisiert, wenn die Arbeit:
- aktiv
- delegiert
- geplant
- funktionsübergreifend
- wichtig genug für eine interne Verfolgung ist
Kernablauf
1. Zuerst die öffentliche Oberfläche lesen
Sammle:
- GitHub Issue- oder PR-Status
- Autor und Branch-Status
- Review-Kommentare
- CI-Status
- Verknüpfte Issues
2. Arbeit klassifizieren
Jedes Element sollte in einem dieser Zustände enden:
| Zustand | Bedeutung |
|---|---|
| Merge | in sich geschlossen, richtlinienkonform, bereit |
| Port/Neubau | nützliche Idee, sollte aber manuell innerhalb von ECC neu eingebracht werden |
| Schließen | falsche Richtung, veraltet, unsicher oder dupliziert |
| Parken | potenziell nützlich, aber nicht für jetzt geplant |
3. Entscheiden, ob Linear gerechtfertigt ist
Linear nur erstellen oder aktualisieren, wenn:
- die Ausführung aktiv geplant ist
- mehrere Repos oder Arbeitsströme betroffen sind
- die Arbeit interne Verantwortung oder Reihenfolge benötigt
- das Issue Teil einer größeren Programmspur ist
Nicht alles mechanisch spiegeln.
4. Die beiden Systeme konsistent halten
Wenn Arbeit aktiv ist:
- GitHub Issue/PR sollte öffentlich sagen, was passiert
- Linear sollte Besitzer, Priorität und Ausführungsspur intern verfolgen
Wenn Arbeit ausgeliefert oder abgelehnt wird:
- die öffentliche Lösung zurück an GitHub posten
- die Linear-Aufgabe entsprechend markieren
Überprüfungsregeln
- Niemals allein aufgrund des Titels, der Zusammenfassung oder des Vertrauens mergen; das vollständige Diff verwenden
- Features aus externen Quellen sollten innerhalb von ECC neu gebaut werden, wenn sie wertvoll aber nicht in sich geschlossen sind
- CI-Rot bedeutet klassifizieren und beheben oder blocken; nicht so tun, als wäre es merge-bereit
- Wenn der wahre Blockierer die Produktrichtung ist, dies sagen, anstatt sich hinter Werkzeugen zu verstecken
Ausgabeformat
Rückgabe:
ÖFFENTLICHER STATUS
- Issue / PR-Status
- CI / Review-Status
KLASSIFIKATION
- merge / port-neubau / schließen / parken
- ein Absatz Begründung
LINEAR-AKTION
- erstellen / aktualisieren / kein Linear-Element nötig
- Projekt / Spur falls zutreffend
NÄCHSTER OPERATOR-SCHRITT
- genauer nächster Schritt
Gute Anwendungsfälle
- "Prüfe den offenen PR-Backlog und sage mir, was gemerged vs. neu gebaut werden soll"
- "Bilde GitHub Issues auf unsere ECC 1.x- und ECC 2.0-Programmspuren ab"
- "Prüfe, ob dies ein Linear Issue benötigt oder GitHub-exklusiv bleiben sollte"