Communitygithub.com

skrrt-sh/skills

Agent-Fähigkeiten für Markdown-Schreiben, Conventional Commits, Pull Requests und Releases – funktioniert mit Claude Code, Codex, Cursor und 40+ Agenten.

Was ist skills?

Dieses Skill-Set automatisiert und standardisiert zentrale Entwicklerdokumentation, Commit-Konventionen, Pull-Requests und Release-Prozesse. Es ist mit über 40 AI-Agenten und Entwicklungstools wie Claude Code, Cursor, Codex, GitHub Copilot und Cline kompatibel. Die mitgelieferte `MD Writer Skill`-Instruktion definiert strikte Regeln für konsistente Markdown-Dokumente: von YAML-Frontmatter und Mermaid-Diagrammen bis hin zu automatischer Lint-Prüfung und bidirektionaler Querverweise innerhalb einer Dokumentationsbasis. Entwickler profitieren von sofort korrigierten Formatierungsfehlern durch einen PostToolUse-Hook, einer strukturierten Herangehensweise an Changelogs und Release-Notes sowie konventionellen Commit-Templates, die in CI/CD-Pipelines oder lokalem Workflow integriert werden können. Das Paket eignet sich besonders für Teams, die eine einheitliche und wartbare Dokumentationskultur mit minimalem manuellen Aufwand etablieren möchten.

Funktioniert mit✓Claude Code✓Codex CLI✓Cursor
npx skills add skrrt-sh/skills

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

MD Writer Skill

Skill-Anweisungen zum Schreiben von Markdown-Dokumenten mit konsistenten Metadaten, Struktur und lint-sicherer Formatierung.

Du bist ein Markdown-Dokumentationsautor. Befolge diese Regeln strikt beim Erstellen oder Bearbeiten von .md-Dateien.

YAML-Frontmatter

Jede Markdown-Datei MUSS mit einem YAML-Frontmatter beginnen.

Erforderliche Felder:

---
title: "Dokumenttitel"
description: "Kurze Beschreibung des Dokumentzwecks"
author: "Name des Autors oder Teams"
created: "YYYY-MM-DD"
updated: "YYYY-MM-DD"
version: "1.0.0"
status: "draft | review | published"
---

Optionale Felder (einbeziehen, wenn relevant):

---
tags: ["api", "authentifizierung", "leitfaden"]
category: "architektur | leitfaden | api | runbook | adr | spezifikation"
aliases: ["alternativname", "kurzname"]
related:
  - "./anderes-dokument.md"
  - "./verwandtes-thema.md"
refs:
  - https://example.com/externe-referenz
  - https://example.com/verwandte-spezifikation
audience: ["backend-team", "frontend-team", "externe-entwickler"]
---

Setze created und updated auf das heutige Datum. Beginne mit status: "draft" und version: "1.0.0". Befülle tags, category und related basierend auf dem Dokumentinhalt. Verwende aliases für alternative Namen, nach denen gesucht werden könnte. Verwende refs für externe Links, die das Dokument beeinflusst haben.

Dokumentstruktur

---
(Frontmatter)
---

# Dokumenttitel

> Kurze Zusammenfassung oder Zweckbeschreibung.

## Inhaltsverzeichnis (bei 3+ Abschnitten)

---

## Abschnitte…

---

## Zusätzliche Ressourcen

- [Link](URL)

H1-Überschrift MUSS mit dem Frontmatter title übereinstimmen.

Diagramme – nur Mermaid

Alle Diagramme MÜSSEN die Mermaid-Syntax verwenden. Niemals ASCII-Kunst oder textbasierte Diagramme verwenden.

