OwlMeans kannst du schon heute haben — ein Befehl, jeder Agent

Die Leute fragen mich ständig, wann sie OwlMeans nutzen können. Die ehrliche Antwort war bisher: wenn die Plattform kommt. Jetzt gibt es eine bessere — den wichtigsten Teil kannst du schon heute nutzen, auf dem Agenten, dem du ohnehin schon vertraust.

OwlMeans ist eine KI-Entwicklungspipeline. Du beschreibst, was du willst, in Form von User Storys, und ein Team spezialisierter KI-Rollen verwandelt sie in Fullstack-Apps in TypeScript, die wirklich dir gehören. Unter jeder dieser Apps liegt eine einzige Bibliothek — OwlMeans Common — das, woraus all unsere Projekte gebaut sind. Diese Woche hat sie ein create-app-Paket bekommen. Ein Befehl erzeugt ein vollständiges Fullstack-Projekt, das Claude Code oder GitHub Copilot von Anfang bis Ende entwickeln kann, mit der gesamten Agenten-Anleitung schon im Karton.

Ich möchte dich durch das führen, was dieser Befehl dir gibt, warum er so gebaut ist, wie er ist, und wie du von einem leeren Ordner zu einem echten, datenbankgestützten Feature kommst, ohne selbst eine einzige Zeile Verdrahtung zu schreiben.

Der eine Befehl

Wähl deinen Paketmanager:

bun create @owlmeans/app my-app
# oder
npm create @owlmeans/app@latest my-app
# oder
npx @owlmeans/create-app my-app

Dann:

cd my-app
bun run dev          # API auf :3000, Web auf :3001

Öffne die Web-App, geh zum Session-Screen, füge ein paar Einträge hinzu und entferne sie wieder. Das ist eine funktionierende Fullstack-App: ein typisierter, geteilter Vertrag, ein Backend und ein shadcn-UI-Frontend, die miteinander reden. Keine Datenbank bereitzustellen, keine Authentifizierung zu konfigurieren, kein Boilerplate, das du aus einem Tutorial kopieren musstest.

Was du bekommst, ist ein kleines Monorepo mit drei Workspaces:

• common — der geteilte Vertrag: die Entrypoints der Routen, Validierungsschemata und die Typen, die beide Seiten nutzen.
• api — das Backend, auf @owlmeans/server-app, das die Demodaten in einer In-Memory-Resource hält.
• web — das Frontend, auf @owlmeans/web-panel, mit shadcn-Navigation, einem Layout und Screens.

Diese Struktur ist kein Spielzeug. Es ist dieselbe Form, die unsere echten Apps haben, auf das Wesentliche heruntergebrochen. Wenn du dem In-Memory-Store entwächst, tauschst du ein Paket aus — ich zeige dir das weiter unten genau.

Warum es so gebaut ist, dass Agenten sich nicht verlaufen

Hier kommt die unbequeme Wahrheit über Coding-Agenten im Jahr 2026. Sie haben keine Betriebszugehörigkeit. Jede Sitzung startet bei null, und jeder Aufruf zahlt den vollen Preis für alles, was dein Code nicht explizit gemacht hat. Die Zahlen sind brutal: in einer mittelgroßen Codebasis kann die Erkundungsphase — der Agent, der Dateien liest, nur um herauszufinden, wo was liegt — „60–70 % der gesamten Input-Tokens“ verschlingen, und eine einzige Aufgabe kann Hunderttausende bis Millionen kumulierter Tokens durch das Modell jagen. Der Agent ist klug. Der Agent „startet aber bei null, abgesehen von dem, was du ihm explizit ins Kontextfenster gibst“.

Die Frage, die OwlMeans Common geprägt hat, war also einfach: Wie sieht eine Codebasis aus, die so entworfen ist, dass sie von etwas gelesen wird, das zwischen den Sitzungen alles vergisst?

Die Antwort entpuppte sich als genau das, was sich gute Ingenieure schon immer gewünscht haben. Die Branche ist dieses Jahr unabhängig darauf gekommen — „Code sollte einfach, explizit und langweilig sein … damit es für die KI nichts zu entscheiden gibt“, und Agenten „tun sich schwer mit implizitem Verhalten und cleveren Abstraktionen“. Genau das ist die Vorgabe, unter der wir gebaut haben:

• Keine komplexen DI-Schemata. Services sind ganz normale TypeScript-Factory-Funktionen, registriert über einen String-Alias und abgerufen mit context.service('alias'). Keine Decorators, keine Metadaten, keine Container-Magie, die man rückwärts entschlüsseln müsste.
• Kein generierter Code. Kein OpenAPI-zu-Client-Schritt, kein Schema-Codegen, kein Build-Artefakt, das du mit der Realität synchron halten musst. Was du liest, ist das, was läuft.
• Kein YAML, kein Konfigurations-Wildwuchs. Die Konfiguration ist TypeScript. Routen und Konfiguration sind schlichte Objekte.
• Alles explizit und nachvollziehbar. Jeder Service, jede Route, jede Resource lässt sich finden, indem man danach sucht. Ein Mensch kann ihr folgen. Ein Agent auch — ohne tausend Tokens fürs Raten zu verfeuern.

