agentsclimarketplace

Global git conventions

Skill wemwi/skill-library/global-git-conventions

Versionierte Heimat meiner Agent Skills für Claude (claude.ai, Claude Code, API).

Install
npx -y skills add wemwi/skill-library --skill global-git-conventions

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Projektübergreifender Standard für GitHub-Repos — README-Aufbau, SemVer-Versionierung, CHANGELOG und Pflicht-Release-Automation via release-please. IMMER laden, sobald ein Repo angelegt, ein README geschrieben oder auditiert, eine Version gebumpt, ein Tag/Release gesetzt, ein CHANGELOG gepflegt oder die Release-Automation eingerichtet wird — auch wenn das Wort Skill oder Convention nicht fällt. Trigger u.a. README erstellen/überarbeiten, neues Repo bootstrappen, Version bumpen, SemVer-Entscheidung major/minor/patch, Git-Tag setzen, CHANGELOG anlegen/aktualisieren, Conventional Commits, release-please einrichten, Release-PR, Repo dokumentieren, Repo-Hygiene, eine Änderung committen oder ins Repo hochladen, einen Commit-Title oder eine Commit-Message formulieren, Upload/Commit vorbereiten. Gilt für alle eigenen Repos der Typen *-library, *-mcp und *-foundation.

SKILL.md

6.7 KB, as published. Nobody here has run it

global-git-conventions

Verbindlicher Standard für Doku und Versionierung aller eigenen GitHub-Repos. Dieser Skill definiert den typ-übergreifenden Standard. Typ-spezifische Details (z.B. die MCP-Secrets-Mechanik) leben in den jeweiligen Fach-Skills und werden von hier nur referenziert — nie dupliziert.

Grundprinzipien

  1. Single Source of Truth pro Regel. Jede Vorgabe lebt an genau einer Stelle. Dieser Skill = Standard. Fach-Skills (global-mcp-framework etc.) = Erweiterung. README-Templates sind nur die Materialisierung der Regel aus references/conventions.md — bei Konflikt gewinnt die Referenz.
  2. README passt auf einen Bildschirm. Kein Handbuch. Was länger wird, kommt in eine separate Datei oder den passenden Fach-Skill.
  3. Automation ist Pflicht, nicht optional. Jedes Repo bekommt release-please (Releases) und Renovate (Dependency-Bumps). Versionierung und CHANGELOG werden nicht von Hand gepflegt, sondern aus Conventional Commits generiert; Dependency-Updates kommen als Renovate-PRs, nicht von Hand. Release-PRs werden automatisch gemergt — releasbarer Merge auf main → Release + Deploy ohne Handgriff (Mechanik + PAT-Pflicht in references/automation.md). Renovate-Bump-PRs bleiben bewusst manuell.
  4. Web-only-tauglich. Alle Schritte funktionieren über GitHub Web + Cloudflare-Git-Build. Keine Annahme über lokales git/Terminal.
  5. READMEs auf Deutsch.
  6. Jede Repo-Änderung endet mit einem fertigen Commit-Vorschlag. Web-only heißt: du committest von Hand über GitHub-Web. Deshalb liefere ich den Commit-Block proaktiv mit — nie erst auf Nachfrage. Format und Regeln: Abschnitt unten + references/changelog.md.

Repo-Typ am Suffix erkennen

Der Repo-Name bestimmt Template und Konfiguration:

SuffixBeispielREADME-Templaterelease-type
*-mcpgoogle-sheets-mcpassets/readme/mcp.mdnode
*-foundationmcp-foundationassets/readme/foundation.mdnode
*-libraryskill-libraryassets/readme/library.mdsimple

Details je Typ: siehe references/types.md.

Workflow — neues oder bestehendes Repo standardisieren

  1. Typ bestimmen am Suffix (Tabelle oben).
  2. README aus dem passenden assets/readme/*.md ableiten. Platzhalter <...> ersetzen. Pflichtsektionen nicht entfernen — Regel in references/conventions.md.
  3. CHANGELOG anlegen: assets/CHANGELOG.template.md kopieren (minimaler Header, den release-please füllt). NICHT von Hand mit [Unreleased] pflegen — Begründung in references/changelog.md.
  4. Automation einrichten: Workflow + Config + Manifest aus assets/automation/ kopieren, release-type nach Typ wählen. Setup-Schritte und die zwei Stolperfallen (Repo-Setting, Token) in references/automation.md.
  5. Commit-Konvention einhalten: Conventional Commits, auch im PR-Titel bei Squash-Merge. Mapping in references/changelog.md.
  6. About-Block setzen: Description (= README-Einzeiler), Website (Live-URL bei *-mcp) und Topics je Typ. Kein Datei-Artefakt — per gh repo edit mitsetzen. Schema in references/about.md.

Commit-Vorschlag — am Ende jeder Repo-Änderung mitliefern

Sobald eine Änderung in einem dieser Repos landet (Datei geändert, Skill/Asset geliefert, Config angepasst), schließe die Antwort mit einem copy-paste-fähigen Commit-Block ab — Title und, wenn die Änderung es wert ist, ein kurzer Body. Das ist keine Option und keine Nachfrage-Sache: web-only committest du das von Hand im GitHub-Web, also muss der fertige Text bereitliegen.

  • Auslöser: echte Repo-Änderung (geänderte/neue Datei, geliefertes Artefakt). Reine Fragen, Debugging ohne Dateiänderung oder Erklärungen brauchen keinen Block.
  • Format: Conventional Commit, release-please-tauglich. Bei Squash-Merge zählt der PR-Titel — derselbe Text passt für beides. Mapping, Body-Format und Beispiele: references/changelog.md. SemVer-Stelle: references/versioning.md.
  • Scope = die berührte Komponente (z.B. der Skill-Name in einer *-library). In Monorepo-Setups ordnet release-please über den Dateipfad zu, nicht über den Scope — einen Commit also nie quer über zwei Komponenten ziehen.
  • Mehrere unabhängige Änderungen: getrennte Commit-Vorschläge (sauberer Changelog), nicht alles in einen quetschen. Gehört es logisch zusammen, ein Commit mit Footer.
  • Skill-Version mitführen: Ändert sich ein Skill in einer *-library, gehört der passende metadata.version-Bump im SKILL.md zur selben Änderung — Regel in references/versioning.md.

Referenzen — bei Bedarf lesen

  • references/conventions.md — README-Pflichtsektionen, Längenlimit, SSoT-Regel
  • references/versioning.md — SemVer-Policy (wann major/minor/patch), Tag-Konvention
  • references/changelog.md — CHANGELOG × release-please, Conventional-Commit-Mapping
  • references/automation.md — release-please + Renovate einrichten, Cloudflare-Interaktion, Token/Settings
  • references/protection.md — Repo-Härtung: Branch-Protection, Secret Scanning, Dependabot, 2FA (GitHub Free, public vs. private)
  • references/about.md — GitHub About-Block: Description, Website, Topic-Schema je Typ
  • references/types.md — die drei Repo-Typen im Detail

Assets — ins Ziel-Repo kopieren

  • assets/readme/{mcp,foundation,library}.md — README-Templates
  • assets/CHANGELOG.template.md — CHANGELOG-Startdatei
  • assets/automation/release-please.yml — Workflow → .github/workflows/
  • assets/automation/config-{node,simple}.json — → release-please-config.json
  • assets/automation/manifest.json — → .release-please-manifest.json
  • assets/automation/renovate.json — Renovate-Config (Mend-App), → Repo-Wurzel

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.