AGENTS.md schreiben: Vorlage und Regeln für KI-Agenten

Praktische Materialien zu Vibe Coding und zur Arbeit mit Agenten: Ailoot-Dokumentation.

AGENTS.md in einem Absatz#

Im Folgenden wird das Format anhand von agents.md, der Dokumentation zu OpenAI Codex, JetBrains Junie, den Cursor Rules Docs, dem Changelog des GitHub Copilot Coding Agent und der Pressemitteilung der Linux Foundation zur Agentic AI Foundation erläutert. Alle Zahlen und Funktionen entsprechen dem Stand vom 30. Mai 2026. Die Unterstützung von AGENTS.md in Claude Code wird gemäß der Dokumentation von Anthropic beschrieben, ergänzt um ein Update vom 24. September 2026.

Wenn du keine Ahnung hast, was dieser Zoo von Tools auf dem Markt ist oder warum sie eine gemeinsame Datei brauchen, lies zuerst die Anleitung „Womit programmieren im Jahr 2026: 8 KI-Tools von Claude Code bis Antigravity“. Dieser Artikel konzentriert sich speziell auf das Format AGENTS.md und darauf, wie du in 30 Minuten deine eigene Datei schreibst.

Was ist AGENTS.md und woher kommt das Format?#

Früher hatte jedes KI-Tool eine eigene Regeldatei: Anthropic hatte CLAUDE.md, Cursor hatte .cursorrules, GitHub hatte .github/copilot-instructions.md, Aider hatte .aider.conf.yml und JetBrains hatte .junie/guidelines.md. Wenn dein Team drei verschiedene Agenten hatte, bedeutete das drei parallele Dateien mit denselben Inhalten, die innerhalb einer Woche auseinanderdrifteten.

OpenAI war als Erstes davon genervt. Im August 2025 veröffentlichte das Unternehmen Codex CLI und führte gleichzeitig agents.md als offenes Format ein. Auf der Website heißt es:

„Betrachte AGENTS.md als README für Agenten.“

(agents.md, aus dem Englischen übersetzt)

Diese Standardregel gilt für Clients, die diesen Such- und Vorrangmechanismus tatsächlich implementieren. Prüfe die installierte Version; bei ausdrücklich konfiguriertem Laden kann ein anderer Dateipfad gelten.

Der Kernpunkt ist, dass AGENTS.md das README ergänzt. README ist für Menschen geschrieben: „Was ist das Projekt, wie führe ich es lokal aus, wie kann ich dazu beitragen?“ AGENTS.md ist für den Agenten geschrieben: genaue Shell-Befehle, überprüfbare Kriterien für „fertig“ und Grenzen wie „das hier niemals anfassen“.

Auf der Website heißt es:

„AGENTS.md ergänzt README: Die Datei enthält zusätzlichen, manchmal detaillierten Kontext, den der Agent braucht – Build-Schritte, Tests und Konventionen, die README überladen würden oder für menschliche Mitwirkende schlicht nicht nötig sind.“

(agents.md, aus dem Englischen übersetzt)

Im September 2025 unterstützte der GitHub Copilot Coding Agent das Format (Changelog, 28.08.2025). Bis Dezember waren Cursor, Junie, Gemini CLI, Aider und ein Dutzend weitere Tools hinzugekommen. Am 9. Dezember 2025 gründete die Linux Foundation die Agentic AI Foundation (AAIF): Ihre drei Gründungsprojekte waren AGENTS.md von OpenAI, MCP von Anthropic und goose von Block. Zu den Gründungsmitgliedern gehörten AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft und OpenAI. Bis zum 24. Februar 2026 umfasste die Foundation bereits 146 Organisationen, darunter Red Hat, ServiceNow, Akamai, Lenovo, JPMorgan Chase, Huawei, UiPath und Hitachi.

Von da an war AGENTS.md nicht mehr „noch so ein Ding von OpenAI“, sondern wurde zum De-facto-Standard.

Welche KI-Agenten lesen AGENTS.md und welche nicht?#

Unterstützungstabelle mit Stand vom 30. Mai 2026; die Zeile zu Claude Code wurde am 24. September 2026 aktualisiert:

Anthropic stieß als Letzter der großen Anbieter dazu. Im August 2025 wurde im offiziellen Repository anthropics/claude-code das Issue #6235 eröffnet, das um Unterstützung für AGENTS.md bat.

