Repo-Doku: Dokumentation im Quell-Repo erstellen
Zweck
Dieser Skill erzeugt oder aktualisiert die Dokumentation direkt im Quell-Repo — als
Source of Truth, aus der nachgelagerte Doku-Systeme (Doku-Portal, Website) sie übernehmen können.
Geschrieben wird in die README.md, bei größeren Projekten zusätzlich in eine DEVELOPMENT.md.
- Output bleibt im Repo:
README.md immer; DEVELOPMENT.md nur bei größeren Projekten.
- Kein Auto-Commit: Niemals selbstständig committen oder pushen — nur einen Conventional-Commit
vorschlagen.
Workflow
1. Doku-Ziel bestimmen
- Projekt-Typ und Umfang einschätzen (Bibliothek/Client, größere Anwendung, CLI, …).
- Doku-Ziel festlegen: nur
README.md oder README.md + DEVELOPMENT.md.
- → Details in references/doku-ziel.md.
2. Letzten Doku-Stand finden (Git)
Den Punkt finden, bis zu dem zuletzt dokumentiert wurde, um nur die Lücke zu schließen:
git log -1 --format='%H %ci' -- README.md # letzte Änderung am README
git log --oneline <letzter-stand>..HEAD # Commits seitdem
- Conventional Commits nach Typ gruppieren (
feat, fix, BREAKING CHANGE …).
feat/BREAKING CHANGE sind dokumentationsrelevant, reine chore/ci/test meist nicht.
3. Quellen sammeln (in dieser Reihenfolge)
- Vorhandene Doku (
README.md, ggf. DEVELOPMENT.md) als Ausgangsbasis — fortschreiben,
nicht von Null neu schreiben.
- Changelog-Dateien als strukturierte Quelle für Neuerungen (auf die exakte Schreibweise im
Repo achten, z.B.
Changelog.md vs. CHANGELOG.md).
- Git-Commits seit letztem Stand (Schritt 2) für Änderungen ohne Changelog-Eintrag.
- Quellcode für die Details: öffentliche API, Optionen, Signaturen, realistische Beispiele.
4. Doku schreiben/aktualisieren
- Konventionen einhalten → references/konventionen.md
(Sprache, Code/Kommentar-Sprache, Changelog, Diagramme, projekt-spezifische Regeln).
- Minimal-invasiv: nur ergänzen/korrigieren, was die neuen Commits/Features betreffen.
- Beispiele aus echtem Code ableiten, keine erfundenen APIs.
5. Abschluss
Wenn Doku geändert wurde:
- Aufgaben in einer Aufgabenliste nachverfolgen (z.B.
todos/<thema>/todo.md), falls im Projekt üblich.
- Conventional-Commit vorschlagen (z.B.
docs: README um Feature X ergänzen),
aber nicht selbst committen.
- Kurze Zusammenfassung der Änderungen geben.
"Kein Gap" ist ein gültiges Endergebnis. Wenn die Auswertung zeigt, dass die vorhandene Doku
bereits aktuell und vollständig ist (z.B. nur interne Bugfixes/Tests/Releases seit dem letzten
Stand), dann keine Änderung erzwingen: keine erfundenen Inhalte, keine Aufgabenliste, kein
Commit-Vorschlag. Stattdessen die ausgewerteten Quellen und den Befund kurz berichten — inklusive
ggf. einzelner Grenzfälle, deren Bewertung der Benutzer entscheidet.
Referenzen
- references/doku-ziel.md — Doku-Ziel wählen (README vs. README+DEVELOPMENT),
Umfang und was rein- bzw. nicht reingehört.
- references/konventionen.md — Schreib-, Changelog- und Diagramm-Regeln
sowie projekt-spezifische Konventionen.
1---2name: repo-doku3description: Erstellt oder aktualisiert die Dokumentation (in der Regel README.md, bei größeren Projekten zusätzlich DEVELOPMENT.md) direkt im Quell-Repo — als Source of Truth. Quellen sind die vorhandene Doku, Changelog-Dateien, Git-Commits seit dem letzten Doku-Stand und der Quellcode. Nutze diesen Skill, wenn der Benutzer in einem Repo die Doku schreiben, das README aktualisieren, neue Features/Änderungen dokumentieren oder die Doku auf Stand bringen möchte. Trigger-Begriffe: Doku erstellen, README aktualisieren, dokumentieren, Doku auf Stand bringen, Changelog dokumentieren.4---56# Repo-Doku: Dokumentation im Quell-Repo erstellen78## Zweck910Dieser Skill erzeugt oder aktualisiert die Dokumentation **direkt im Quell-Repo** — als11**Source of Truth**, aus der nachgelagerte Doku-Systeme (Doku-Portal, Website) sie übernehmen können.12Geschrieben wird in die `README.md`, bei größeren Projekten zusätzlich in eine `DEVELOPMENT.md`.1314- **Output bleibt im Repo**: `README.md` immer; `DEVELOPMENT.md` nur bei größeren Projekten.15- **Kein Auto-Commit**: Niemals selbstständig committen oder pushen — nur einen Conventional-Commit16 vorschlagen.1718## Workflow1920### 1. Doku-Ziel bestimmen21- Projekt-Typ und Umfang einschätzen (Bibliothek/Client, größere Anwendung, CLI, …).22- Doku-Ziel festlegen: nur `README.md` oder `README.md` + `DEVELOPMENT.md`.23- → Details in [references/doku-ziel.md](references/doku-ziel.md).2425### 2. Letzten Doku-Stand finden (Git)26Den Punkt finden, bis zu dem zuletzt dokumentiert wurde, um nur die Lücke zu schließen:27```bash28git log -1 --format='%H %ci' -- README.md # letzte Änderung am README29git log --oneline <letzter-stand>..HEAD # Commits seitdem30```31- Conventional Commits nach Typ gruppieren (`feat`, `fix`, `BREAKING CHANGE` …).32- `feat`/`BREAKING CHANGE` sind dokumentationsrelevant, reine `chore`/`ci`/`test` meist nicht.3334### 3. Quellen sammeln (in dieser Reihenfolge)351. **Vorhandene Doku** (`README.md`, ggf. `DEVELOPMENT.md`) als Ausgangsbasis — fortschreiben,36 nicht von Null neu schreiben.372. **Changelog-Dateien** als strukturierte Quelle für Neuerungen (auf die exakte Schreibweise im38 Repo achten, z.B. `Changelog.md` vs. `CHANGELOG.md`).393. **Git-Commits** seit letztem Stand (Schritt 2) für Änderungen ohne Changelog-Eintrag.404. **Quellcode** für die Details: öffentliche API, Optionen, Signaturen, realistische Beispiele.4142### 4. Doku schreiben/aktualisieren43- Konventionen einhalten → [references/konventionen.md](references/konventionen.md)44 (Sprache, Code/Kommentar-Sprache, Changelog, Diagramme, projekt-spezifische Regeln).45- Minimal-invasiv: nur ergänzen/korrigieren, was die neuen Commits/Features betreffen.46- Beispiele aus echtem Code ableiten, **keine erfundenen APIs**.4748### 5. Abschluss49Wenn Doku geändert wurde:50- Aufgaben in einer Aufgabenliste nachverfolgen (z.B. `todos/<thema>/todo.md`), falls im Projekt üblich.51- **Conventional-Commit vorschlagen** (z.B. `docs: README um Feature X ergänzen`),52 aber nicht selbst committen.53- Kurze Zusammenfassung der Änderungen geben.5455**"Kein Gap" ist ein gültiges Endergebnis.** Wenn die Auswertung zeigt, dass die vorhandene Doku56bereits aktuell und vollständig ist (z.B. nur interne Bugfixes/Tests/Releases seit dem letzten57Stand), dann **keine Änderung erzwingen**: keine erfundenen Inhalte, keine Aufgabenliste, kein58Commit-Vorschlag. Stattdessen die ausgewerteten Quellen und den Befund kurz berichten — inklusive59ggf. einzelner Grenzfälle, deren Bewertung der Benutzer entscheidet.6061## Referenzen62- [references/doku-ziel.md](references/doku-ziel.md) — Doku-Ziel wählen (README vs. README+DEVELOPMENT),63 Umfang und was rein- bzw. nicht reingehört.64- [references/konventionen.md](references/konventionen.md) — Schreib-, Changelog- und Diagramm-Regeln65 sowie projekt-spezifische Konventionen.
processcube-io