Kicktemp – Wie wir arbeiten

Appearance

Neues Projekt mit dem kicktemp-playbook aufsetzen ​

Ablauf für ein neues Joomla-Extension-Projekt (Component/Plugin/Package), das auf die vorhandene Build-Pipeline aufsetzt. Für Directus/Astro-Projekte gilt das analog, sobald es dafür einen eigenen Skill gibt (Rule of Two).

1. Repo anlegen ​

bash
cd ~/Development/kicktemp
git init <projektname>
cd <projektname>

2. Skill per Symlink einbinden ​

bash
mkdir -p .claude/skills
ln -s ~/Development/kicktemp-playbook/skills/joomla-build .claude/skills/joomla-build

Kein Copy — Fixes am Skill (z. B. der copy-file.js-Binärdatei-Fix) wirken sofort, ohne dass man sie im Projekt nachziehen muss.

3. Config aus dem Template erzeugen ​

bash
cp .claude/skills/joomla-build/config.template.js ./config.js

Alle TODO-Marker in config.js durchgehen: Pfade, Extension-Namen, archiver[]/package[]-Einträge. Nicht unverändert lassen — das Template ist absichtlich unvollständig, Projektidentität lebt hier.

4. package.json mit Placeholder-Block ​

json
"placeholder": {
  "[UPDATEURL]": "https://kicktemp.shop/download?e=[PACKAGE_NAME]&v=[VERSION]",
  "[PACKAGE_NAME]": "...",
  "[PROJECT_NAME]": "...",
  "[PRODUCT_NAME]": "...",
  "[ALIAS]": "...",
  "[AUTHOR]": "Kicktemp GmbH",
  "[PLUGINTYPE]": "system"
}

Devdependency-Versionen aus der SKILL.md prüfen (glob >=9, fast-xml-parser statt libxmljs) — nicht blind aus einem alten Projekt kopieren, das könnte noch die veraltete Version gepinnt haben.

5. CLAUDE.md fürs Projekt ​

markdown
# <Projektname>

## Stack
Joomla 5, ...

## Playbook
Build-Pipeline: `.claude/skills/joomla-build/SKILL.md`
Bekannte Joomla-Fallstricke: `~/Development/kicktemp-playbook/learnings/joomla.md`
Build-Pipeline-Fallstricke: `~/Development/kicktemp-playbook/learnings/joomla-build.md`

6. Scaffold-Check — Pflichtschritt vor dem ersten Release ​

bash
.claude/skills/joomla-build/scripts/scaffold-check.sh

Prüft changelog.xml, update.xml, updatetemplate.xml, release.yml, config.js, package.json auf Identifier-Reste eines Ursprungsprojekts. Bereits mehrfach real aufgetreten (unterschiedliche Quellprojekte jedes Mal) — kein hypothetisches Risiko.

7. Docs-Strategie wählen (falls das Projekt Docs bekommt) ​

  • Kunden-Doku → templates/joomla-build-docs/docs-gh-pages.yml
  • Eigenes Paddle-/Shop-Produkt (docs.kicktemp.com) → templates/joomla-build-docs/push-docs.yml

Siehe learnings/vitepress.md für den Dead-Link-Check-Fallstrick (vitepress build bricht hart bei fehlenden Bild-Referenzen).

8. Erster Build-Test ​

bash
npm install
npm run copy        # lokale Dev-Instanz befüllen
npm run watch        # Live-Sync starten, falls parallel entwickelt wird