Skills als eigene Bereiche dokumentieren und das ZIP über ein Gitea-Release ausliefern.
This commit is contained in:
Dominic Gundel committed
1 parent
b57c458919
commit
55e93e7660
17 files changed
+436
-215
No files matched your search
+68
-14
@@ -1,16 +1,21 @@
|
||||
# Mitarbeiten
|
||||
|
||||
Kollegen installieren einen Skill ohne Git: ZIP aus der Tabelle in der [README](README.md) laden und in Claude hochladen. Dieser Text ist für alle, die einen Skill anlegen oder aktualisieren.
|
||||
|
||||
## Aufbau eines Skills
|
||||
|
||||
```
|
||||
skills/<name>/
|
||||
├── SKILL.md Pflicht – Anweisungen für Claude
|
||||
├── CHANGELOG.md Pflicht – Versionen (wird nicht ins ZIP gepackt)
|
||||
├── SKILL.md Pflicht – Anweisungen für Claude (liegt im ZIP)
|
||||
├── README.md Pflicht – Doku für Menschen (nicht im ZIP)
|
||||
├── CHANGELOG.md Pflicht – Versionen (nicht im ZIP)
|
||||
├── scripts/ optional – Hilfsskripte, die Claude ausführen kann
|
||||
├── references/ optional – Nachschlagematerial, das Claude bei Bedarf liest
|
||||
└── assets/ optional – Vorlagen, Bilder usw.
|
||||
```
|
||||
|
||||
`README.md` hat dieselben Abschnitte wie [templates/skill/README.md](templates/skill/README.md): Zweck, Voraussetzungen, Installation, Einrichtung, Stolpersteine, Test, Deinstallation/Update, Link zum Changelog.
|
||||
|
||||
## Regeln
|
||||
|
||||
- **Name:** kebab-case, nur `a-z`, `0-9` und einzelne Bindestriche, höchstens 64 Zeichen, ohne „claude“ oder „anthropic“. Der Ordnername ist der Skill-Name.
|
||||
@@ -23,39 +28,88 @@ skills/<name>/
|
||||
---
|
||||
```
|
||||
|
||||
`name` muss dem Ordnernamen entsprechen. `description` ist Pflicht, höchstens 1024 Zeichen, ohne spitze Klammern. Sie entscheidet, wann Claude den Skill benutzt – also beschreiben, *wann* er gebraucht wird, nicht nur *was* er ist. Enthält sie „: “, in Anführungszeichen setzen.
|
||||
`name` muss dem Ordnernamen entsprechen. `description` ist Pflicht, höchstens 1024 Zeichen, ohne spitze Klammern. Sie entscheidet, wann Claude den Skill benutzt – also beschreiben, *wann* er gebraucht wird, nicht nur *was* er ist. Enthält sie „: “, in Anführungszeichen setzen. Dieselbe `description` erscheint als Kurzbeschreibung in der Tabelle der Wurzel-README.
|
||||
- **Kodierung:** UTF-8 ohne BOM, Zeilenenden LF (regelt `.gitattributes`).
|
||||
- **CHANGELOG.md:** Einträge als `## x.y.z (YYYY-MM-DD)`, neuester oben. Der oberste Eintrag ist die aktuelle Version.
|
||||
|
||||
## Ablauf
|
||||
## Neuer Skill
|
||||
|
||||
1. Skill anlegen:
|
||||
1. Ordner aus der Vorlage anlegen:
|
||||
`scripts/new-skill.sh <name>` bzw. `scripts\new-skill.ps1 -Name <name>`
|
||||
2. `SKILL.md` ausfüllen.
|
||||
2. `SKILL.md` und `README.md` ausfüllen.
|
||||
3. Prüfen:
|
||||
`scripts/validate.sh <name>` bzw. `scripts\validate.ps1 -Name <name>`
|
||||
4. Version im `CHANGELOG.md` des Skills erhöhen und Änderungen beschreiben.
|
||||
5. Skill-Tabelle in der README aktualisieren:
|
||||
`scripts/update-readme.sh` bzw. `scripts\update-readme.ps1`
|
||||
6. Committen.
|
||||
7. Tag setzen und pushen – das Release entsteht automatisch:
|
||||
4. Tabelle in der Wurzel-README neu erzeugen:
|
||||
`scripts/update-index.sh` bzw. `scripts\update-index.ps1`
|
||||
5. Committen und nach `main` pushen.
|
||||
6. Tag setzen und pushen. Bestehende Tags nicht verschieben und nicht löschen. Der Push allein legt kein Release an.
|
||||
|
||||
```sh
|
||||
git tag <name>/v<version>
|
||||
git push origin main <name>/v<version>
|
||||
```
|
||||
|
||||
Die GitHub Action prüft, dass die Tag-Version zur obersten CHANGELOG-Version passt, baut das ZIP und hängt es an ein Release mit dem CHANGELOG-Abschnitt als Text.
|
||||
7. Release vom eigenen Rechner anlegen (siehe unten). Auf git.gundel.dev läuft kein Actions-Runner.
|
||||
|
||||
## Update eines Skills
|
||||
|
||||
1. `SKILL.md` und `README.md` ändern.
|
||||
2. Im `CHANGELOG.md` einen neuen Eintrag `## x.y.z (YYYY-MM-DD)` oben einfügen.
|
||||
3. Prüfen (`validate`), dann `update-index` ausführen.
|
||||
4. Committen und nach `main` pushen.
|
||||
5. Neuen Tag `<name>/v<version>` setzen und pushen. Der Tag muss exakt zur obersten CHANGELOG-Version passen. Danach das Release vom eigenen Rechner anlegen.
|
||||
|
||||
## Versionen
|
||||
|
||||
- **Patch** (0.1.0 → 0.1.1): Korrekturen, Tippfehler, präzisere Formulierungen
|
||||
- **Patch** (0.1.0 → 0.1.1): Korrekturen, Tippfehler, präzisere Formulierungen, Doku
|
||||
- **Minor** (0.1.0 → 0.2.0): neue Abschnitte, neue bekannte Fallen, neue Beispiele
|
||||
- **Major** (0.x → 1.0.0): geänderte Voraussetzungen oder Arbeitsweise, die bestehende Einrichtungen betreffen
|
||||
|
||||
## Release
|
||||
|
||||
Ein Paket pro Skill, Dateiname `dist/<name>-v<version>.zip`. Im ZIP liegt der Ordner `<name>/` mit `SKILL.md` auf oberster Ebene. `README.md` und `CHANGELOG.md` werden nicht eingepackt.
|
||||
|
||||
```sh
|
||||
scripts/package.sh # alle Skills
|
||||
scripts/package.sh <name>
|
||||
```
|
||||
|
||||
```powershell
|
||||
powershell -ExecutionPolicy Bypass -File scripts\package.ps1
|
||||
powershell -ExecutionPolicy Bypass -File scripts\package.ps1 -Name <name>
|
||||
```
|
||||
|
||||
### Vom eigenen Rechner
|
||||
|
||||
Auf git.gundel.dev ist kein Actions-Runner registriert. Das Release legt deshalb ein Skript auf dem Rechner an, der das ZIP schon gebaut hat. Es spricht die Gitea-API an ([Release anlegen](https://docs.gitea.com/enterprise/api/21/operations/repo-create-release/), [Anhang hochladen](https://docs.gitea.com/api/operations/repo-create-release-attachment/)):
|
||||
|
||||
- `POST /api/v1/repos/dg/claude-skills/releases`
|
||||
- `POST /api/v1/repos/dg/claude-skills/releases/{id}/assets`
|
||||
|
||||
Dafür braucht es ein persönliches Zugangs-Token mit Schreibrecht auf dieses Repository (`write:repository`). Anlegen unter Profil → Einstellungen → Applications. Authentifizierung: [`Authorization: token …`](https://docs.gitea.com/development/api-usage/). Das Token nur in die Umgebung legen, nicht ins Repository.
|
||||
|
||||
Der Tag `<name>/v<version>` muss lokal existieren und schon auf dem Server liegen. Das Skript verschiebt keine Tags und pusht nichts.
|
||||
|
||||
```powershell
|
||||
$env:GITEA_TOKEN = '<Token>'
|
||||
powershell -ExecutionPolicy Bypass -File scripts\release.ps1 -Name <name>
|
||||
```
|
||||
|
||||
```sh
|
||||
GITEA_TOKEN='<Token>' scripts/release.sh <name>
|
||||
```
|
||||
|
||||
### Manuell, ohne Token
|
||||
|
||||
1. Paket bauen (Befehle oben). Prüfen, dass `dist/<name>-v<version>.zip` die Einträge `<name>/` und `<name>/SKILL.md` enthält und weder `README.md` noch `CHANGELOG.md`.
|
||||
2. Unter [Releases](https://git.gundel.dev/dg/claude-skills/releases) ein neues Release anlegen.
|
||||
3. Tag: `<name>/v<version>` (der Tag muss schon auf dem Server liegen). Titel: `<name> <version>`.
|
||||
4. Als Text den Abschnitt dieser Version aus `skills/<name>/CHANGELOG.md` einfügen.
|
||||
5. `dist/<name>-v<version>.zip` als Anhang hochladen.
|
||||
|
||||
## Hinweise zu den Skripten
|
||||
|
||||
- Für jedes Skript gibt es eine Bash- (`.sh`) und eine PowerShell-Variante (`.ps1`). Die Bash-Skripte brauchen `zip` und `unzip`, die PowerShell-Skripte laufen ohne Zusatztools unter Windows PowerShell 5.1 und PowerShell 7.
|
||||
- Für jedes Skript gibt es eine Bash- (`.sh`) und eine PowerShell-Variante (`.ps1`). Die Bash-Skripte brauchen `zip` und `unzip`, die PowerShell-Skripte laufen ohne Zusatztools unter Windows PowerShell 5.1 und PowerShell 7. `release.sh` braucht zusätzlich `curl` und `python3`; unter Windows genügt `release.ps1`.
|
||||
- `.ps1`-Dateien enthalten nur ASCII-Zeichen. Windows PowerShell 5.1 liest UTF-8 ohne BOM als ANSI; Umlaute oder Gedankenstriche können ein Skript dort unbrauchbar machen.
|
||||
- `package.ps1` baut ZIPs mit `System.IO.Compression` statt `Compress-Archive`, weil `Compress-Archive` unter 5.1 Pfade mit `\` schreibt.
|
||||
- Unter Windows bei gesperrter Ausführungsrichtlinie: `powershell -ExecutionPolicy Bypass -File scripts\<skript>.ps1`
|
||||
Reference in new issue
Block a user