Apothem vs. rohe CodeBuddy-Regeln
Warum man die Projektregeln von CodeBuddy über Apothem führt, statt pro Projekt .codebuddy/rules-Dateien von Hand zu verfassen.
CodeBuddy liest Projektregeln aus .codebuddy/rules/*.md. Du kannst diese Dateien von Hand verfassen, pro Projekt, für immer. Der codebuddy-Adapter von Apothem rendert eine davon aus dem gemeinsamen Profil und hält sie über jedes Harness und jedes Projekt hinweg konsistent. Diese Seite stellt das Pflegen dieser Konfiguration von Hand der Verwaltung mit Apothem gegenüber.
Aufwandsvergleich
| Aufgabe | Manuelle Konfiguration | Von Apothem verwaltet |
|---|---|---|
| Regeln schreiben | Dieselben Disziplinen pro Projekt in .codebuddy/rules/ kopieren und einfügen | Aus einem gemeinsamen Korpus gerendert |
| Quelle der Wahrheit | Die eigenen Dateien jedes Projekts | Eine kanonische Kohorte |
| Regeln über Harnesses hinweg abgestimmt halten | Pro Werkzeug neu ableiten | Automatisch projiziert |
| Regeln aktualisieren | Jedes Projekt von Hand bearbeiten | apothem update --harness codebuddy --project <path> |
| Konfiguration entfernen | Manuell löschen | apothem uninstall mit zeitgestempeltem Backup |
| Wiederverwendbare Skills und Befehle teilen | Jeden Skill-Ordner von Hand nach ~/.codebuddy/skills/ kopieren und die Kopien aktuell halten | Vom Adapter nach ~/.codebuddy/skills/ geschrieben, eine gemeinsame Kopie für alle Projekte, und bei apothem update aufgefrischt |
Was Apothem verwaltet
Der codebuddy-Adapter rendert die gemeinsamen Regeln in eine dedizierte Datei <project>/.codebuddy/rules/apothem-rules.md. Außerdem schreibt er zwei Ordner in deinem Home-Verzeichnis, die alle Projekte teilen: Die Skills und die als Skills verpackten Befehle kommen nach ~/.codebuddy/skills/, und die Regeln und Templates, die diese Skills zitieren, kommen nach ~/.config/apothem/rules/ und ~/.config/apothem/templates/. Deine Memory-Datei CODEBUDDY.md, deine Berechtigungen und MCP-Server in .codebuddy/settings.json sowie alle anderen von dir verfassten Regeldateien bleiben vollständig im Besitz des Operators; der Adapter erkennt diese Oberflächen, bearbeitet sie aber nie. Jede Änderung an den gemeinsamen Regeln rendert die Regeldatei beim nächsten apothem update neu.
Migrationspfad
- Führe
apothem profile initaus, um das gemeinsame Profil zu erstellen, falls noch nicht geschehen. - Verschiebe die Disziplinen aus deinen bestehenden Dateien in
.codebuddy/rules/in den gemeinsamen Korpus. - Führe
apothem install --harness codebuddy --project <path>aus, um die Dateiapothem-rules.mdneben deinen eigenen, unveränderten Regeln zu rendern. - Führe
apothem verify --harness codebuddy --project <path>aus, um zu bestätigen, dass die Konfiguration angekommen ist. - Verwende
apothem update --harness codebuddy --project <path>für jede spätere Änderung.
Als Nächstes lesen
Apothem im Vergleich zur manuellen Trae-Konfiguration
Die Regeln von Trae unter .trae/rules/ von Hand pflegen, verglichen mit dem Rendern aus dem gemeinsamen Profil von Apothem.
Apothem im Vergleich zur manuellen Antigravity-Konfiguration
Den globalen Kontext und die Plugin-Dateien der Antigravity CLI von Hand pflegen, im Vergleich zur Verwaltung über das gemeinsame Profil von Apothem.