oh-my-openagent-toolkit – Ein lokales Betriebs-Toolkit, das mit Claude Code begann und sich bei OpenCode/oh-my-openagent eingependelt hat

Hallo.
Schon als ich Claude Code intensiv genutzt habe, hatte ich das Gefühl, dass man, wenn man AI-Coding-Agenten tatsächlich in ein Projekt integriert, am Ende eher eine Ebene braucht, die erklärt, „wie in diesem Projekt gearbeitet werden soll“, als sich nur auf den Code selbst zu konzentrieren.

Zum Beispiel solche Dinge:

• wohin bestimmte Anfragen geroutet werden sollen
• welche built-in helper angebunden werden sollten
• bis wohin der Support-Bereich reicht, über den man aktuell wirklich mit Nachdruck sprechen kann
• wo neue Arbeiten angelegt werden und wie bestehende Projekte behandelt werden sollten
• wie und ab wo UI-bezogene Refinements sinnvoll ergänzt werden sollten

Anfangs habe ich das auf der Claude-Code-Seite immer weiter auf meine Weise verfeinert, zwischendurch auch einen Wechsel zu OpenCode ausprobiert, und inzwischen bin ich bei oh-my-openagent gelandet und habe es in eine Form gebracht, die sich in lokalen Projekten konsistenter nutzen lässt.
Dies habe ich nun unter dem Namen oh-my-openagent-toolkit veröffentlicht.

GitHub:
https://github.com/HanTechnology/oh-my-openagent-toolkit

Was ist das?

Kurz gesagt:
Ein project-local companion toolkit für den Einsatz auf OpenCode + oh-my-openagent.

Etwas konkreter gesagt:
Es soll nicht das Upstream-Harness ersetzen, sondern liegt eher darüber und macht die lokale Betriebsebene klarer.
Dieses Repo ergänzt vor allem Folgendes.

• thin routing
  • ordnet, wohin Anfragen geschickt werden sollen
  • gibt klarer vor, welche category / helper passend sind
• skill surface
  • organisiert die Top-Level-Entrypoints unter .opencode/skills/
  • aktuell gibt es 43 Entrypoints, davon 40 core surface und 3 geplante adjacent packs
• support boundary
  • trennt validated / guided / planned
  • damit ist unterschieden zwischen „scheint zu funktionieren“ und „kann man derzeit öffentlich mit Nachdruck sagen“
• workspace convention
  • legt fest, wie vom Repo-Root aus gelesen wird und woran sich die Arbeit orientiert
• UI refinement layer
  • bündelt impeccable-bezogene Dinge lokal
  • damit sich bei UI-Arbeiten zusätzlich zur primary route noch eine refinement layer aufsetzen lässt

Warum wurde das gebaut?

Wenn man AI-Coding-Agenten in reale Projekte einbindet, kommt irgendwann der Moment, in dem nicht mehr so wichtig ist, „wie schlau der Agent ist“, sondern „nach welchen Regeln sich der Agent in diesem Projekt bewegen soll“.

Gerade wenn mehrere Domänen zusammenkommen, gilt das umso mehr.

• frontend / backend / systems / data / security / QA
• die Grenze zwischen Implementierung und Validierung
• die Unterscheidung zwischen Dokumentation und tatsächlich validierter surface
• wann man agent helper einbindet und wann nicht

Statt all das jedes Mal lang in Prompts zu schreiben oder nur im Kopf zu behalten, dachte ich, es wäre besser, eine dünne Betriebsebene direkt im Projekt zu hinterlassen.
Ich habe auch klar festgehalten, was dieses Repo nicht sein will.

Es ist nicht eines der folgenden drei Dinge.

• (X) eine offizielle Upstream-Distribution von oh-my-openagent
• (X) eine neue Runtime, die das Harness ersetzt
• (X) eine weitere lokale Control Plane

Mit anderen Worten: Es ist ein companion toolkit, das auf dem Upstream aufsetzt,
aber nicht der Versuch, noch ein weiteres Framework zu schaffen.

Wie weit ist es aktuell?

Auch hier wollte ich es nicht übermäßig einschränken.
Dieses Repo verfügt derzeit über eine broad skill surface mit 43 Skills für die gesamte Entwicklung,
aber aktuell als validated eingestuft sind diese 4.

• frontend-product-delivery
• backend-service-delivery
• cloud-release-readiness
• ai-data-product-delivery

Alles andere ist als guided oder planned eingeordnet.

Für wen ist das geeignet?

Für folgende Leute könnte es passend sein.

• Leute, die OpenCode bereits nutzen oder ausprobieren möchten
• Leute, die auf oh-my-openagent eine klarere lokale Projekt-Betriebsebene aufsetzen möchten
• Leute, die AI-Coding-Agenten tatsächlich auf Repo-/Worktree-Ebene betreiben und
  routing / support boundary / workspace rules ordnen möchten
• Leute, die statt immer längerer Prompts lieber Betriebswissen im Projekt selbst hinterlassen möchten

Schnell ausprobieren

Für dieses Repo reicht grob die folgende Reihenfolge.

1. OpenCode installieren
2. oh-my-openagent einrichten
3. Repo clonen
4. opencode ausführen
5. mit der Kombination aus Sisyphus oder Prometheus + Atlas aus oh-my-openagent vibe-coden

Zum Schluss

Es ist noch eher kein fertiges Gesamtprodukt,
sondern eher ein lokales Betriebs-Toolkit, das ich beim Wechsel von Claude Code → OpenCode → oh-my-openagent aus echtem Bedarf heraus zusammengestellt habe.

Wenn es hier Leute mit ähnlichen Überlegungen gibt, freue ich mich über Feedback.

Repo:

https://github.com/HanTechnology/oh-my-openagent-toolkit