aelena/llms-txt

Was macht llms-txt?

Erstelle eine hochwertige llms.txt-Datei im Stammverzeichnis eines Repositorys, die dem vorgeschlagenen Standard von llmstxt.org folgt. Die Datei ist ein kuratierter, maschinenlesbarer Index des Projekts – eine „Inhaltsangabe für LLMs“ – die bequem in das Kontextfenster eines Modells passt.

Warum dies existiert

LLMs, die ein Repository blind lesen, müssen raten, was wichtig ist. Mit llms.txt kann ein Projekt ihnen sagen: Hier ist das Projekt, hier die Zusammenfassung, hier die kanonischen Dokumentationen in Prioritätsreihenfolge, hier die sekundären Ressourcen, die du bei knappem Kontext überspringen kannst. Es ist robots.txt für das Modellzeitalter – nur dass es dem Modell hilft, seine Arbeit besser zu erledigen, nicht schlechter.

Aufruf

Auslöser	Verhalten
/llms-txt oder /llms-txt-gen	Erzeuge llms.txt im Repository-Stammverzeichnis
/llms-txt full	Erzeuge zusätzlich llms-full.txt (zusammenhängende vollständige Dokumentation, ohne Kürzung)
/llms-txt validate	Validiere eine vorhandene llms.txt gegen die Spezifikation
/llms-txt update	Aktualisiere eine vorhandene llms.txt mit dem aktuellen Repository-Zustand, unter Beibehaltung manueller Bearbeitungen
Natürliche Sprache: „erzeuge eine llms.txt”, „mache dieses Repository LLM-freundlich“, „generiere den llm-Index“	Gleich

Stoppen / Deaktivieren

Nicht wirklich anwendbar – dies ist ein einmaliger Generator, kein Sitzungsmodus. Rufe es einfach nicht auf.

Ausführungsablauf

1. Kandidaten entdecken. Führe scripts/discover.sh aus, um Folgendes aufzulisten:

   • Projektmetadatendateien: README*, package.json, pyproject.toml, Cargo.toml, Gemfile, go.mod usw.
   • Markdown auf Stammebene: README.md, CHANGELOG.md, CONTRIBUTING.md, LICENSE, ARCHITECTURE.md usw.
   • Inhalte des docs/-Verzeichnisses (.md, .mdx, .rst)
   • Andere Markdown-Dateien in Tiefe 2–3 (außer node_modules, .git, vendor)

2. Lesen und zusammenfassen. Lese die README und die primäre Metadatendatei. Extrahiere:

   • Projektname (aus package.json:name, pyproject.toml:[project].name oder README H1)
   • Zusammenfassung in einem Satz (aus dem ersten Absatz der README oder package.json:description)
   • Längerer Kontext (1–2 Absätze aus der README-Einleitung, ohne Überschriften)

3. Kategorisiere Kandidaten in H2-Abschnitte. Sinnvolle Standardwerte:

   • Docs – primäre benutzerorientierte Dokumentation
   • Examples – Beispielcode, Tutorials, Schnellstarts
   • API Reference – generierte oder handgeschriebene API-Dokumentation
   • Optional – sekundäre Ressourcen (CHANGELOG, Beitragsleitfäden, RFCs, interne Notizen)

   Der Abschnitt ## Optional hat in der Spezifikation eine besondere Bedeutung: LLMs mit knappem Kontextbudget sollten ihn überspringen. Füge alles Nicht-Wesentliche dort ein.

4. Generiere llms.txt nach dem Format in format.md. Strenge Struktur:

   # Projektname
   
   > Zusammenfassung in einem Satz in einem Blockzitat.
   
   Optionaler Kontext von 1–2 Absätzen, ohne Überschriften.
   
   ## Abschnitt
   - [Titel](relativer-oder-absoluter-url): einzeilige Beschreibung
   - [Titel](url): Beschreibung
   
   ## Optional
   - [Titel](url): Beschreibung
   

5. Validiere mit scripts/validate.sh. Bei Fehlern korrigieren und erneut validieren.

6. Vorschau der generierten Datei dem Benutzer anzeigen, bevor sie geschrieben wird. Bestätigung einholen.

7. Schreibe nach ./llms.txt. Wenn bereits eine Datei existiert, Diff dagegen erstellen und vor dem Überschreiben um Bestätigung bitten – erhalte manuelle Abschnitte, die der Benutzer hinzugefügt hat.

8. Optionale llms-full.txt (nur wenn das Argument full übergeben wurde): verketten den vollständigen Inhalt jedes verlinkten Dokuments in eine einzelne Datei, mit # File: <pfad>-Überschriften dazwischen. Dies ist die „gib mir alles“-Variante.

Sicherheitsvorkehrungen

• Vorhandene llms.txt niemals ohne Vorschau + Bestätigung überschreiben. Sie kann manuelle Kuratierung enthalten.
• Niemals Geheimnisse in die generierte Datei aufnehmen. Überspringe jede Kandidatendatei, die auf .env*, *.pem, *key*, credentials*, *.secret passt. Den Benutzer warnen, falls gefunden.
• Niemals auf private Pfade verlinken (alles innerhalb von .git/, node_modules/, vendor/, target/, build/, dist/).
• Keine URLs erfinden. Alle Links müssen auf reale Dateien im Repository verweisen (relative Pfade) oder auf URLs, die explizit in der README vorhanden sind. Die Startseite des Projekts nicht erraten.
• .gitignore respektieren. Wenn eine Kandidatendatei gitignoriert wird, nicht indizieren.

Stilregeln für die generierte Datei

• H1 ist der Projektname, nichts anderes. Kein Slogan, kein Untertitel.
• Blockzitat-Zusammenfassung ist ein Satz, Präsens, sachlich. Keine Marketing-Sprache.
• Beschreibungen bei Link-Elementen sind einzeilig, maximal ~12 Wörter. Sage dem LLM, warum diese Datei wichtig ist, nicht wortwörtlich, was darin steht.
• Reihenfolge innerhalb eines Abschnitts wichtig – das Wichtigste zuerst. Das Modell hört möglicherweise mitten drin auf zu lesen.
• Keine Emojis, keine dekorative Markdown-Syntax, keine verschachtelten Listen. Das Format ist bewusst flach gehalten.
• Relative Pfade bevorzugen für Dateien im Repository (docs/getting-started.md), absolute URLs nur für externe Ressourcen.

Dateien in diesem Skill

• SKILL.md – diese Datei
• format.md – die Formatreferenz von llmstxt.org, destilliert
• scripts/discover.sh – Kandidatendateien für die Indizierung auflisten
• scripts/validate.sh – eine generierte llms.txt gegen grundlegende Spezifikationen prüfen