Plugin versioning en distributie workflow

Definitie

De versioning en distributieworkflow beschrijft hoe wijzigingen aan een Cowork plugin worden doorgevoerd, verpakt en uitgebracht, zowel voor technisch gebruik via GitHub als voor niet-technische ontvangers via een .plugin-bestand.

Context

Cowork plugins leven in een Git-repo maar worden gedistribueerd als binaire archieven. Dat vraagt om een expliciete stap tussen “code aanpassen” en “plugin bruikbaar opleveren”. Zonder die stap loopt de code in de repo uit de pas met wat mensen installeren. Dit document dekt de volledige cyclus: van code naar release.

Kernpunten

.plugin vs .zip

Een .plugin-bestand is functioneel identiek aan een .zip-bestand. Het verschil zit uitsluitend in de extensie: Cowork herkent .plugin als installeerbaar archief en biedt bij dubbelklik of drag-and-drop de installatiedialog aan. Een .zip met dezelfde inhoud werkt technisch, maar wordt door Cowork niet automatisch herkend. Gebruik .zip voor archivering of inspectie; gebruik .plugin voor alles wat je oplevert aan gebruikers.

Commit-flow

Wijzigingen in de plugin volgen de standaard git-workflow:

1. Breng wijzigingen aan in de bronbestanden (SKILL.md, commands, references, plugin.json).
2. Verhoog het versienummer in plugin.json conform semver: v0.1.0 voor initiële release, v0.2.0 voor nieuwe commands of skills, v0.1.1 voor bugfixes.
3. Commit met een beschrijvend bericht, bij voorkeur met verwijzing naar het versienummer (chore: bump to v0.2.0).
4. Push naar de remote.

Commit de bronbestanden, niet het .plugin-archief zelf. Het archief is een build-artifact en hoort niet in versiebeheer.

Re-packagen: stappen om een .plugin te bouwen

Na elke commit die de plugin wijzigt, moet een nieuw archief worden gebouwd:

# Vanuit de root van de plugin-map (niet de repo-root)
cd ~/Claude/projects/Eindredacteur/eindredacteur
 
# Maak een ZIP van alle pluginbestanden
zip -r ../eindredacteur.zip .
 
# Hernoem naar .plugin
mv ../eindredacteur.zip ../eindredacteur.plugin

Let op: de ZIP moet worden aangemaakt vanuit de plugin-root, zodat plugin.json direct in de root van het archief zit en niet genest in een submap. Een submap-structuur breekt Cowork-installatie (zie wiki-cowork-plugin-structuur).

GitHub workflow: publiceren, taggen, releases

Na het re-packagen:

1. Push de broncode naar de GitHub-repo.
2. Maak een release aan via gh release create v0.2.0 ../eindredacteur.plugin --title "v0.2.0" --notes "Beschrijving van wijzigingen".
3. Het .plugin-bestand wordt als release-asset toegevoegd en is direct downloadbaar via de GitHub-releasepagina.

Tagging maakt het mogelijk om een specifieke versie te reproduceren. Gebruik semver-tags (v0.1.0, v0.2.0), geen datumtags.

Prototype verpakken voor niet-technische ontvangers

Voor mensen die Git niet gebruiken, lever je een ZIP met:

• Het .plugin-bestand (het enige dat ze nodig hebben voor installatie).
• Een beknopte INSTALLATIE.md of README.md met drie stappen: download, drag-and-drop in Cowork, commands beschikbaar via Skills-menu.
• Optioneel: een schermafbeelding van de installatiestap.

Noem de versie expliciet in de bestandsnaam van het .plugin-bestand: eindredacteur-v0.2.0.plugin. Zo is altijd duidelijk welke versie iemand heeft, ook als ze het bestand ergens bewaren.

Opnemen in de README bij distributie:

• Welke commands beschikbaar zijn en wat ze doen.
• Of een bestaande versie eerst verwijderd moet worden voor update.
• Contactinformatie voor vragen.

Verbanden

• Zie ook: wiki-cowork-plugin-structuur

• Gerelateerd project: eindredacteur

• Zie ook: wiki-eindredacteur-plugin — conceptually_related_to

Sessie-herkomst

• raw-cc-2026-03-27-eindredacteur-plugin-bouw