Das Issue blieb fast ein Jahr offen und wurde am 17. August 2026 geschlossen; Version 2.1.277 mit AGENTS.md-Unterstützung erschien am 18. September. Die Logik von Anthropic ist folgende: CLAUDE.md hat Vorrang, und AGENTS.md wird gelesen, wenn sich weder im Arbeitsverzeichnis noch in einem übergeordneten Verzeichnis eine CLAUDE.md-Datei befindet. Laut der Dokumentation funktioniert es so:

Der Haken: Auch eine persönliche CLAUDE.local.md zählt, und dann hört Claude Code auf, AGENTS.md zu lesen. Dieses Verhalten kannst du unter Project instructions in /config ändern – zum Beispiel, damit Claude Code beide Dateien gleichzeitig liest. In Versionen vor 2.1.277 wird AGENTS.md nicht automatisch eingelesen; die Zeile @AGENTS.md in CLAUDE.md bleibt die Lösung.

Wie unterscheidet sich AGENTS.md von CLAUDE.md und .cursorrules?#

Vergleich der vier Formate mit Stand vom 30. Mai 2026:

Die zentrale Idee: AGENTS.md kann Regeln gemeinsam halten, wenn jeder Client richtig angebunden ist; persönliche, nicht eingecheckte Einstellungen bleiben eine separate Aufgabe. Claude Code hat dafür CLAUDE.local.md, Cursor hat lokale .mdc-Dateien unter User. AGENTS.md bietet diese Möglichkeit allein nicht – du musst es entweder mit anderen Dateien kombinieren oder dich im Team darauf einigen, persönliche Regeln in gitignorierten Abschnitten zu schreiben.

Ein weiteres wichtiges Detail sind Monorepos. Codex und Cursor setzen die Regel „die nächstgelegene AGENTS.md gewinnt“ um:

„Lege in einem Monorepo eine separate AGENTS.md in jedes Paket. Agenten lesen automatisch die nächstgelegene Datei im Verzeichnisbaum, und die nächstgelegene gewinnt.“

(agents.md, aus dem Englischen übersetzt)

agents.md erwähnt, dass OpenAIs Haupt-Monorepo 88 AGENTS.md-Dateien für verschiedene Unterpakete enthält. Wenn du in einem Monorepo arbeitest, verteile die Regeln auf mehrere Ebenen: allgemeine Regeln ins Stammverzeichnis, spezifische in die Unterordner.

Was sollte eine gute AGENTS.md enthalten?#

Die Website agents.md bietet ein flexibles Format – „beliebiges Markdown“. Doch 80 % der guten Dateien da draußen enthalten dieselben acht Abschnitte. Die Hauptregel: Jeder Punkt sollte ein genauer Befehl oder ein konkretes Beispiel sein. Eine abstrakte Aussage wie „schreibe sauberen Code“ wird der Agent ignorieren.

1. Projektübersicht – 2–3 Zeilen. Was ist das Projekt, für wen ist es und was ist sein Hauptziel? Keine Werbung. Beispiel: „Telegram-Bot für das Onboarding in einen kostenpflichtigen Workshop. Stack: Next.js 14, Prisma, PostgreSQL. Wird durch einen neuen Eintrag in purchases ausgelöst.“
2. Einrichtungsbefehle – genaue Shell-Befehle für die lokale Ausführung. npm install, npm run dev, npm run build. Kein „so machen wir das normalerweise“.
3. Codestil / Konventionen – konkrete Regeln mit einem Beispiel, nicht „schreibe sauber“. Zum Beispiel: „TypeScript strict, einfache Anführungszeichen, keine Default-Exports, Komponentennamen in PascalCase, Hooks beginnen mit use.“
4. Tipps zur Entwicklungsumgebung – wo wichtige Dinge liegen. Welche Variablen in .env benötigt werden, wo Geheimnisse gespeichert sind, welche Ports verwendet werden und wie mit der lokalen DB gearbeitet wird.
5. Testanweisungen – wie ein bestimmter Test ausgeführt wird und was als „grün“ gilt. Zum Beispiel: npm test -- --testPathPattern=user-auth; es wird erwartet, dass 100 % bestehen.
6. PR- / Commit-Richtlinien – Format der Commit-Nachricht, Checkliste vor dem PR (Tests, Linter, Dokumentation) und wer genehmigt.
7. Sicherheitsaspekte – was niemals geschehen darf. „Commite .env niemals. Geheimnisse gehören ausschließlich in Vault. Gib in Logs keine persönlichen Daten von Benutzern aus.“
8. Grenzen / Das niemals tun – Verbote mit einer Alternative. „Verwende auf main nicht git push --force. Wenn du zurücksetzen musst, verwende git revert oder git reset auf einem Feature-Branch.“

