Readme Best Practices

Cursor-Regel für einheitliche, vollständige README-Dateien nach festen Qualitätskriterien.

Original-Beschreibung der Autoren: Cursor rules for README documentation with best practices integration.

Die Regel

---
description: "Cursor rules for README documentation with best practices integration."
globs: **/*
alwaysApply: false
---
Write READMEs like landing pages, not API docs. The reader decides in 3-5 seconds.

Start with a bold one-liner saying what it does and why someone should care. Not "A tool that..." - a punchline.
Put a working code example in the first 5 lines. Show the value prop immediately.
Use feature tables (two columns) instead of **Feature:** bullet lists. Tables scan faster.
Quick Start must be copy-paste ready. No $ prefix on bash commands. Zero to running in 30 seconds.
Vary sentence lengths and structure. Mix one-liners with short paragraphs and tables. Not walls of same-length bullets.
Never use "seamless", "robust", "comprehensive", "cutting-edge", or other AI marketing words.
Never open with "In today's..." or close with "Happy coding!"
Check that referenced assets (demo.gif, screenshots) actually exist on disk before adding image links.
Author section should include a visual card or badge, not just plain text "Made by username".

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Diese Cursor-Regel legt fest, wie Cursor README-Dateien schreibt oder überarbeitet: welche Abschnitte ein gutes README braucht (z. B. Installation, Nutzung, Beispiele), wie knapp und konkret der Ton sein soll und was vermieden werden sollte. Statt jedes Mal manuell zu erklären, was ins README soll, generiert Cursor mit dieser Regel im Hintergrund konsistente Dokumentation nach denselben Maßstäben. Lohnt sich vor allem für Teams oder Open-Source-Projekte mit vielen Repos, wo READMEs sonst unterschiedlich ausführlich und uneinheitlich ausfallen. Ersetzt keine inhaltliche Prüfung durch Menschen, sorgt aber für einen brauchbaren, einheitlichen Ausgangspunkt statt eines leeren oder generischen Templates.

Praxis-Tipp

In .cursor/rules/ ablegen und dann prompten: „Schreib ein README für dieses Projekt“ — Cursor übernimmt automatisch Struktur und Tonalität aus der Regel.

Siehe auch

• Anti Overengineering
• Anti Sycophancy Code Discipline

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …