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
- 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.
- README passt auf einen Bildschirm. Kein Handbuch. Was länger wird, kommt in eine separate Datei oder den passenden Fach-Skill.
- 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.
- Web-only-tauglich. Alle Schritte funktionieren über GitHub Web + Cloudflare-Git-Build. Keine Annahme über lokales git/Terminal.
- READMEs auf Deutsch.
- 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:
| Suffix |
Beispiel |
README-Template |
release-type |
*-mcp |
google-sheets-mcp |
assets/readme/mcp.md |
node |
*-foundation |
mcp-foundation |
assets/readme/foundation.md |
node |
*-library |
skill-library |
assets/readme/library.md |
simple |
Details je Typ: siehe references/types.md.
Workflow — neues oder bestehendes Repo standardisieren
- Typ bestimmen am Suffix (Tabelle oben).
- README aus dem passenden
assets/readme/*.md ableiten. Platzhalter <...> ersetzen. Pflichtsektionen nicht entfernen — Regel in references/conventions.md.
- 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.
- 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.
- Commit-Konvention einhalten: Conventional Commits, auch im PR-Titel bei Squash-Merge. Mapping in
references/changelog.md.
- 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-Regelreferences/versioning.md — SemVer-Policy (wann major/minor/patch), Tag-Konventionreferences/changelog.md — CHANGELOG × release-please, Conventional-Commit-Mappingreferences/automation.md — release-please + Renovate einrichten, Cloudflare-Interaktion, Token/Settingsreferences/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 Typreferences/types.md — die drei Repo-Typen im Detail
Assets — ins Ziel-Repo kopieren
assets/readme/{mcp,foundation,library}.md — README-Templatesassets/CHANGELOG.template.md — CHANGELOG-Startdateiassets/automation/release-please.yml — Workflow → .github/workflows/assets/automation/config-{node,simple}.json — → release-please-config.jsonassets/automation/manifest.json — → .release-please-manifest.jsonassets/automation/renovate.json — Renovate-Config (Mend-App), → Repo-Wurzel
1---2name: global-git-conventions3description: 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.4---56# global-git-conventions78Verbindlicher 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.910## Grundprinzipien11121. **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.132. **README passt auf einen Bildschirm.** Kein Handbuch. Was länger wird, kommt in eine separate Datei oder den passenden Fach-Skill.143. **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.154. **Web-only-tauglich.** Alle Schritte funktionieren über GitHub Web + Cloudflare-Git-Build. Keine Annahme über lokales git/Terminal.165. **READMEs auf Deutsch.**176. **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`.1819## Repo-Typ am Suffix erkennen2021Der Repo-Name bestimmt Template und Konfiguration:2223| Suffix | Beispiel | README-Template | release-type |24|--------|----------|-----------------|--------------|25| `*-mcp` | `google-sheets-mcp` | `assets/readme/mcp.md` | `node` |26| `*-foundation` | `mcp-foundation` | `assets/readme/foundation.md` | `node` |27| `*-library` | `skill-library` | `assets/readme/library.md` | `simple` |2829Details je Typ: siehe `references/types.md`.3031## Workflow — neues oder bestehendes Repo standardisieren32331. **Typ bestimmen** am Suffix (Tabelle oben).342. **README** aus dem passenden `assets/readme/*.md` ableiten. Platzhalter `<...>` ersetzen. Pflichtsektionen nicht entfernen — Regel in `references/conventions.md`.353. **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`.364. **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`.375. **Commit-Konvention** einhalten: Conventional Commits, auch im PR-Titel bei Squash-Merge. Mapping in `references/changelog.md`.386. **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`.3940## Commit-Vorschlag — am Ende jeder Repo-Änderung mitliefern4142Sobald eine Änderung in einem dieser Repos landet (Datei geändert, Skill/Asset43geliefert, Config angepasst), schließe die Antwort mit einem **copy-paste-fähigen44Commit-Block** ab — Title und, wenn die Änderung es wert ist, ein kurzer Body. Das ist45keine Option und keine Nachfrage-Sache: web-only committest du das von Hand im46GitHub-Web, also muss der fertige Text bereitliegen.4748- **Auslöser:** echte Repo-Änderung (geänderte/neue Datei, geliefertes Artefakt). Reine49 Fragen, Debugging ohne Dateiänderung oder Erklärungen brauchen keinen Block.50- **Format:** Conventional Commit, release-please-tauglich. Bei Squash-Merge zählt der51 PR-Titel — derselbe Text passt für beides. Mapping, Body-Format und Beispiele:52 `references/changelog.md`. SemVer-Stelle: `references/versioning.md`.53- **Scope = die berührte Komponente** (z.B. der Skill-Name in einer `*-library`). In54 Monorepo-Setups ordnet release-please über den **Dateipfad** zu, nicht über den Scope55 — einen Commit also nie quer über zwei Komponenten ziehen.56- **Mehrere unabhängige Änderungen:** getrennte Commit-Vorschläge (sauberer Changelog),57 nicht alles in einen quetschen. Gehört es logisch zusammen, ein Commit mit Footer.58- **Skill-Version mitführen:** Ändert sich ein Skill in einer `*-library`, gehört der59 passende `metadata.version`-Bump im SKILL.md zur selben Änderung — Regel in60 `references/versioning.md`.6162## Referenzen — bei Bedarf lesen6364- `references/conventions.md` — README-Pflichtsektionen, Längenlimit, SSoT-Regel65- `references/versioning.md` — SemVer-Policy (wann major/minor/patch), Tag-Konvention66- `references/changelog.md` — CHANGELOG × release-please, Conventional-Commit-Mapping67- `references/automation.md` — release-please + Renovate einrichten, Cloudflare-Interaktion, Token/Settings68- `references/protection.md` — Repo-Härtung: Branch-Protection, Secret Scanning, Dependabot, 2FA (GitHub Free, public vs. private)69- `references/about.md` — GitHub About-Block: Description, Website, Topic-Schema je Typ70- `references/types.md` — die drei Repo-Typen im Detail7172## Assets — ins Ziel-Repo kopieren7374- `assets/readme/{mcp,foundation,library}.md` — README-Templates75- `assets/CHANGELOG.template.md` — CHANGELOG-Startdatei76- `assets/automation/release-please.yml` — Workflow → `.github/workflows/`77- `assets/automation/config-{node,simple}.json` — → `release-please-config.json`78- `assets/automation/manifest.json` — → `.release-please-manifest.json`79- `assets/automation/renovate.json` — Renovate-Config (Mend-App), → Repo-Wurzel
wemwi