Dieser letzte Punkt ist das ganze Spiel. Expliziter, langweiliger Code ist für einen Agenten günstiger zu bearbeiten, und er ist der Unterschied zwischen einem Assistenten, der souverän die richtige Datei editiert, und einem, der über vierzig Dateien herumirrt.

Die vier Ideen, die dem Agenten die Arbeit leicht machen

Vier Designentscheidungen erledigen den größten Teil der Arbeit. Du musst sie dir nicht merken — aber es lohnt sich, sie einmal gesehen zu haben, denn sie sind der Grund, warum eine Feature-Anfrage an Claude Code sauber landet, statt auszuufern.

Context Injection. Der App-Kontext hält deine Services und Resources und wird von oben nach unten durchgereicht. Einen Service registrierst du als Factory-Closure und löst ihn über den Alias auf. Nichts ist verborgen: die gesamte Verdrahtung ist gewöhnlicher Code, den ein Agent in einem Durchgang liest.

Entrypoints als universelles Fullstack-Protokoll. Das ist der Schlussstein. Ein Entrypoint ist eine URL-Einheit — ein Alias, ein Pfad, eine Methode und ein eingebettetes Validierungsschema — einmal in common deklariert:

entrypoint(
  route(session.add, '/:sid/items', { parent: session.base, method: RouteMethod.POST }),
  filter(params(SessionParamsSchema), body(AddItemSchema)),
)

Das Backend elevatet denselben Entrypoint mit einem Handler. Das Frontend elevatet ihn mit einem Screen und ruft ihn mit ctx.entrypoint(session.add).call({ params, body }) auf. Eine Deklaration ist die einzige Quelle der Wahrheit für die Route, die Validierung und die Typen auf beiden Seiten. Du änderst sie einmal, und der ganze Stack bleibt synchron. Es gibt keine separate API-Spezifikation, keinen generierten Client, der aus dem Takt geraten kann. Für einen Agenten bedeutet das: ein neues Feature hat eine offensichtliche, wiederholbare Form — deklarieren, implementieren, aufrufen.

Vereinheitlichte Resources. Jeder Datenspeicher — In-Memory, MongoDB, Redis, Object Storage — implementiert dieselbe Resource<T>-Schnittstelle: get, list, create, update, delete und ein paar Geschwister. Dein Handler-Code ändert sich nicht, wenn sich der Speicher ändert. Den In-Memory-Store der Demo gegen eine echte Datenbank zu tauschen ist — fast wörtlich — eine Ein-Paket-Änderung.

Ein shadcn-UI, das dir gehört. Die Web-Schicht ist auf shadcn und Tailwind v4 gebaut, und die Komponenten leben in deinem Quellbaum — nicht hinter einer Abhängigkeit. Das ist Absicht. shadcn ist „keine Bibliothek, die du installierst — es ist ein Code-Generator … es gehört dir“, und es ist zur Komponenten-Bibliothek geworden, zu der jedes KI-Coding-Tool greift. Der Agent liest dein UI als echtes, editierbares React — denselben Code, den er ohnehin schon kennt — statt in einem undurchsichtigen Paket herumzustochern.

Vom ersten Tag an voll mit Skills ausgestattet

Hier ist der Teil, auf den ich am stolzesten bin. Das Projekt kommt an und weiß bereits, wie man es entwickelt.

