lggarrison/agent-skills

Repo-Setup

Ein neues Repository braucht jedes Mal dieselbe Basis: eine Lizenz, eine Möglichkeit, Sicherheitsprobleme zu melden, eine README, Vorlagen, die PRs und Issues nützlich machen, und ein CI, das dieselben Prüfungen ausführt, die ein Mitwirkender lokal durchführt. Dieses Skill ist eine Checkliste für diese Basis und eine Möglichkeit, sie abzuarbeiten.

Repo-Regeln zuerst

Lies, was das Repository bereits hat, bevor du etwas hinzufügst: AGENTS.md / CLAUDE.md, CONTRIBUTING.md, vorhandene .github/-Dateien, das Paketmanifest und seine Skripte sowie jede CI-Konfiguration. Wenn sie eine Konvention festlegen (Standardbranch, Lizenz, Werkzeuge, Dateipfade), folge ihr. Überschreibe niemals eine vorhandene Datei, um sie an eine Vorlage hier anzupassen. Erweitere sie oder lasse sie unverändert und erwähne die Lücke.

Arbeitsablauf

1. Die Aufgabe klären

• Bootstrapping: ein neues oder fast leeres Repository. Arbeite die gesamte Checkliste ab.
• Lücken füllen: einem bestehenden Repository fehlt ein Teil davon. Füge nur das Fehlende hinzu.
• Audit: berichte, was fehlt oder schwach ist, und ändere nichts.

2. Inventur erstellen

Liste auf, welche Checklisten-Dateien existieren, und lies das Manifest (package.json, pyproject.toml, go.mod, Cargo.toml usw.) für die Sprache, die Skripte und ob das Projekt veröffentlicht wird. Finde den Standardbranch mit git remote show origin oder gh repo view --json defaultBranchRef. Frage den Benutzer nichts, was du auf diese Weise erfahren kannst.

3. Nach den Entscheidungen fragen

Dies sind die Entscheidungen des Benutzers. Frage einmal, in einer kurzen Runde, und empfehle, wo die Belege dies stützen:

• Lizenz, und den Namen des Rechteinhabers.
• Sicherheitskontakt: GitHub Private Vulnerability Reporting, eine E-Mail-Adresse oder beides.
• Verhaltenskodex-Kontakt, falls einer hinzugefügt wird.
• PR-Basisbranch, falls es nicht der Standardbranch ist.
• Veröffentlicht oder nicht: in ein Paketregister oder als Release-Artefakt.
• CI-Matrix: welche Betriebssysteme und Laufzeitversionen unterstützt werden sollen.

4. Dateien schreiben

Arbeite die Checkliste von oben nach unten ab und überspringe Abschnitte, die nicht zutreffen.

• Kanomischen Text holen; nicht aus dem Gedächtnis zitieren. Lizenztext von gh api licenses/<spdx-id> --jq .body holen (z. B. mit oder apache-2.0), dann Jahr und Inhaber eintragen. Einen Verhaltenskodex von seiner offiziellen Quelle holen, wie dem Contributor Covenant.
• Vorlagen anpassen. Beginne mit templates/. Ersetze jedes <placeholder> und ändere die Befehle in solche, die in diesem Repo existieren. Eine Vorlage, die ein Skript auflistet, das das Repo nicht hat, ist schlimmer als keine Vorlage.
• Eine Liste der Prüfungen. Die PR-Vorlagen-Checkliste, CONTRIBUTING.md, der Pre-Commit-Hook und das CI sollten alle dieselben Befehle nennen. Wenn sich einer ändert, ändere die anderen.
• Vor dem Ändern von Einstellungen fragen. Branch-Schutz, Rulesets und Private Vulnerability Reporting sind Repository-Einstellungen, keine Dateien. Schlage sie vor und wende sie nur an, wenn der Benutzer zustimmt.

5. Prüfe es