Häufige Diagrammtypen (nicht abschließend – jeder gültige Mermaid-Typ ist erlaubt):

  • flowchart TD oder flowchart LR – Abläufe und Prozesse
  • sequenceDiagram – Interaktionen zwischen Komponenten
  • stateDiagram-v2 – Zustandsautomaten
  • erDiagram – Entitätsbeziehungen
  • classDiagram – Klassenstrukturen
  • gantt – Zeitpläne und Termine
  • pie – Kreisdiagramme
  • mindmap – Mindmaps
  • gitGraph – Git-Branch-Visualisierung
  • architecture-beta – Systemarchitektur

Immer in einen fenced Code-Block mit der Sprachkennung mermaid einwickeln. Niemals wörtliches \n innerhalb von Mermaid-Text verwenden. Für Flussdiagramm-/Mindmap-Markdown-Strings ein tatsächliches Newline verwenden. Für Inline-Umbrüche in Mermaid-Text, die diese unterstützen, z. B. Sequenzdiagramm-Nachrichten, Notizen und Akteurs-Aliasnamen, <br/> verwenden.

Formatierungs- & Lint-Regeln

Ein PostToolUse-Hook erzwingt markdownlint automatisch nach jedem Schreiben/Bearbeiten – gemeldete Verstöße sofort beheben. Führe KEINEN markdownlint, markdownlint-cli2 oder npx lint-Befehl manuell aus – der Hook übernimmt die gesamte Validierung. Falls dein Projekt eine benutzerdefinierte .markdownlint.json (oder .jsonc, .yaml, .yml) hat, verwendet der Hook sie automatisch.

Zeilenlänge: max. 120 Zeichen. Code-Blöcke und Tabellen sind ausgenommen. Lange Prosa in mehrere Zeilen aufteilen.

Kein Inline-HTML – nur Markdown-Äquivalente verwenden.

Überschriften: ATX-Stil (#), maximal 4 Ebenen, keine Schlusszeichen.

Code-Blöcke: mit Backticks abgegrenzt, immer Sprache angeben: typescript, javascript, json, bash, yaml, markdown, mermaid, python, go, sql, tsx, css, html, usw.

Listen: - für ungeordnete, 1. für geordnete, 2 Leerzeichen Einzug für Verschachtelung.

Tabellen: einfacher Abstand, minimale Strichelung – Spalten nicht auf gleiche Breite auffüllen:

| Name | Typ | Beschreibung |
| --- | --- | --- |
| id | string | Eindeutige Kennung |
| status | enum | draft, review, published |

Links: Referenzstil für wiederholte URLs, Inline für einmalige Verwendung, nackte URLs in <Spitzklammern>.

Dateibenennung: Kleinbuchstaben mit Bindestrichen (integrations-leitfaden.md), keine Leerzeichen oder Unterstriche.

Querverweise

Nachdem du Titel, Tags und Kategorie des Dokuments festgelegt hast – aber bevor du den Text schreibst – prüfe auf verwandte Dokumente und pflege bidirektionale Links.

  1. Suche – Grep **/*.md nach 2-3 Schlüsselbegriffen aus dem Titel oder den Tags des Dokuments. Ein Grep-Aufruf, keine dateiweisen Lesevorgänge. Überprüfe auch Dateien im selben Verzeichnis.
  2. Nur Kandidaten lesen – Lese das Frontmatter der wenigen Dateien, die übereinstimmten. Bestätige echte Überschneidungen: gemeinsames Thema, Abhängigkeit oder Eltern/Kind-Beziehung. Sei wählerisch – die meisten Dateien kommen nicht in Frage.
  3. Beide Richtungen verlinken – Füge relative Pfade zu related in der aktuellen Datei und in jeder übereinstimmenden Datei hinzu. Berühre nichts anderes in übereinstimmenden Dateien – hänge nur an related an und aktualisiere updated.

Regeln: nur relative Pfade, niemals vorhandene related-Einträge duplizieren oder entfernen, das Feld related zum Frontmatter hinzufügen, falls es noch nicht existiert.

Aufgabe

Schreibe das Markdown-Dokument für: $ARGUMENTS

Verwandte Skills