full-after-care

Solid

Tiefe Pflegerunde für ein veröffentlichtes GitHub-Repository (Stufe 2): enthält den vollständigen surface-after-care-Durchlauf und ergänzt ihn um drei teure Schritte — rechtliche Ersteinschätzung über die Rechtsabteilung mit Wiedervorlage nach einem Jahr (Gutachten bleibt gitignored im Repo), Querverweise zu verwandten Repos über ALLE Organisationen hinweg sowie das Nachziehen aller Sprachen auf App-Ebene, nicht nur in der Doku. Nutze diesen Skill bei "full after care", "deep after care", "tiefe Repo-Pflege", "große Runde", "Repo grundlegend durchgehen", wenn ein Repo länger nicht geprüft wurde, vor größeren Releases oder wenn rechtliche Relevanz, Querverweise oder Mehrsprachigkeit ausdrücklich Thema sind. Für die günstige, oft wiederholte Runde stattdessen surface-after-care; für die Erstveröffentlichung github-repo-care.

AI & Automation 2 stars 1 forks Updated today MIT

Install

View on GitHub

Quality Score: 81/100

Stars 20%
16
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Full After Care — die tiefe Runde (Synonym: Deep After Care) ## Wann dieser Skill greift Nutze ihn, wenn ein veröffentlichtes Repo **grundlegend** durchgegangen werden soll: länger nicht geprüft, vor einem größeren Release, bei rechtlich relevanten Gegenständen, oder wenn die Verzahnung mit den übrigen eigenen Projekten Thema ist. Der Unterschied zur günstigen Runde ist der Aufwand, nicht die Sorgfalt: Stufe 2 verlässt die Grenzen des einzelnen Repos. Sie fragt Fremdquellen an (Rechtslage), inventarisiert **alle** Organisationen und greift in die Anwendung selbst ein (Sprachen). Deshalb läuft sie seltener — typischerweise einmal pro Repo und Jahr oder anlassbezogen. ## Ablauf ### Stufe 1 zuerst vollständig Führe **`surface-after-care` komplett aus** — inklusive Schritt 0 (Distributionsflächen), Privacy-Gate, Veröffentlichungsabsicht, Banner, Ist-Soll-Abgleich, README-Sprachen, Sichtbarkeit, Organisationseintrag, Issues und PRs sowie Commit, Push und Flächen-Parität. Nichts davon wird hier wiederholt oder abgekürzt. Die drei folgenden Schritte kommen obendrauf. Sie erzeugen ihrerseits Änderungen an Doku und Code — pushe sie im selben Rhythmus wie in Stufe 1 beschrieben, in thematisch getrennten Commits. --- ### 5. Rechtliche Ersteinschätzung mit Jahres-Wiedervorlage #### Zuerst: Ist eine Einschätzung überhaupt fällig? Sieh in `_after-care/RECHTSCHECK.md` nach (der Ordner ist gitignored, siehe unten). Steht dort ein Prüfdatum, das **weniger als ein Jahr** zurücklie...

Details

Author
ellmos-ai
Repository
ellmos-ai/skills
Created
4 months ago
Last Updated
today
Language
Python
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

surface-after-care

Regelmäßiger Pflegedurchlauf für ein bereits veröffentlichtes GitHub-Repository (Stufe 1, günstig und oft wiederholbar): zuerst alle Distributionsflächen des Projekts ermitteln (npm, PyPI, Registries, Marketplaces, Stores, Website) und Änderungen später dorthin spiegeln, dann Topics setzen, Privacy-Gate, Dokumente auf Veröffentlichungsabsicht prüfen und interne Planungsdateien nachträglich ignorieren, Banner ergänzen, Aussagen im README gegen den echten Code-Stand abgleichen, Darstellung verbessern, Sprachfassungen der README vervollständigen, Sichtbarkeitsmaßnahmen umsetzen, Eintrag auf der Organisationsseite prüfen sowie offene Issues und Pull Requests abarbeiten. Nutze diesen Skill, wenn ein bestehendes Repo gepflegt, aufgeräumt, aktualisiert, aufgehübscht oder "mal wieder durchgesehen" werden soll, wenn ein Repo veraltet oder unaufgeräumt wirkt, bei Formulierungen wie "Repo-Pflege", "after care", "Nachpflege", "Repo auf Stand bringen", "aufräumen und pushen" oder bei rotierenden Qualitätsrunden über mehre

2 Updated today
ellmos-ai
AI & Automation Solid

github-repo-care

Protokoll für das sichere Erstellen, Veröffentlichen und Pflegen von GitHub-Repositories: lokale Regeln und Sperren prüfen, .gitignore vor dem ersten Add setzen, Privacy-Checks durchführen, README/i18n/Banner/Metadaten vorbereiten, Release-Tag und GitHub-Release verifizieren sowie Organisationsprofile, llms.txt und Registry-Links aktualisieren.

2 Updated today
ellmos-ai
Code & Development Listed

global-git-conventions

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.

1 Updated 1 weeks ago
wemwi