amanjotx/Agent-Fähigkeiten

/ship

Aktuelle Arbeit committen, pushen und einen Pull-Request öffnen. Das Aufrufen dieser Fähigkeit ist die explizite Erlaubnis, Branches zu erstellen/wechseln, zu committen, zu pushen und gh pr create auszuführen.

Harte Regeln

• Befolgen Sie das Git-Sicherheitsprotokoll des Benutzers: Niemals die Git-Konfiguration ändern; niemals Hooks überspringen; niemals Force-Push zu main/master; nur dann Amenden, wenn die Amend-Regeln vollständig erfüllt sind.
• Niemals Geheimnisse committen (.env, Anmeldeinformationen, private Schlüssel, Tokens). Warnen und ausschließen, falls vorhanden.
• Nur Dateien stagen, die zu dieser Änderung gehören. Keine pauschalen git add . / git add -A verwenden, es sei denn, der Baum ist eindeutig absichtlich und frei von Müll.
• HEREDOC für Commit-Nachrichten und PR-Bodies verwenden.
• Diesen Workflow projektagnostisch halten. Überprüfungsbefehle und Layout aus dem Repository ableiten; keine App- oder Paketnamen hartcodieren.
• Die PR-URL zurückgeben, wenn fertig.

Konventionelle Commit-Präfixe

Produktionsreife Conventional Commits verwenden. Einen primären Typ auswählen:

Präfix	Wann
feat	Neue benutzerseitige Funktion
fix	Fehlerbehebung
refactor	Interne Umstrukturierung ohne beabsichtigte Verhaltensänderung
perf	Leistungsverbesserung
chore	Wartung, Werkzeuge, Abhängigkeiten, Haushalt
docs	Nur Dokumentation
test	Nur Tests
ci	CI-Konfiguration / Pipelines
build	Build-System- oder Bundler-Änderungen
style	Formatierung / lint-getriebene Änderungen ohne Logikänderung
revert	Einen vorherigen Commit rückgängig machen

Format:

typ(optionaler-gültigkeitsbereich): imperative Zusammenfassung

Optionaler Body: Warum diese Änderung existiert (1–2 Sätze).

Beispiele: feat(auth): refresh token Rotation hinzufügen, fix: Doppeltes Absenden beim Checkout verhindern, chore: Lint-Konfiguration aktualisieren.

Workflow

1. Überprüfen (parallel ausführen)

• git status
• git diff und git diff --staged
• git branch -vv (aktueller Branch + Tracking)
• git log -8 --oneline (Nachrichtenstil)
• Standard-Basis-Branch (main bevorzugt, sonst master oder Repository-Standard)
• Remote-Synchronisationszustand (git status -sb, nicht gepushte Commits)

Wenn es nichts zu committen gibt und keine für diese Arbeit relevanten, nicht gepushten Commits vorhanden sind, anhalten. Keinen leeren PR öffnen.

2. Den korrekten Branch sicherstellen

Ziel: Arbeit auf einem dedizierten Feature-Branch basierend auf dem aktuellen Base landen.

1. Feststellen, ob der aktuelle Branch für diese Änderungen vorgesehen ist:

   • Ja, wenn es bereits ein beschreibender Themen-Branch für diese Arbeit ist (feat/…, fix/…, chore/… oder klar dem Änderungszweck entsprechend) und es nicht der Standard-Branch ist.
   • Nein, wenn auf main/master/Standard, einem nicht passenden Themen-Branch, einem veralteten, nicht verwandten Branch oder einem detached HEAD.

2. Wenn der aktuelle Branch nicht für diese Änderungen vorgesehen ist:

   • Wenn der Working Tree verschmutzt ist, stashen mit einer klaren Nachricht (Standard; nicht fragen, es sei denn, Stash ist unmöglich).
   • git checkout <base>
   • git pull --ff-only (oder gleichwertiges Fast-Forward-Update vom Tracking-Remote)
   • Einen neuen beschreibenden Branch erstellen und auschecken, z.B. feat/art-thema, fix/art-thema, chore/art-thema
   • git stash pop auf den neuen Branch; Konflikte ggf. lösen.

3. Wenn der aktuelle Branch für diese Änderungen vorgesehen ist:

   • Darauf bleiben.
   • Vor dem Commitieren bei Bedarf vom Base aktualisieren (Rebase oder Merge vom aktuellen Base gemäß den Repository-Gepflogenheiten; zerstörungsfreie Optionen bevorzugen; keinen Force-Push durchführen, es sei denn, der Benutzer bittet explizit darum).

Niemals einen PR direkt vom Standard-Branch aus erstellen.

3. Committen

• Einen kohärenten Commit bevorzugen, es sei denn, der Benutzer hat eine Aufteilung gewünscht.
• Nachricht verwendet ein korrektes konventionelles Präfix und eine imperative Zusammenfassung.
• Body (optional): Fokus auf warum, keine Dateiliste.
• Nach dem Commit git status ausführen, um den erwarteten Zustand zu bestätigen.
• Wenn ein Hook fehlschlägt: Das Problem beheben und einen neuen Commit erstellen. Nicht amenden, es sei denn, die Amend-Regeln sind vollständig erfüllt.

4. Pushen

git push -u origin HEAD

Erforderliche Berechtigungen anfordern, wenn Sandbox/Netzwerk/gh die Operation blockiert.

5. Den PR öffnen

Alle Commits analysieren, die in den Base gemergt werden (nicht nur den neuesten).

Titel: Gleicher Geist wie die Commit-Zusammenfassung – klar, spezifisch, konventionell, wenn es hilft. Keine vagen Titel.

Body-Vorlage (erforderlich):

## Zusammenfassung

- 2–5 Aufzählungspunkte, was ausgeliefert wird und warum es wichtig ist

## Warum

- Problem, Motivation oder Auslöser für diese Änderung

## Was hat sich geändert

- Aufzählungspunkte, gruppiert nach Belang (Verhalten, API/Verträge, Daten, UI, Infra, Tests, Docs)
- Änderungen mit Breaking Changes, Migrationen oder Auth/Session-Verhaltensänderungen explizit benennen

## Architektur / Ablauf

Mindestens eines einschließen:

1. Mermaid-Diagramm (Sequenz, Flussdiagramm oder Zustand) für den primären Pfad
2. ASCII-Diagramm für Struktur, Schichtung oder vorher → nachher

Mermaid für Kontrollfluss verwenden; ASCII für Bäume oder Ebenenkarten.
Diagramme müssen zum tatsächlichen Diff passen – keine Architektur erfinden.

## Risiko / Rollback

- Wahrscheinliche Fehlermodi
- Sichere Rücknahme / Minderungshinweise

## Testplan

- [ ] Konkrete Schritte, die ein Prüfer ausführen kann
- [ ] Repo-angemessene Verifikationsbefehle, die aus dem Projekt ermittelt wurden

Mit gh pr create und einem HEREDOC-Body erstellen. --base bei Bedarf explizit setzen.

6. Rückmeldung geben

Kurz halten:

• Branch-Name
• Commit-Zusammenfassung
• PR-Titel
• PR-URL
• ggf. absichtlich nicht committete Dateien