Wende für jeden Abschnitt das Prinzip „Befehl statt Idee“ an. Der Agent wird „Sei vorsichtig mit Migrationen“ ignorieren. Er wird sich an „Führe vor alembic upgrade head alembic check aus. Wenn ein Fehler gemeldet wird, wende die Migration nicht an, sondern frag mich“ halten.

Fertige AGENTS.md-Vorlage zum Kopieren und Anpassen#

# AGENTS.md

## Project overview

<project-name> - <one phrase describing its purpose>.
Stack: <Next.js / Python / Go / ...>.
Main entities: <users, orders, posts ...>.
Details for people are in README.md.

## Setup commands

```bash
# first install
npm install
cp .env.example .env  # then fill in manually; see list below

# run
npm run dev           # dev server on :3000
npm run build         # production build
npm run start         # run production build
```

## Dev environment

- Node 20+ (via nvm: `nvm use 20`)
- PostgreSQL 16 locally on :5432 (`docker-compose up postgres`)
- Redis is optional, needed only for queues (`docker-compose up redis`)
- `.env`: `DATABASE_URL`, `STRIPE_KEY`, `RESEND_API_KEY`, `JWT_SECRET`
- Never read the entire `.env` file. If you need one variable: `grep "^VAR=" .env`

## Code style

- TypeScript strict mode
- Single quotes, no semicolons (unless ESLint requires them)
- Imports: external first, then internal via `@/`, then relative
- Components in PascalCase; hooks start with `use`
- No `any` without an explicit comment explaining “why it can’t be typed”

Example of a good module:

```ts
import { z } from 'zod'

const UserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(2),
})

export function parseUser(raw: unknown) {
  return UserSchema.parse(raw)
}
```

## Testing

```bash
npm test                                # all tests
npm test -- --testPathPattern=auth      # auth only
npm test -- --watch                     # watch mode
```

All tests must pass (be green) before committing. If a test is red, don’t commit; ask me what to do.

## Pull request guidelines

- Commit format: `<type>(<scope>): <description>` (`feat(auth): add magic-link`)
- Before PR: `npm run build && npm test && npm run lint`
- PR description = what changes, why, and how to test
- Don’t approve your own PR—always wait for human review

## Security

- Secrets only in `.env` and Vault, never in code
- Don’t log personal data (email, phone, name)
- When working with the production DB, use read-only queries only unless explicitly authorized
- Don’t hardcode external service API keys (Stripe, OpenAI) in tests

## Never do this

- Don’t `git push --force` to main. If you need to roll back, use `git revert` or open a new PR
- Don’t run DB migrations without `alembic check` (or the equivalent in your ORM)
- Don’t use `npm install -g` or `sudo` for project dependencies
- Don’t add dependencies without approval (especially heavy ones: webpack plugins, ORM)

Im Durchschnitt umfasst die Vorlage 80–120 Zeilen. Wenn die Datei mehr als 150 Zeilen hat, ist das ein Zeichen dafür, dass du sie überarbeiten solltest: Verschiebe etwas nach docs/, verlinke darauf oder fasse etwas in einer Zeile zusammen. In der Praxis funktionieren Dateien mit 100–150 Zeilen am besten; ab diesem Punkt beginnen die Qualitätsgewinne wieder abzunehmen.

Welche 5 Regeln machen AGENTS.md wirklich nützlich?#

1. Befehle statt Ideen. Ein Agent versteht „Sei vorsichtig mit Migrationen“ nicht. Er wird alembic check vor alembic upgrade head ausführen. Agenten arbeiten mit Befehlen und Bedingungen, nicht mit Stimmungen. Formuliere alle wichtigen Regeln als „Mach X, andernfalls Y“.

2. Verbote mit einer Alternative. Ein bloßes „nicht mit Force pushen“ wird vom Agenten nach zwei oder drei Prompts stillschweigend ignoriert. Die Kombination „Tu X nicht, sondern mach stattdessen Y“ funktioniert. Beispiel: „Verwende auf main nicht git push --force; wenn du zurücksetzen musst, verwende git revert oder öffne einen neuen PR.“

