mcpField
R
repo-doku

repo-doku

github.com/processcube-ioDevelopment0110 installsUpdated 17w ago
Repository

About repo-doku

repo-doku is a skill for creating or updating project documentation inside the source repository, aimed at developers maintaining repository docs. It uses existing documentation, change logs, Git commits, and source code to identify updates, and does not commit or push changes automatically.

Key features

  1. 01Maintain README.md in the repository
  2. 02Add DEVELOPMENT.md for larger projects
  3. 03Update only identified documentation gaps
  4. 04Use change logs, Git commits, and source code
  5. 05Never commit or push changes automatically

Use cases

  1. 01Document new features in a project README
  2. 02Update development docs for a larger project
  3. 03Check whether recent commits require documentation changes

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/processcube-io/processcube.agent.skills --skill repo-doku

After installing, type/repo-dokuin Claude Code to confirm it loaded.

Bundled filesreferences/doku-ziel.mdreferences/konventionen.md

Details

From the project README

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)
  1. Vorhandene Doku (README.md, ggf. DEVELOPMENT.md) als Ausgangsbasis — fortschreiben, nicht von Null neu schreiben.
  2. Changelog-Dateien als strukturierte Quelle für Neuerungen (auf die exakte Schreibweise im Repo achten, z.B. Changelog.md vs. CHANGELOG.md).
  3. Git-Commits seit letztem Stand (Schritt 2) für Änderungen ohne Changelog-Eintrag.
  4. 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

Comments

Markdown supported