Quelle auf.

Quelle auf.

Ich stelle ChatGPT Fragen, bei denen ich selbst nicht weiß, ob meine Ausgangsannahme stimmt. Statt einer schnellen Antwort soll ChatGPT recherchieren, Quellen prüfen und offenlegen, worauf die Antwort beruht.

Warum ich diesmal frage: Ich habe einen Artikel über Spec-Driven Development gelesen und mich gefragt, ob es für Coding Agents inzwischen ein etabliertes „How to Spec“ gibt – nicht bloß einen besseren Prompt oder eine Repository-Anweisung, sondern ein Format für Anforderungen, Constraints, Verhalten, Schnittstellen, Akzeptanz und Verifikation.

Meine Frage: Existiert mit Stand heute eine etablierte, möglichst tool- und anbieterübergreifende Spezifikationssprache, ein Standard oder ein ausreichend formalisiertes Format, mit dem Softwareanforderungen für Coding Agents beschrieben werden können – vergleichbar mit OpenAPI für APIs?

Hier ist die Antwort von ChatGPT:

Gibt es ein OpenAPI für Coding Agents?

Die erste Datei, die ein Coding Agent in einem fremden Repository lesen sollte, ist selten die, die man ihm in den Chat kopiert hat. Es ist die Datei neben dem Code. Darin steht dann: so startest du die Tests, diese Tabelle bitte nicht anfassen, die Migration nur in dieser Reihenfolge, und wenn du unsicher bist, frag lieber einmal zu viel.

Lange sah das nach einer privaten Gewohnheit aus. Jede Agenten-Umgebung hatte ihren eigenen Zettel am Kühlschrank. Inzwischen hat dieser Zettel einen gemeinsamen Namen: AGENTS.md.

Die kurze Antwort auf die Frage nach einem OpenAPI für Coding Agents lautet deshalb: Ja, für Projektkontext und Arbeitsanweisungen gibt es mit AGENTS.md inzwischen einen weit verbreiteten, offenen gemeinsamen Nenner. Nein, für einen formalen, maschinenprüfbaren Vertrag über eine konkrete Softwareänderung gibt es noch kein direktes Pendant zu OpenAPI. Eine Anweisung steuert Arbeit; ein Vertrag beschreibt überprüfbar, was am Ende wahr sein muss.

Das ist weniger unbefriedigend, als es zunächst klingt. Es räumt nur mit einer Verwechslung auf.

Ein Agent braucht zuerst Orientierung, nicht gleich eine Ontologie

Die AGENTS.md-Initiative und ihr offizielles Projekt-Repository beschreiben die Datei als offenes Format, das Coding Agents projektbezogene Hinweise gibt. Ihre Beispiele sind erstaunlich unglamourös: Installations- und Testbefehle, Code-Stil, Sicherheitsregeln, Grenzen. Gerade deshalb funktionieren sie. Auch die Linux Foundation nennt AGENTS.md einen Gründungsbeitrag der Agentic AI Foundation und berichtet von mehr als 60.000 Open-Source-Projekten sowie Unterstützung durch zahlreiche Werkzeuge. [c-09, c-10]

AGENTS.md ist damit eine de-facto-Konvention mit institutioneller Einbettung, keine formale Sprache mit Pflichtfeldern oder Konformitätssuite.

Das ist ein echter Fortschritt. Ein Team muss seine wichtigste Arbeitsanweisung nicht mehr in CLAUDE.md, copilot-instructions.md und einem Chat-Absatz in drei Varianten pflegen. Ein Agent, der die Konvention versteht, findet einen vorhersehbaren Ort. Verschachtelte Dateien können dabei den Kontext eines Teilprojekts präzisieren.

Aber Markdown bleibt Markdown. Die Datei kann sagen: „Führe vor dem Commit pnpm test aus.“ Sie kann nicht aus sich heraus beweisen, welche Änderung fachlich geschuldet ist, ob eine Datenmigration vollständig ist oder ob zwei Agenten dieselbe Anforderung gleich auslegen. Sie liefert Kontext und Leitplanken; sie ist keine formale Spezifikation mit verbindlichem Datenmodell.

Der Unterschied klingt pedantisch, ist aber praktisch: Eine Anweisung steuert Arbeit. Ein Vertrag beschreibt überprüfbar, was am Ende wahr sein muss.

OpenAPI hat es leichter, weil sein Gegenstand klein ist

OpenAPI ist nicht deshalb so erfolgreich, weil YAML eine besonders erwachsene Textdatei wäre. Die OpenAPI Specification beschreibt einen eng umrissenen Gegenstand: eine sprachunabhängige Schnittstellenbeschreibung für HTTP-APIs. Endpunkte, Operationen, Nachrichten und Schemas liegen innerhalb eines klaren Rahmens. [c-01]