• Jeder Befehl, der in einer Vorlage, einem Hook oder CI-Job genannt wird, läuft lokal und ist erfolgreich.
• Kein <placeholder> ist in einer Datei verblieben.
• Issue-Formulare und Workflows sind gültiges YAML. Issue-Formulare erscheinen nur auf dem Standardbranch, also überprüfe sie dort nach dem Mergen.
• Links sind gültig, einschließlich der URL der Sicherheitsrichtlinie.
• Die eigenen Formatierungs- und Lint-Prüfungen des Repos bestehen für die neuen Dateien.

6. Bericht erstatten

Sage, was du hinzugefügt hast, was du unverändert gelassen hast und warum, welche Repository-Einstellungen du vorgeschlagen hast und welche Entscheidungen noch offen sind.

Checkliste

R ist erforderlich, rec ist empfohlen und opt ist optional.

Werkzeuge

• R git sowie die Sprachlaufzeit und der Paketmanager.
• rec Ein Laufzeitversionen-Manager (nvm, fnm, pyenv usw.), der zur festgelegten Versionendatei passt.
• rec gh, authentifiziert mit gh auth login, für Betreuer.

Rechtliches und Community

• R LICENSE.
• R SECURITY.md: unterstützte Versionen, wie man privat meldet und was Melder nach der Meldung erwarten können.
• rec CONTRIBUTING.md: Einrichtung, auszuführende Prüfungen, Branch- und Commit-Konventionen und wie PRs überprüft werden.
• rec CODE_OF_CONDUCT.md mit einem echten Durchsetzungskontakt.
• rec CHANGELOG.md im Keep a Changelog-Format.

Dokumentation

• R README.md: Was es ist, wie man es installiert, ein minimales Nutzungsbeispiel und Links zu CONTRIBUTING.md, SECURITY.md und der Lizenz.
• opt AGENTS.md: der anbieterneutrale Einstiegspunkt für Codierungsagenten. Gib die auszuführenden Befehle und die zu befolgenden Regeln an und verlinke auf andere Dokumente, anstatt sie zu wiederholen.
• opt RELEASING.md für veröffentlichte Projekte. Siehe Veröffentlichung.

Editor- und Git-Hygiene

• R .gitignore für die Sprache, die Build-Ausgabe und lokale Umgebungsdateien.
• rec .gitattributes mit * text=auto eol=lf, damit Zeilenenden nicht zwischen Betriebssystemen wechseln.
• rec .editorconfig für Zeichensatz, finale neue Zeile und Einrückung.

GitHub-Vorlagen und -Automatisierung

Wenn das Repository nicht auf GitHub ist, verwende die Äquivalente des Hosts.

• rec .github/PULL_REQUEST_TEMPLATE.md. Siehe Vorlagen.
• rec Issue-Formulare in .github/ISSUE_TEMPLATE/: bug_report.yml, feature_request.yml und eine config.yml, die leere Issues deaktiviert und Sicherheitsmeldungen an den privaten Kanal weiterleitet. Siehe Vorlagen.
• rec .github/dependabot.yml mit einem Eintrag für jedes Paket-Ökosystem, das das Repo verwendet, plus github-actions.
• R .github/workflows/ci.yml, das dieselben Prüfungen wie die PR-Vorlage bei jedem PR und jedem Push auf den Standardbranch ausführt.
• opt .github/release.yml, um generierte Release-Notizen nach Label zu gruppieren.
• opt .github/workflows/release.yml nur für veröffentlichte Projekte.
• rec Branch-Schutz oder ein Ruleset auf dem Standardbranch, das CI erfordert. Dies ist eine Einstellung, also frage zuerst.

Node.js und TypeScript

Überspringe diesen Abschnitt für andere Sprachen und wende dieselben Ideen mit den Werkzeugen dieses Ökosystems an: eine festgelegte Laufzeitversion, ein Formatierer, ein Linter, ein Testläufer, ein einzelner „Alles prüfen“-Befehl und eine CI-Matrix.

Laufzeit und Metadaten

• rec .nvmrc und engines.node in package.json, die miteinander übereinstimmen.
• R package.json repository, homepage, bugs, license und author.
• rec `