3. Genau eine Quelle der Wahrheit. Die AGENTS.md im Stammverzeichnis ist die maßgebliche Quelle für das ganze Projekt. In einem Monorepo verwendest du verschachtelte AGENTS.md-Dateien in Unterordnern und hältst dich an die Regel „die nächstgelegene gewinnt“. Keine parallelen Dateien mit widersprüchlichen Anweisungen.

4. Überprüfbare Kriterien für „fertig“. „Tests müssen bestehen“ ist nutzlos. Ein genaues Kriterium lautet: npm test gibt Exit-Code 0 zurück und schreibt kein FAIL in stdout. „Der Code sollte sauber sein“ ist ebenfalls nutzlos. Ein genaues Kriterium lautet: npm run lint läuft ohne Warnungen durch. Ein Agent versteht erst dann, was „fertig“ bedeutet, wenn du die Bedingung ausdrücklich beschreibst.

5. Eine Datei mit weniger als 150 Zeilen. Jenseits von 150 Zeilen verschlechtern sich die Metriken: Der Agent verbraucht mehr Kontext beim Lesen und übersieht wichtige Regeln. Wenn alles nicht hineinpasst, verschiebe Details nach docs/architecture.md und verlinke sie in AGENTS.md; in der Datei bleiben nur Befehle und Grenzen.

Welche 10 Fehler machen AGENTS.md zum Müll?#

1. Vage Regeln ohne Befehle. Der Agent ignoriert „Sei vorsichtig mit Migrationen“ – dieser Satz ist für ihn inhaltsleer. Nur ein konkreter Befehl mit einer Bedingung funktioniert: „Führe vor alembic upgrade head alembic check aus. Wenn ein Fehler vorliegt, wende die Migration nicht an, sondern frag mich.“

2. „Sauberer Code.“ Eine nutzlose Formulierung. Ersetze sie durch ein konkretes Muster: „Verwende funktionale Komponenten mit Hooks. Beispiel: function LoginForm() { const [email, setEmail] = useState(''); ... }“

3. Unstrukturierter Fließtext. Wenn AGENTS.md aus 300 Zeilen Fließtext ohne Überschriften besteht, verbraucht der Agent 80K Kontext-Tokens mit irrelevanten Passagen und übersieht Wichtiges. Verwende H2/H3-Überschriften, kurze Abschnitte und Aufzählungen.

4. Eine Datei mit mehr als 150 Zeilen. Oberhalb dieser Schwelle verschlechtern sich die Qualitätsmetriken. Teile den Inhalt auf eine Hauptdatei und Links zu Details in docs/ auf.

5. Mehr als 30 Verbote ohne Alternativen. Wenn die Datei eine lange Liste mit „Tu nicht X, tu nicht Y“ enthält, ohne zu erklären „Mach stattdessen Z“, tappt der Agent im Dunkeln.

6. README.md duplizieren. Wenn du „wie installieren und ausführen“ bereits in README beschrieben hast, kopiere es nicht in AGENTS.md. Verweise stattdessen mit einer Zeile auf README und beschreibe in AGENTS.md, was der Agent braucht, menschliche Mitwirkende aber nicht.

7. Geheimnisse fest eintragen. AGENTS.md kann öffentlich sein, weil die Datei in Git liegt. Keine echten API-Schlüssel, Tokens oder Passwörter. Verweise nur auf Speicherorte für Geheimnisse: „Siehe Vault: secret/staging/db.“

8. Widersprüchliche Prioritäten ohne Rangfolge. „Schnell vorankommen“ + „90 % Testabdeckung halten“ lässt den Agenten unsicher zurück, wofür er sich entscheiden soll. Lege die Rangfolge ausdrücklich fest: „Zuerst Testabdeckung ≥80 %, dann Geschwindigkeit. Bei einem Konflikt haben Tests Vorrang.“

9. Veraltete Dokumentation. Eine Architekturbeschreibung, die REST+Polling angibt, obwohl tatsächlich schon WebSockets verwendet werden. Der Agent folgt der veralteten Beschreibung und beschädigt die Architektur. Regel: Aktualisiere AGENTS.md im selben PR wie den Code, wenn sich die Architektur ändert.

10. Architektonischer Overkill für eine einfache Aufgabe. Wenn jemand um eine Änderung von zwei Zeilen in einer Konfiguration bittet, sollte der Agent nicht die gesamte Topologie von 14 Microservices lesen müssen. Verschiebe die „tiefe“ Architektur nach docs/architecture.md; lasse in AGENTS.md nur „Wenn die Aufgabe die Architektur betrifft, lies docs/architecture.md.“

