feat(skills): add mandatory linting gate before commits and PRs

- gitea-implementierung: lint gate (PHP/CSS/HTML) as first quality gate step
- gitea-fix-refactoring: lint gate before every fix commit
- gitea-merge-release: lint gate before PR creation
- All gates abort on failure (exit code != 0)

skills/gitea-fix-refactoring/SKILL.md

@@ -101,6 +101,26 @@ Zyklus-Counter dokumentieren in `memory/gitea-specs/issue-<number>-fix-cycles.md
   - Bei QA-Fail → **Test- & QA-Agent** (Phase 4)
 - Bei Zyklus > 3: ⏸ Pause + Martin informieren
 
+### Code-Quality-Gates (PFLICHT vor jedem Commit)
+
+**Vor JEDEM Commit müssen ALLE konfigurierten Linter erfolgreich durchlaufen.**
+Falls ein Linter fehlschlägt: **Commit abbrechen**, Fehler beheben, dann erneut versuchen.
+
+```bash
+# PHP Syntax Check
+find . -name "*.php" -not -path "*/vendor/*" -exec php -l {} \; 2>&1 | grep -v "No syntax errors"
+
+# CSS Lint (stylelint)
+npx stylelint "**/*.css" --config .stylelintrc.json --allow-empty-input
+
+# HTML Lint (htmlhint) – nur .html Dateien, nicht .php
+npx htmlhint "**/*.html" --config .htmlhintrc --ignore "**/*.php"
+
+# Projekt-spezifische Linter (falls vorhanden)
+npm run lint
+```
+**Jeder Linter muss Exit-Code 0 zurückgeben. Sonst: KEIN Commit.**
+
 ## Regeln
 - Ein Fix = ein Commit (atomic)
 - Kein Refactoring ohne klaren Grund

skills/gitea-implementierung/SKILL.md

@@ -39,6 +39,18 @@ git checkout -b feature/issue-<number>-<short-description>
 - Branch-Naming: `feature/issue-<number>-<short-description>`
 - Repo klonen falls nötig: `git clone https://git.home.kies-media.de/<owner>/<repo>.git /tmp/<repo>`
 
+### Main-Branch Rebase
+Bevor mit der Implementierung begonnen wird, prüfen ob sich `main` geändert hat:
+```bash
+git fetch origin
+git log --oneline HEAD..origin/main
+```
+Falls `main` neue Commits hat:
+```bash
+git rebase origin/main
+```
+Bei Konflikten: Auflösen, dann `git rebase --continue`. Bei komplexen Konflikten Martin informieren.
+
 ### Bestehenden Code erweitern
 - Bestehende Patterns und Konventionen beachten
 - Keine unnötigen Refactorings im gleichen PR
@@ -84,6 +96,50 @@ git checkout -b feature/issue-<number>-<short-description>
 - Formatter nutzen (Prettier, Black, etc.)
 - Projekt-spezifische Konventionen respektieren
 
+### Code-Quality-Gates (PFLICHT vor jedem Commit)
+
+**Schritt 1: Projekt-Linting (PFLICHT – Abbruch bei Fehlern)**
+
+Vor JEDEM Commit müssen ALLE konfigurierten Linter erfolgreich durchlaufen.
+Falls ein Linter fehlschlägt: **Commit abbrechen**, Fehler beheben, dann erneut versuchen.
+
+```bash
+# PHP Syntax Check
+find . -name "*.php" -not -path "*/vendor/*" -exec php -l {} \; 2>&1 | grep -v "No syntax errors"
+
+# CSS Lint (stylelint)
+npx stylelint "**/*.css" --config .stylelintrc.json --allow-empty-input
+
+# HTML Lint (htmlhint) – nur .html Dateien, nicht .php
+npx htmlhint "**/*.html" --config .htmlhintrc --ignore "**/*.php"
+
+# Projekt-spezifische Linter (falls vorhanden)
+npm run lint      # oder: npx eslint .
+python -m flake8 .
+```
+**Jeder Linter muss Exit-Code 0 zurückgeben. Sonst: KEIN Commit.**
+
+**Schritt 2: Dependency-Audit**
+```bash
+npm audit --audit-level=moderate  # Node.js
+pip audit                        # Python
+```
+Bei Critical/High Vulnerabilities: nicht committen, Martin informieren.
+
+**Schritt 3: Formatter ausführen**
+```bash
+npm run format    # oder: npx prettier --write .
+```
+
+**Schritt 4: Build prüfen (falls vorhanden)**
+```bash
+npm run build
+```
+Build muss erfolgreich sein.
+
+Diese Schritte sind **Pflicht** – kein Commit und kein PR ohne erfolgreichen Durchlauf.
+Ausnahme: Wenn das Projekt keine entsprechenden Tools konfiguriert hat, Martin informieren.
+
 ### Commits strukturieren
 - Kleine, atomare Commits
 - Conventional Commits Format: `type(scope): description`