Das erlaubt Werkzeugen, aus derselben Beschreibung Server-Stubs, Clients, Dokumentation und Prüfungen abzuleiten. Die wichtige Leistung ist nicht das Dateiformat allein, sondern die gemeinsame Bedeutung seiner Felder.

Eine Anforderung an einen Coding Agent ist breiter. „Füge eine Freigabe für Rechnungen hinzu“ kann Rollen, UI, API, Datenhistorie, Benachrichtigungen, Rechte, Fehlermeldungen und das ausdrücklich Unveränderte meinen. Dazu kommt der Bestandscode: Welche Tabelle gibt es schon? Welche Bibliothek darf nicht ersetzt werden? Darf der Agent eine Migration ausführen oder nur vorbereiten? Das sind unterschiedliche Arten von Information – und sie werden heute selten in einem gemeinsamen Schema beschrieben.

Die Bauteile lagen schon vor dem Agenten auf dem Tisch

Es wäre trotzdem falsch, die Lage als leeres Feld zu erzählen. Das Requirements Engineering hat seit Langem brauchbare Teilverträge. Jedes der folgenden Formate löst einen Teil des Problems; keines löst es allein.

ReqIF 1.2 ist eine formale OMG-Spezifikation mit maschinenlesbaren normativen Dokumenten für den Austausch von Anforderungen. [c-02] Für Organisationen, die Anforderungen zwischen Werkzeugen und Firmen übergeben, ist das keine Fußnote, sondern die naheliegende Antwort. Es regelt jedoch nicht, wie ein Coding Agent den Bestandscode untersucht oder einen Diff sicher ausführt.

EARS hilft beim nächsten Stück: Eine Anforderung bekommt eine feste Satzstruktur aus Vorbedingungen, Auslöser, System und Reaktion. [c-03] Das zwingt einen Satz wie „Die App soll vernünftig reagieren“ in eine Form, über die man streiten und testen kann. Es löst aber noch nicht die Frage, welche Dateien dafür geändert werden müssen.

Gherkin übernimmt eher die Abnahme. Seine Szenarien sind ausführbare Spezifikationen, sobald ihre Schritte an projektspezifische Step Definitions gebunden sind. [c-04] Das ist sehr nützlich für „gegeben, wenn, dann“. Die Bindung an echten Code ist zugleich seine Grenze: Das Szenario sagt nicht vollständig, wie Architektur und Implementierung entstehen sollen.

Die neuen Formate liegen auf anderen Ebenen

Neben AGENTS.md entstehen weitere offene Formate. Die Agent-Skills-Spezifikation beschreibt einen wiederverwendbaren Skill als Verzeichnis mit SKILL.md, YAML-Metadaten und Markdown-Anweisungen. [c-11] Das standardisiert Fähigkeiten, nicht die Produktanforderung für eine einzelne Änderung.

Der IETF-Entwurf AAIF geht weiter in Richtung portabler Agenten-Definitionen: Ziele, Werkzeuge, Laufzeitpolitik und andere Eigenschaften sollen zwischen konformen Laufzeiten transportierbar werden. Der Entwurf sagt selbst klar, dass Internet-Drafts Arbeit im Werden sind. [c-12] Auch das ist nicht dasselbe wie ein Änderungsvertrag für ein konkretes Repository, aber es zeigt: Die Schichten beginnen, Namen zu bekommen.

Parallel bauen Werkzeuge eigene Arbeitsabläufe. Spec Kit führt von „Specify“ über Planung und Aufgaben bis zur Umsetzung; Kiro erzeugt requirements.md, design.md und tasks.md; OpenSpec ordnet Proposal, Specs, Design und Tasks in einem eigenen Schema. [c-05, c-06, c-07] Das sind hilfreiche Gerüste. Ihre Gemeinsamkeit ist bisher vor allem, dass sie Dateien neben den Code legen – nicht, dass ein anderes Werkzeug alle Bedeutungen verlässlich übernehmen könnte.

Die sinnvolle Zwischenlösung ist absichtlich mehrteilig

Meine eigene Synthese ist daher keine Forderung nach einer riesigen Superdatei. Sie ist ein praktischer Vorschlag, kein Standard:

Das ist nicht elegant im Sinne von „eine Datei, die alles löst“. Es ist aber ehrlich über die verschiedenen Fragen. Wer mit AGENTS.md beginnt, gewinnt bereits etwas Wesentliches: Der Agent weiß eher, wo er ist und was er nicht tun soll. Wer eine belastbare Änderung beauftragen will, braucht zusätzlich einen Vertrag über Verhalten und Nachweis.

Vielleicht entsteht daraus einmal ein formaler Standard. Im Moment wäre die vernünftigere Forderung kleiner: nicht den gemeinsamen Zettel mit dem Bauplan verwechseln – und beide so schreiben, dass ein Mensch ihn noch prüfen kann.