langfuse/langfuse

Was macht langfuse?

Workflow für das langfuse-Repository: Git, GitHub, Commits, Branches, Pull Requests, Issue-Suche, Releases und Produktions-Promotion. Verwenden Sie dies beim Staging, Committen, Pushen, Erstellen von PRs, Auswählen eines Linear-Git-Branch-Namens, Bearbeiten von Claude-, Greptile- oder Codex-Review-Kommentaren, Durchsuchen von GitHub-Issues oder Ändern des Release-/Promotion-Verhaltens.

Übersicht

Dieser Skill definiert die Regeln und Konventionen für die tägliche Entwicklung am langfuse/langfuse Repository.

Wann aktivieren?

• Immer wenn Sie git-Befehle ausführen (staging, commit, push)
• Immer beim Erstellen oder Aktualisieren von Pull Requests
• Immer beim Durchsuchen von Issues
• Immer bei der Code-Review-Verarbeitung (Claude, Greptile, Codex)
• Immer beim Auswählen von Branch-Namen (Linear oder andere Systeme)
• Immer beim Ändern von Release-/Promotion-Verhalten

Git-Workflow

Branches

• main: Stabiler, produktionsbereiter Branch. Direkte Commits sind verboten.
• release/*: Release-Branches (z. B. release/v1.2.3).
• feat/*: Feature-Branches.
• fix/*: Bugfix-Branches.
• chore/*: Wartungsarbeiten, Refactoring, CI.

Branch-Namenskonvention: <typ>/<kurzbeschreibung> in Kebab-Case.

Commits

• Verwenden Sie aussagekräftige Commit-Nachrichten.
• Format: <typ>(<scope>): <kurzbeschreibung>
  • Typen: feat, fix, chore, docs, style, refactor, perf, test
  • Scope: optional, z. B. api, ui, core
  • Beispiel: feat(api): Nutzer-Login-Endpunkt hinzufügen

Pull Requests

• Titel im gleichen Format wie Commit-Nachrichten.
• Fügen Sie einen Link zum zugehörigen Issue hinzu (falls vorhanden).
• Fügen Sie eine kurze Beschreibung der Änderungen hinzu.
• Warten Sie auf alle Checks, bevor Sie mergen.
• Verwenden Sie Squash-Merge für Feature-Branches.

GitHub-CLI-Befehle

Nutzen Sie gh für schnelle Operationen:

# Issues durchsuchen
gh issue list --state open --label bug

# Issue anzeigen
gh issue view <nummer>

# PR erstellen
gh pr create --base main --title "feat: Neues Feature" --body "Beschreibung"

# PR überprüfen
gh pr review <nummer> --approve

# Release erstellen
github release create v1.0.0 --title "Version 1.0.0" --notes "Release-Notizen"

Code Review

Wenn Sie Kommentare von Claude, Greptile oder Codex erhalten:

1. Lesen Sie den Kommentar sorgfältig.
2. Nehmen Sie die vorgeschlagenen Änderungen an.
3. Committen und pushen Sie in den gleichen Branch.
4. Falls nötig, kommentieren Sie im PR auf die Review-Hinweise.

Release- & Promotion-Workflow

1. Vorbereitung: Branch release/v<version> von main erstellen
2. Stabilisierung: Nur Bugfixes im Release-Branch
3. Tag: v<version> erstellen
4. Release: GitHub Release erstellen mit Changelog
5. Promotion: In Produktion deployen (über CI/CD)
6. Backport: Falls nötig, Bugfixes zurück in main portieren

Lineare Integration

Verwenden Sie die lineare Issue-ID als Branch-Name:

git checkout -b feat/LANG-12345-neue-funktion

Weitere Hinweise

• Keine sensiblen Daten (Tokens, Passwörter) in Commits oder Issues.
• Immer git pull --rebase verwenden, bevor Sie pushen.
• Niemals direkt in main committen.
• Immer in Feature-Branches arbeiten.