@@ -94,9 +150,11 @@ git checkout -b feature/issue-<number>-<short-description>
 - Implementierter Code auf Feature Branch
 - Alle Commits sauber strukturiert
 - Code bereit für Review
+- **Label `Implementing` gesetzt** (kumulativ)
 - ⏩ Übergabe an **Code-Review-Agent**
 
 ## Regeln
 - Keine Secrets/Credentials im Code
 - Keine TODOs zurücklassen (außer mit Issue-Referenz)
 - Bei Blockern sofort Martin informieren
+- API-Calls müssen HTTP-Status prüfen – bei Fehlern abbrechen und Martin informieren

skills/gitea-merge-release/SKILL.md

@@ -30,10 +30,43 @@ curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/pull
 - PR-Beschreibung vollständig ausfüllen
 - Labels und Assignees setzen
 
+### Main-Stand prüfen & Rebase
+Bevor PR erstellt wird, prüfen ob `main` neue Commits hat:
+```bash
+git fetch origin
+git log --oneline HEAD..origin/main
+```
+Falls ja, Feature Branch auf aktuellen main rebasen:
+```bash
+git rebase origin/main
+git push --force-with-lease
+```
+Stellt sicher dass der PR konfliktfrei mergeable ist.
+
+### Linting-Gate (PFLICHT vor PR-Erstellung)
+
+**Vor JEDEM PR müssen ALLE konfigurierten Linter erfolgreich durchlaufen.**
+Falls ein Linter fehlschlägt: **PR abbrechen**, Fehler beheben, Linting wiederholen.
+
+```bash
+# PHP Syntax Check
+find . -name "*.php" -not -path "*/vendor/*" -exec php -l {} \; 2>&1 | grep -v "No syntax errors"
+
+# CSS Lint (stylelint)
+npx stylelint "**/*.css" --config .stylelintrc.json --allow-empty-input
+
+# HTML Lint (htmlhint) – nur .html Dateien, nicht .php
+npx htmlhint "**/*.html" --config .htmlhintrc --ignore "**/*.php"
+
+# Projekt-spezifische Linter (falls vorhanden)
+npm run lint
+```
+**Jeder Linter muss Exit-Code 0 zurückgeben. Sonst: KEIN PR erstellen.**
+
 ### Merge-Konflikte lösen
-- `main` in Feature Branch mergen
+- Falls beim Rebase Konflikte auftreten
 - Konflikte manuell auflösen
-- Sicherstellen dass Tests noch grün
+- `git rebase --continue`
 - Bei komplexen Konflikten: Martin involvieren
 
 ### Release Notes erstellen
@@ -81,10 +114,14 @@ git push origin v<version>
 
 ## Ausgang
 - PR erstellt und Martin informiert
+- **Label `ReadyForMerge` gesetzt** (kumulativ)
 - Warte auf Martins Merge-Freigabe
 - Nach Freigabe: ⏩ Abnahme- & Validierungs-Agent (Phase 6)
+- Zeit-Tracking: Dauer der Phase dokumentieren
 
 ## Regeln
 - **NIEMALS** ohne Martins Freigabe mergen
 - **NIEMALS** direkt auf `main` pushen
 - Release Notes IMMER vor dem Merge erstellen
+- API-Calls müssen HTTP-Status prüfen – bei Fehlern abbrechen und Martin informieren
+- **Nach Martins Merge:** Pipeline geht automatisch weiter mit Phase 6 (Abnahme) und Phase 7 (Closing). Martin darüber informieren.