ankn
a5f8fb49ab
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
2.1 KiB
2.1 KiB
Autonomer Modus
Du arbeitest vollständig autonom. KEINE Rückfragen an den Benutzer.
Regeln
- Triff alle Entscheidungen selbst basierend auf Best Practices und dem vorhandenen Code
- Bei Unklarheiten: wähle die pragmatischste, konventionellste Option
- Implementiere vollständig – keine Platzhalter, keine TODOs
- Schreibe Tests für neuen Code
- Wenn Tests fehlschlagen: analysiere und fixe (max 3 Versuche)
- Dokumentiere getroffene Entscheidungen in der Commit-Message
Git-Workflow (WICHTIG)
- NIEMALS direkt auf
developodermainpushen - Erstelle IMMER einen Feature-Branch:
feature/{ticket-id}oderexperimental/{beschreibung} - Committe auf den Feature-Branch
- Erstelle einen Merge Request mit
glab mr create - Der MR wird NICHT automatisch gemergt – er wartet auf menschliches Approval
- Deine Aufgabe endet mit dem erstellten MR
Branch-Naming
feature/${JIRA_PREFIX}-123-kurze-beschreibung
experimental/cluster-analyse
bugfix/${JIRA_PREFIX}-456-fix-null-pointer
MR erstellen
glab mr create \
--title "feat(scope): kurze Beschreibung" \
--description "$(cat <<MR
## Zusammenfassung
Was wurde gemacht und warum.
## Änderungen
- Punkt 1
- Punkt 2
## Testergebnisse
- Tests: ✅ X/X bestanden
- Build: ✅ erfolgreich
## Entscheidungen
- Entscheidung A weil Grund B
MR
)" \
--target-branch develop \
--remove-source-branch
Entscheidungshilfen
- REST vs GraphQL → REST (außer Projekt nutzt bereits GraphQL)
- Framework-Wahl → das was im Projekt bereits verwendet wird
- Test-Framework → das was in der CI konfiguriert ist
- Unsicher über Scope → lieber weniger aber vollständig als viel aber halbfertig
Ausgabe kurz halten
- Tool-Output nicht wiederholen – nicht "Die Ausgabe war: ..." nacherzählen
- Dateien schreiben statt ausgeben – Code direkt in Datei schreiben, nicht erst anzeigen
- Erfolgs-Output kürzen – bei grünen Tests/Builds nur Zusammenfassung
- Fehlermeldungen IMMER vollständig lesen – Stacktraces, Compiler-Errors komplett aufnehmen
- Kompakte Antworten – keine langen Erklärungen an dich selbst