Jedes @owlmeans/*-Paket bringt seine eigene Agenten-Anleitung mit — Claude-Code-Skills und GitHub-Copilot-Instructions, versionsgleich mit dem Paket. Wenn create-app mit dem Scaffolding fertig ist, spielt es diese Anleitung ins Projekt: Skills landen in .claude/skills/, Instructions in .github/instructions/. Es schreibt außerdem eine CLAUDE.md und eine .github/copilot-instructions.md mit Memory-Direktiven, plus Start-Memory-Indizes, die beide Agenten zu Beginn jeder Sitzung lesen.

Wenn du also das Projekt öffnest und Claude Code bittest, die Resource-Schicht anzufassen, muss er nicht erst herausfinden, wie OwlMeans-Resources funktionieren — der mongo-resource-Skill liegt direkt da. Wenn er eine Route hinzufügt, liegt der entrypoint-Skill direkt da. Es gibt sogar eine reuse-code-Regel, fest in der CLAUDE.md verankert, die dem Agenten sagt, er solle nach einem bestehenden @owlmeans/*-Paket suchen, bevor er sich eine eigene Lösung ausdenkt. Beim ersten Öffnen des Projekts fragt dich der Agent, wofür es ist, und schreibt deine Antwort in beide Kontextdateien, damit er nie wieder fragen muss.

Nichts davon hast du geschrieben. Du hast keine Verdrahtung verlegt. Die Skills, das Memory und die Konventionen kamen mit dem Befehl. Genau das bedeutet „selbsttragend, voll mit Skills ausgestattet“ in der Praxis — und es ist dieselbe Maschinerie, auf die sich unsere Plattform stützt, dir direkt in die Hand gegeben.

Schritt für Schritt: vom Scaffold zu einem echten Feature

Machen wir es konkret. Sagen wir, du willst den In-Memory-Store der Demo in ein echtes, persistentes Feature auf Basis von MongoDB verwandeln. Du öffnest nicht die Doku und fängst an, Treiber zu verdrahten. Du scaffoldest, dann fragst du.

Zuerst scaffolden und starten (jeder Manager funktioniert):

bun create @owlmeans/app my-app     # oder: npm create @owlmeans/app@latest my-app
cd my-app
bun run dev

Dann, in Claude Code (oder Copilot), starte mit einem Prompt wie diesem:

Füge ein persistentes Notizen-Feature auf Basis von MongoDB hinzu. Nutze @owlmeans/mongo und @owlmeans/mongo-resource statt der statischen In-Memory-Resource. Deklariere die Entrypoints und das Schema in sources/common, registriere die Resource und implementiere die Handler in sources/api, und füge in sources/web einen Screen hinzu. Verwende bestehende @owlmeans/*-Pakete wieder — halte dich an den reuse-code-Skill.

Dieser Prompt funktioniert ohne Händchenhalten, und es lohnt sich zu verstehen, warum. Das Projekt trägt die Skills für genau das schon in sich. Der Agent weiß, dass der Resource-Tausch eins zu eins ist, weil jede Resource dieselbe Schnittstelle implementiert — der Handler, der context.getStaticResource(...) machte, wird zu context.resource(...) über einer Mongo-Collection, und die create/list/delete-Aufrufe sind identisch:

const notes = context.resource<NotesResource>(RES_NOTES)
await notes.create({ id, text, createdAt })
const { items } = await notes.list({ criteria: { ... } })

Er weiß, dass das Entrypoint-Muster dasselbe bleibt — deklariere in common, elevate mit einem Handler in api, elevate mit einem Screen in web. Und er weiß, dass dein UI shadcn ist, das er direkt editieren kann. Weil die Struktur explizit ist und die Anleitung mit dem Repository mitreist, gibt der Agent seine Tokens dafür aus, dein Feature zu bauen, statt sich jede Sitzung das Framework neu beizubringen. Wenn du später deine @owlmeans/*-Pakete aktualisierst, führst du npx @owlmeans/agent-skills erneut aus, und die Anleitung frischt sich mit ihnen auf.

Warum das der Anfang ist, nicht das Ganze

Ich sage es klar, was das ist und was nicht.

create-app ist die Bibliothek und die Agenten-Anleitung, dir in die Hand gegeben, damit du sie selbst mit Claude Code oder Copilot steuerst. Sie ist wirklich mächtig, und für viele Projekte ist sie alles, was du brauchst. Die OwlMeans-Plattform — die vollständige Pipeline spezialisierter KI-Rollen, die User Storys in fertige, dir gehörende Software verwandelt — ist die Schicht obendrauf, und sie ist um genau diese Bibliothek herum gebaut. Genau deshalb kann sie zu einem Bruchteil der Kosten leisten, was sie leistet: Sie erkundet nicht jede Sitzung eine fremde Codebasis und zahlt nicht die Erkundungssteuer, sondern operiert auf einem Framework, das von Grund auf darauf ausgelegt ist, explizit, wiederholbar und billig zu durchdenken zu sein. Unser Ziel ist, dass die Plattform diese Projekte mit rund zehnmal weniger Tokens baut als ein ungezügelter Coding-Agent, der sich durch ein unbekanntes Repo quält.

Aber du musst nicht darauf warten. Das Fundament, auf dem die Plattform steht, ist heute schon auslieferbar, in einem Befehl, auf dem Agenten, für den du ohnehin schon bezahlst. Führe create-app aus, richte Claude Code darauf, und du bekommst einen echten Vorgeschmack auf die OwlMeans-Art zu bauen: typisiert, explizit, voll mit Skills ausgestattet und deins zum Behalten.

Das ist die Team-um-den-Agenten-Idee, klein genug gemacht, um genau jetzt in dein Terminal zu passen.