CommunityRecherche & Datenanalysegithub.com

Roberdan/roberdan-os

CLI-first Workflows für KI-Agenten: gemeinsame Anweisungen, wiederverwendbare Fähigkeiten, Multi-Modell-Delegation, menschliche Freigaben und lokales Task-Tracking.

Was ist roberdan-os?

Diese Fähigkeit definiert einen plattformunabhängigen „Ship“-Workflow, der KI-Agenten dabei hilft, Code zuverlässig von der Entwicklung bis zur Produktion zu bringen – ohne Abkürzungen. Sie basiert auf einem strengen lokalen CI-Pipeline (Format, Lint, Typcheck, Test, Build), der vor jedem Push ausgeführt werden muss. Der Workflow erzwingt dedizierte Branches, konventionelle Commits mit Belegen, Pull-Requests mit Zusammenfassung und Testplan sowie Merge-Commits (kein Squash oder Rebase), um die Historie für parallele Agenten zu erhalten. Menschliche Schranken (z. B. Merge auf `main` mit Branch-Protection oder Force-Push) erfordern explizite Freigabe, und alle Review-Kommentare müssen gründlich analysiert und beantwortet werden. Die Fähigkeit ist für CLI-gesteuerte KI-Agenten wie Claude Code, Cursor oder Codex konzipiert und nutzt `git` und `gh` als primäre Werkzeuge.

Funktioniert mit✓Claude Code✓Codex CLI~Cursor
npx skills add Roberdan/roberdan-os

Installed? Explore more Recherche & Datenanalyse skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

ship — die Arbeit in Produktion bringen (git + gh)

Plattformunabhängiger Ship-Workflow. Keine Umgehungen, keine Abkürzungen.

Pre-Push: lokale CI-Pipeline (alles grün vor dem Pushen)

  1. Format — cargo fmt --check / prettier --check / ruff format --check
  2. Lint — cargo clippy -- -D warnings / eslint / ruff check
  3. Typcheck — cargo check / npx tsc --noEmit
  4. Test — cargo test / npm test / pytest (Ausgabe anzeigen)
  5. Build — cargo build / npm run build

Wenn ein Schritt fehlschlägt: Beheben und alle Prüfungen erneut ausführen. Niemals mit bekannten Fehlern pushen.

Ablauf

  1. Dedizierter Branch (niemals direkt auf main arbeiten).
  2. Commit pro Phase, konventionell + nachweisorientierte Nachrichten (SHA/PR/CI).
  3. git push des Branches.
  4. PR öffnen: Zusammenfassung + Testplan (5-teilige Vorlage, falls das Repository eine verwendet).
  5. CI beobachten: gh pr checks <n> — alle ERFOLGREICH, bevor es weitergeht.
  6. Merge: nur Merge-Commit (niemals squashen, niemals rebasen – bewahrt Historie für parallele Agenten).
  7. Nach dem Merge: Branch löschen, lokales main per Fast-Forward aktualisieren, den Merge-Commit-SHA melden.

Menschliche Schranken (STOP — zuerst fragen)

  • Merge auf main mit Auswirkungen auf Branch-Protection / Sicherheit / Lizenz / Release-Infrastruktur (#1)
  • Force-Push auf main (#2) — immer ohne explizite Bestätigung verboten
  • CI nicht vollständig grün → nichts Ausstehendes/Fehlschlägiges mergen

Review-Kommentare

Jeder Kommentar (von Mensch oder Bot) muss analysiert, verstanden und gründlich behoben werden — niemals stumm schließen, niemals eine „Korrektur“, die nur die zitierte Zeile betrifft, während der Kern ignoriert wird. Antworte im Thread mit dem, was du getan hast und warum, dann schließe. Siehe skills/review.

Verwandte Skills