Die Studie des GitHub Blog zu mehr als 2.500 AGENTS.md-Repositories nennt die wichtigste Schlussfolgerung:

„Die meisten Agent-Dateien scheitern, weil sie zu allgemein sind. ‚Du bist ein hilfreicher Programmierassistent‘ funktioniert nicht.“

(GitHub Blog, aus dem Englischen übersetzt)

Wie verwaltet man AGENTS.md und CLAUDE.md in einem Repository?#

Die wichtigste praktische Frage lautet, wie man mit beiden Dateien arbeiten kann, ohne Inhalte zu duplizieren. Es gibt drei Szenarien:

Szenario 1: Nur Claude Code. Behalte CLAUDE.md und nutze alle Funktionen von Claude Code: ~/.claude/CLAUDE.md für Anweisungen auf Benutzerebene, CLAUDE.md für das Projekt, CLAUDE.local.md für persönliche Anpassungen, @import zum Einbinden anderer Dateien und .claude/skills/ für spezialisierte Skills. AGENTS.md ist nicht nötig.

Szenario 2: Mehrere Programmierclients. Halte gemeinsame Regeln in AGENTS.md und binde jeden Client einzeln ein. Gemini CLI unterstützt einen konfigurierten Kontextdateinamen; Aider kann eine Datei über seine Lesekonfiguration laden. Das sind ausdrückliche Ladewege, keine identische automatische Erkennung.

Beginne eine frische Sitzung in einem ungefährlichen Test-Repository. Füge eine eindeutige harmlose Anweisung hinzu, etwa „Nenne im Test die Markierung instructions-loaded“, und prüfe neben der Antwort auch die dokumentierte Anzeige geladener Dateien oder die Protokolle des Clients. Wiederhole das für jeden tatsächlich verwendeten Client und jede Version. Die Behauptung des Modells, es habe die Datei gelesen, ist kein unabhängiger Nachweis; eine erfolgreiche Prüfung belegt nicht die Unterstützung aller anderen Tools.

Szenario 3: Ein gemischtes Team (Claude Code + andere). Das ist 2026 die häufigste Konfiguration. Die Lösung: AGENTS.md zur Hauptdatei machen. Wenn du keine Regeln speziell für Claude Code hast, lege gar keine CLAUDE.md an: Seit Version 2.1.277 liest Claude Code AGENTS.md, wenn sich im Projekt keine CLAUDE.md befindet. Wenn du solche Regeln hast, kannst du CLAUDE.md entweder als Symlink oder als kurzen Wrapper mit einem @AGENTS.md-Import anlegen.

Prüfe und sichere vor Änderungen beide Dateien. Sind beide vorhanden, vereine widerspruchsfreie gemeinsame Anweisungen in AGENTS.md und behalte Claude-spezifische Regeln in CLAUDE.md mit einem @AGENTS.md-Import. Bewahre vorhandene Symlinks, statt sie zu ersetzen.

Für eine reguläre CLAUDE.md nur bei fehlender AGENTS.md verhindert diese macOS/Linux-Prüfung das Überschreiben vorhandener Ziele und Symlinks:

if [ -e AGENTS.md ] || [ -L AGENTS.md ]; then
  printf '%s\n' 'STOP: AGENTS.md exists; merge both files first.' >&2
elif [ -f CLAUDE.md ] && [ ! -L CLAUDE.md ]; then
  mv CLAUDE.md AGENTS.md && ln -s AGENTS.md CLAUDE.md
else
  printf '%s\n' 'STOP: inspect the existing CLAUDE.md path first.' >&2
fi

Nach erfolgreicher Umbenennung ist CLAUDE.md ein Symlink auf AGENTS.md. Alle Agenten, die AGENTS.md lesen, sehen denselben Inhalt. Claude Code, das CLAUDE.md liest, sieht über den Symlink denselben Inhalt.

Unter Windows erfordert das Erstellen eines Symlinks den Entwicklermodus (oder Administratorrechte), was für das ganze Team möglicherweise unpraktisch ist. Eine Alternative ist eine kurze CLAUDE.md, die AGENTS.md einbindet:

# CLAUDE.md

@AGENTS.md

## Claude Code specific

- Use .claude/skills/ for specialized prompts
- When working with Skills, consult .claude/skills/INDEX.md
- Use Plan Mode before major changes (Shift+Tab)

In Claude Code bindet diese Syntax AGENTS.md mit einer Zeile ein und ergänzt darunter Claude-Code-spezifische Zusätze. Wenn du AGENTS.md später entfernen willst, löschst du einfach den Import. Diese Zeile führt nicht zu doppeltem Einlesen: Laut Claude-Code-Dokumentation wird dieselbe AGENTS.md nicht zweimal geladen, selbst wenn sie automatisch eingelesen werden könnte.

Kanonischer Aufbau für ein Team mit mehreren Tools im Jahr 2026:

repo-root/
├── AGENTS.md                              # maßgebliche Quelle, ≤150 Zeilen
├── CLAUDE.md                              # nur bei Claude-spezifischen Regeln: Symlink → AGENTS.md ODER @AGENTS.md + Ergänzungen
├── .cursor/rules/                         # gezielte Überschreibungen nur für Cursor
├── .github/copilot-instructions.md        # „Siehe AGENTS.md“, falls verwendet
└── docs/architecture.md                   # ausführliche Architektur, auf die AGENTS.md verweist

Mehr über CLAUDE.md erfährst du in der Anleitung „CLAUDE.md richtig konfigurieren“. Warum ein Agent eine große Anweisungsdatei braucht, erfährst du unter „Was ist Context Engineering?“.

Was änderte sich 2026: Warum stellte die AAIF AGENTS.md unter das Dach der Linux Foundation?#

Die wichtigste politische Geschichte im KI-gestützten Programmieren im Mai 2026 war nicht die Veröffentlichung eines weiteren Modells, sondern die Zusammenführung der Formate. Zuvor hatte jeder Anbieter eine eigene Regeldatei, was für die Anbieter praktisch, für Teams mit mehreren Tools aber mühsam war.

In einer Pressemitteilung vom 9. Dezember 2025 kündigte die Linux Foundation die Agentic AI Foundation als Dachorganisation für drei Formate an:

• AGENTS.md von OpenAI – ein Format für Anweisungsdateien für Agenten
• Model Context Protocol (MCP) von Anthropic – ein Protokoll, um externe Tools mit Agenten zu verbinden
• goose von Block – ein Open-Source-Agent-Framework

Aus der Pressemitteilung der Linux Foundation:

„Indem diese Projekte unter dem Dach der AAIF zusammengeführt werden, können sie sich mit der Transparenz und Stabilität weiterentwickeln, die nur offene Governance bietet.“

(Pressemitteilung der Linux Foundation, 9. Dezember 2025, aus dem Englischen übersetzt)

Bis zum 24. Februar 2026 gehörten der AAIF 146 Organisationen an (97 neue Mitglieder in zwei Monaten). Zu den neuen Gold-Mitgliedern gehörten Red Hat, ServiceNow, Akamai, Lenovo, JPMorgan Chase, Huawei, Hitachi, UiPath, American Express und Autodesk. Anthropic ist auf Platin-Niveau und fördert MCP. OpenAI ist auf Platin-Niveau und fördert AGENTS.md. Block ist mit goose auf Platin-Niveau.

Dadurch ändert sich die Positionierung von AGENTS.md: vom „OpenAI-Format“ zum Branchenstandard. Im Frühjahr 2026 stand Claude Code noch abseits; im September lernte es mit Version 2.1.277, AGENTS.md selbstständig zu lesen. CLAUDE.md ist nicht verschwunden und hat standardmäßig weiterhin Vorrang, wenn die Datei im Projekt liegt.

Ein praktischer Ausgangspunkt sind gemeinsame Projektregeln in AGENTS.md und der Import, Wrapper oder ausdrücklich konfigurierte Lesepfad, den jeder verwendete Client benötigt. Prüfe bei Claude Code installierte Version und Dateivorrang, bevor du über CLAUDE.md-Import oder Symlink entscheidest. Verifiziere das Laden in jedem Client; diese Anleitung belegt keine Abdeckungsquote.

Wie geht es weiter?#

AGENTS.md ist der erste Baustein dafür, „wie man sich mit einem Agenten abstimmt, damit er vorhersehbar funktioniert“. Als Nächstes kommt der zweite Baustein – ein Wissensordner des Projekts, der Geschäftskontext, Zielgruppe, Produkte und Preise enthält. Der dritte Baustein ist Context Engineering, das alles zusammenführt: welche Dateien der Agent in jedem Schritt sieht, wie der Zustand zwischen Sitzungen erhalten bleibt und wie zwischen verschiedenen Modellen gewechselt wird.

Praktische Materialien: Ailoot-Dokumentation.

Weitere Materialien und Tools: Ailoot.