docs: replace ASCII umlaut fallbacks with proper äöüß across all .md

Most German docs were written with `ue`/`ae`/`oe`/`ss` ASCII fallbacks
(`fuer`, `aenderung`, `koennen`, `gemaess`) — relic from older toolchain
constraints. Replaced 237 occurrences across 38 .md files with proper
umlauts and ß so the docs read naturally.

Substitutions are constrained to plain prose: fenced code blocks
(```...```), inline code spans (`...`), markdown link targets `[..](..)`,
and HTML comments are preserved verbatim. Path references like
`docs/howto-erste-aenderung.md` keep their original (umlaut-replaced)
filenames — only the surrounding prose is normalised.

Tool: bin/fix-md-umlauts.py (idempotent — no-op on already-clean files).
Re-runnable if ASCII fallbacks creep back in via copy-paste.

Doc-link-check + doc-drift-check stay green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.agents/skills/core-guardrails/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: core-guardrails
-description: Verbindliche Guardrails fuer Architektur-, Refactor-, Zentralisierungs-, Standardisierungs- und Implementierungsaufgaben in diesem Starterkit. Verwenden, wenn Code geaendert, neu strukturiert oder gegen bestehende Layer-/UI-/Security-Standards geprueft werden soll.
+description: Verbindliche Guardrails für Architektur-, Refactor-, Zentralisierungs-, Standardisierungs- und Implementierungsaufgaben in diesem Starterkit. Verwenden, wenn Code geändert, neu strukturiert oder gegen bestehende Layer-/UI-/Security-Standards geprüft werden soll.
 ---
 
 # Core Guardrails
@@ -12,21 +12,21 @@ Durchgaengig dieselben technischen Grenzen durchsetzen, damit Core robust, wartb
 ## Verbindliche Regeln
 
 1. MUST Layering einhalten (`pages` -> `Service` -> `Repository`, Templates nur Rendering).
-2. MUST Request/Input/Validation-Contract einhalten (`requestInput()`, `FormErrors`, API-Validation ueber `ApiResponse::validationFromFormErrors(...)`, kein `ApiResponse::readJsonBody(...)` in `pages/api/v1/**`, keine direkten Superglobals in `pages/**`).
-3. MUST AuthZ/RBAC serverseitig durchsetzen und im UI nur ueber `$viewAuth` steuern.
-4. MUST Security-Guards einhalten (CSRF auf POST-Endpunkten, keine unredacted PII/Secrets in Logs/Audit-Meta, SQL nur vorbereitet ueber Repository).
-5. MUST UI-Standards und Data-Contracts fuer Listen/Detailseiten nutzen (Wrapper, Partials, globaler Confirm-Dialog statt `window.confirm`, inklusive globaler Grid-Standards fuer rowInteraction/pageSize).
-6. MUST Frontend-Hardcuts einhalten (keine inline ESM-Module in Templates/Pages, JS-`src` mit `assetVersion(...)`, zentrale Telemetrie fuer relevante Frontend-Warnings/Fetch-Fehler).
-7. MUST Quality-Gates ausfuehren und Ergebnis transparent berichten.
-8. MUST bei Konflikten den regelkonformen Weg waehlen oder den Konflikt als Blocker markieren.
+2. MUST Request/Input/Validation-Contract einhalten (`requestInput()`, `FormErrors`, API-Validation über `ApiResponse::validationFromFormErrors(...)`, kein `ApiResponse::readJsonBody(...)` in `pages/api/v1/**`, keine direkten Superglobals in `pages/**`).
+3. MUST AuthZ/RBAC serverseitig durchsetzen und im UI nur über `$viewAuth` steuern.
+4. MUST Security-Guards einhalten (CSRF auf POST-Endpunkten, keine unredacted PII/Secrets in Logs/Audit-Meta, SQL nur vorbereitet über Repository).
+5. MUST UI-Standards und Data-Contracts für Listen/Detailseiten nutzen (Wrapper, Partials, globaler Confirm-Dialog statt `window.confirm`, inklusive globaler Grid-Standards für rowInteraction/pageSize).
+6. MUST Frontend-Hardcuts einhalten (keine inline ESM-Module in Templates/Pages, JS-`src` mit `assetVersion(...)`, zentrale Telemetrie für relevante Frontend-Warnings/Fetch-Fehler).
+7. MUST Quality-Gates ausführen und Ergebnis transparent berichten.
+8. MUST bei Konflikten den regelkonformen Weg wählen oder den Konflikt als Blocker markieren.
 9. MUST NOT Extension-Architektur erfinden; dieses Thema ist aktuell Out of Scope.
 
 ## Vorgehen je Aufgabe
 
 1. Scope bestimmen (`core`, `ui`, `api`, `mixed`).
 2. Vorhandene Contracts zuerst suchen, dann wiederverwenden.
-3. Aenderung minimal halten, keine Seiteneffekte ohne Grund.
-4. Nach Aenderung die relevanten Gates ausfuehren.
+3. Änderung minimal halten, keine Seiteneffekte ohne Grund.
+4. Nach Änderung die relevanten Gates ausführen.
 5. Rest-Risiken explizit benennen.
 
 ## Out of Scope

.agents/skills/core-guardrails/references/boundaries-core.md

@@ -16,18 +16,18 @@
 
 ## Input / Validation
 
-1. MUST Input in `pages/**` ueber `requestInput()` lesen.
+1. MUST Input in `pages/**` über `requestInput()` lesen.
 2. MUST NOT `$_POST`, `$_GET`, `$_FILES`, `REQUEST_METHOD` in `pages/**` verwenden.
 3. MUST NOT `$_SESSION`, `$_SERVER`, `$_COOKIE`, `$_ENV` in `pages/**` direkt verwenden.
-4. MUST Form-Validation ueber `FormErrors` fuehren.
-5. MUST API-Validation-Fehler ueber `ApiResponse::validationFromFormErrors(...)` ausgeben.
+4. MUST Form-Validation über `FormErrors` führen.
+5. MUST API-Validation-Fehler über `ApiResponse::validationFromFormErrors(...)` ausgeben.
 6. MUST NOT `ApiResponse::readJsonBody(...)` in `pages/api/v1/**` verwenden.
 
 ## List-Data Endpoints
 
 1. MUST `pages/**/data().php` als GET-only Endpunkte umsetzen (`gridRequireGetRequest()`).
-2. MUST Query-Filter ueber `gridParseFilters(...)` + `filter-schema.php` normalisieren.
-3. MUST NOT Query-Filter inline/parallele Alias-Parser in `data().php` neu einfuehren.
+2. MUST Query-Filter über `gridParseFilters(...)` + `filter-schema.php` normalisieren.
+3. MUST NOT Query-Filter inline/parallele Alias-Parser in `data().php` neu einführen.
 
 ## Security / API
 
@@ -35,11 +35,11 @@
 2. MUST Tenant-Scope serverseitig erzwingen.
 3. MUST CSRF auf POST-Endpunkten vor Body-Verarbeitung verifizieren.
 4. MUST NOT PII/Secrets unredacted in Logs oder Audit-Metadata schreiben.
-5. MUST SQL nur ueber Repository mit prepared statements ausfuehren.
+5. MUST SQL nur über Repository mit prepared statements ausführen.
 6. MUST extern UUID-first bleiben.
 7. MUST API-Fehler konsistent halten (`error`, optional `errors`).
-8. MUST OpenAPI im selben Merge aktualisieren, wenn API geaendert wird.
+8. MUST OpenAPI im selben Merge aktualisieren, wenn API geändert wird.
 
-## Pruef-Hinweis
+## Prüf-Hinweis
 
 - Harte Repo-Gates: `tests/Architecture/CoreStarterkitContractTest.php`

.agents/skills/core-guardrails/references/boundaries-ui.md

@@ -2,69 +2,69 @@
 
 ## Listen-Standard
 
-1. MUST Listen ueber `initStandardListPage(...)` initialisieren.
-2. MUST Filter-Toolbar ueber zentrale Helper/Partials rendern.
-3. MUST aktive Chips/Drawer-Verhalten ueber Standard-Contracts laufen lassen.
+1. MUST Listen über `initStandardListPage(...)` initialisieren.
+2. MUST Filter-Toolbar über zentrale Helper/Partials rendern.
+3. MUST aktive Chips/Drawer-Verhalten über Standard-Contracts laufen lassen.
 4. MUST NOT direkt `gridFiltersFromSchema(...)` oder `initListFilterExperience(...)` in Listen-Templates verwenden.
 5. MUST NOT Legacy-Filter-Toggle-Markup (`data-toolbar-toggle`, `data-filter-overflow`, `data-filter-toggle`) neu einbauen.
-6. MUST rowInteraction-Standard fuer Listen mit Row-Navigation beibehalten (sichtbare Action-Spalte + Enter + Doppelklick-Fallback).
+6. MUST rowInteraction-Standard für Listen mit Row-Navigation beibehalten (sichtbare Action-Spalte + Enter + Doppelklick-Fallback).
 7. MUST pageSize-Standard beibehalten (10/25/50/100, Toolbar rechts, URL > localStorage > default).
 
 ## Detailseiten-Standard
 
 1. MUST Hauptformular mit `data-standard-detail-form="1"` markieren.
-2. MUST Unsaved/Shortcut/Dirty-State ueber `initStandardDetailPage(...)` nutzen.
-3. MUST Detail-Aktionen ueber Action-Policy-Contract (`data-detail-action-policy`, `data-detail-action-kind`, `data-detail-confirm-message`) steuern.
+2. MUST Unsaved/Shortcut/Dirty-State über `initStandardDetailPage(...)` nutzen.
+3. MUST Detail-Aktionen über Action-Policy-Contract (`data-detail-action-policy`, `data-detail-action-kind`, `data-detail-confirm-message`) steuern.
 4. MUST NOT inline `confirm(...)` (`onclick` / `onsubmit`) auf standardisierten Detailseiten nutzen.
 
 ## Confirm + Telemetry Standard
 
-1. MUST Confirm-Dialoge zentral ueber den globalen Confirm-Service abwickeln.
+1. MUST Confirm-Dialoge zentral über den globalen Confirm-Service abwickeln.
 2. MUST NOT `window.confirm(...)` in App-JS oder inline HTML-Handlern verwenden.
-3. MUST relevante Frontend-Warnpfade zentral ueber Frontend-Telemetrie erfassen.
+3. MUST relevante Frontend-Warnpfade zentral über Frontend-Telemetrie erfassen.
 4. MUST NOT relevante UX-/Fehlerpfade nur als Console-Warnung implementieren.
 
 ## Frontend Page-Module Hard Cut
 
-1. MUST Seiteninitialisierung ueber dedizierte Module unter `web/js/pages/*` umsetzen.
-2. MUST Page-Config ueber `script[type="application/json"]` + `readPageConfig(...)` bereitstellen/lesen.
-3. MUST alle JS-`src` in `pages/**` und `templates/**` ueber `assetVersion('...js...')` laden.
+1. MUST Seiteninitialisierung über dedizierte Module unter `web/js/pages/*` umsetzen.
+2. MUST Page-Config über `script[type="application/json"]` + `readPageConfig(...)` bereitstellen/lesen.
+3. MUST alle JS-`src` in `pages/**` und `templates/**` über `assetVersion('...js...')` laden.
 4. MUST NOT inline `<script type="module">...</script>` in `pages/**` oder `templates/**` verwenden.
 
 ## Component Lifecycle Runtime
 
-1. MUST migrierte Komponenten ueber `init(root, config)` + `destroy()` standardisieren.
+1. MUST migrierte Komponenten über `init(root, config)` + `destroy()` standardisieren.
 2. MUST NOT migrierte Komponenten per `DOMContentLoaded`/Module-Sideeffect selbst auto-initialisieren.
 3. MUST Listener, Timer und Observer, die in `init(...)` entstehen, in `destroy()` wieder abbauen.
-4. MUST Runtime-Konfiguration ueber Page-Config (`readPageConfig(...)`) beziehen, keine verteilten Ad-hoc-Globals.
-5. MUST host-gebundene UI-Komponenten ueber explizite `data-app-component`-Hosts im Markup binden.
-6. Global-Utilities ohne natuerliches Host-Element MAY via Runtime `scope: 'global'` registriert werden, MUESSEN aber denselben Lifecycle-Contract inkl. `destroy()` einhalten.
+4. MUST Runtime-Konfiguration über Page-Config (`readPageConfig(...)`) beziehen, keine verteilten Ad-hoc-Globals.
+5. MUST host-gebundene UI-Komponenten über explizite `data-app-component`-Hosts im Markup binden.
+6. Global-Utilities ohne natürliches Host-Element MAY via Runtime `scope: 'global'` registriert werden, MÜSSEN aber denselben Lifecycle-Contract inkl. `destroy()` einhalten.
 
 ## Shared Partials
 
-1. MUST Listen-Titlebar ueber `templates/partials/app-list-titlebar.phtml` rendern.
-2. MUST List-Tabs ueber `templates/partials/app-list-tabs.phtml` rendern.
-3. MUST Purge-Action ueber `templates/partials/app-list-purge-action.phtml` rendern.
-4. MUST Detail-Validation-Summary ueber `templates/partials/app-details-validation-summary.phtml` rendern.
+1. MUST Listen-Titlebar über `templates/partials/app-list-titlebar.phtml` rendern.
+2. MUST List-Tabs über `templates/partials/app-list-tabs.phtml` rendern.
+3. MUST Purge-Action über `templates/partials/app-list-purge-action.phtml` rendern.
+4. MUST Detail-Validation-Summary über `templates/partials/app-details-validation-summary.phtml` rendern.
 
 ## RBAC in Templates
 
-1. MUST UI-Capabilities nur ueber `$viewAuth` lesen.
+1. MUST UI-Capabilities nur über `$viewAuth` lesen.
 2. MUST NOT `can('...')` in Templates verwenden.
 
 ## CSS Boundaries
 
-1. MUST Styles moeglichst lokal in `web/css/components`, `web/css/layout` oder `web/css/pages` halten.
-2. MUST NOT globale unscoped Overrides ohne klaren Scope einfuehren.
+1. MUST Styles möglichst lokal in `web/css/components`, `web/css/layout` oder `web/css/pages` halten.
+2. MUST NOT globale unscoped Overrides ohne klaren Scope einführen.
 3. MUST Vendor-Overrides nur in `web/css/vendor-overrides/**` pflegen.
 4. MUST bestehende CSS-Variablen bevorzugen statt neue Inline-Farbwerte zu verteilen.
 
 ## Komponenten in Formularen
 
-1. MUST Core-Button-Klassen (`secondary outline small`, `danger outline small`) verwenden statt Custom-Button-CSS. Custom-CSS nur fuer Layout (z.B. `border-radius: 50%`).
+1. MUST Core-Button-Klassen (`secondary outline small`, `danger outline small`) verwenden statt Custom-Button-CSS. Custom-CSS nur für Layout (z.B. `border-radius: 50%`).
 2. MUST `margin-bottom: 0` auf Buttons, Inputs, Selects und Labels innerhalb selbststaendiger Komponenten in Formularen resetten (Core setzt `margin-bottom: var(--app-spacing)` global).
 3. MUST Checkboxen in Flex-Containern mit expliziter Groesse (`width: 1.25em; height: 1.25em`) und `flex-shrink: 0` versehen (Core nutzt `appearance: none` mit Custom-Sizing).
 4. MUST `position: sticky` mit `top: calc(var(--app-topbar-height) + ...)` verwenden, nicht `top: 0` (Topbar ist sticky).
 5. MUST Icon-Only-Buttons mit `data-tooltip` und `aria-label` versehen.
 6. MUST bei `grid-template-columns` mit mehr als einer Spalte ein `@media`-Fallback auf Single-Column definieren.
-7. MUST bestehende `--app-*` CSS-Variablen fuer Farben verwenden, nie Farbwerte hardcoden.
+7. MUST bestehende `--app-*` CSS-Variablen für Farben verwenden, nie Farbwerte hardcoden.

.agents/skills/core-guardrails/references/quality-gates.md

@@ -29,18 +29,18 @@ Erwartung: jeweils `0`.
 
 ## JS-Scope
 
-- Bei JS-Aenderungen Browser-Smoke mit DevTools-Console durchfuehren.
+- Bei JS-Änderungen Browser-Smoke mit DevTools-Console durchführen.
 - Erwartung: keine neuen JS-Errors.
 
 ## Docs-/Skills-Gates (schnell)
 
 1. `bin/docs-link-check.sh`
-   - prueft Doku-Links in `README.md`, `docs/**`, `.agents/skills/**` und `.agents/**`
-   - `.agents/runs/**` ist standardmaessig ausgeschlossen (historische Artefakte)
+   - prüft Doku-Links in `README.md`, `docs/**`, `.agents/skills/**` und `.agents/**`
+   - `.agents/runs/**` ist standardmäßig ausgeschlossen (historische Artefakte)
 2. `bin/docs-drift-check.sh`
-   - prueft bekannte Legacy-Drifts (entfernte Config-Pfade/Constants, obsolete Search-Marker)
+   - prüft bekannte Legacy-Drifts (entfernte Config-Pfade/Constants, obsolete Search-Marker)
 3. `bin/codex-skills-sync.sh --check`
-   - prueft Drift zwischen Repo-Skills und `~/.codex/skills`
+   - prüft Drift zwischen Repo-Skills und `~/.codex/skills`
 
 ## Berichtspflicht
 

.agents/skills/starterkit-grid-standards/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: starterkit-grid-standards
-description: Standardisierungs-Skill fuer GridJS-Listen im Starterkit. Verwenden, wenn Listen neu gebaut oder refactored werden sollen (rowInteraction, pageSize, filter drawer, URL-state, accessibility).
+description: Standardisierungs-Skill für GridJS-Listen im Starterkit. Verwenden, wenn Listen neu gebaut oder refactored werden sollen (rowInteraction, pageSize, filter drawer, URL-state, accessibility).
 ---
 
 # Starterkit Grid Standards
@@ -18,18 +18,18 @@ GridJS-Listen projektweit einheitlich, zuganglich und wartbar halten.
 ## Verbindliche Regeln
 
 1. MUST `initStandardListPage(...)` als Standard nutzen (nur begruendete Ausnahmen direkt mit `createServerGrid(...)`).
-2. MUST `rowDblClick.getUrl(...)` fuer zeilenbezogene Navigation setzen, wenn Row-Navigation vorgesehen ist.
+2. MUST `rowDblClick.getUrl(...)` für zeilenbezogene Navigation setzen, wenn Row-Navigation vorgesehen ist.
 3. MUST globale `rowInteraction`-Defaults respektieren (Action-Spalte, Enter, Doppelklick-Fallback).
 4. MUST globale `pageSize`-Standards respektieren (`10/25/50/100`, Toolbar-Placement, URL > storage > default).
-5. MUST Filter-Drawer/Chips ueber den Standard-Contract nutzen, keine parallelen Custom-Patterns.
+5. MUST Filter-Drawer/Chips über den Standard-Contract nutzen, keine parallelen Custom-Patterns.
 6. MUST NOT pro Seite eigene Row-Action-Hacks bauen, wenn der Factory-Contract ausreicht.
 
 ## Vorgehen
 
-1. Ist-Liste gegen `references/list-checklist.md` pruefen.
+1. Ist-Liste gegen `references/list-checklist.md` prüfen.
 2. Fehlende Standards zuerst zentral in der Factory loesen, danach nur minimale Seitenanpassungen.
 3. UI/CSS nur als additive Erweiterung zu bestehenden Komponenten.
-4. Relevante Gates und Browser-Smoke (Keyboard + Console) ausfuehren.
+4. Relevante Gates und Browser-Smoke (Keyboard + Console) ausführen.
 
 ## Referenzen
 

.agents/skills/starterkit-grid-standards/references/list-checklist.md

@@ -3,19 +3,19 @@
 ## Bootstrap
 
 1. `initStandardListPage({ grid, filters, hooks })` verwendet.
-2. `filterSchema` aus Server-Config uebergeben.
+2. `filterSchema` aus Server-Config übergeben.
 3. `urlSync` bewusst gesetzt.
 
 ## Interaction
 
 1. `rowDblClick.getUrl(...)` liefert stabile Ziel-URL oder leer.
 2. Keine Doppel-Action-Spalte (Factory auto-action vs explizite actions).
-3. Enter/Pointer/Focus fuer oeffnbare Rows funktionieren.
+3. Enter/Pointer/Focus für öffnbare Rows funktionieren.
 
 ## Pagination + URL
 
 1. Page-size Optionen nur `10/25/50/100`.
-2. URL Sync pruefen (`page`, `order`, `dir`, `limit`).
+2. URL Sync prüfen (`page`, `order`, `dir`, `limit`).
 3. Default-Werte erzeugen saubere URL.
 
 ## Filter UX
@@ -26,5 +26,5 @@
 
 ## Regression
 
-1. Sortierung, Selection/Bulk, Doppelklick unveraendert.
+1. Sortierung, Selection/Bulk, Doppelklick unverändert.
 2. Keine neuen Console Errors.

.agents/skills/starterkit-grid-standards/references/page-size-standard.md

@@ -15,6 +15,6 @@
 
 ## Verhalten
 
-1. Aenderung der Seitengroesse setzt Seite auf 1.
+1. Änderung der Seitengroesse setzt Seite auf 1.
 2. Sortierung/Filter bleiben erhalten.
 3. LocalStorage-Key pro Tabelle (path + dataUrl + container).

.agents/skills/starterkit-grid-standards/references/row-interaction-standard.md

@@ -8,7 +8,7 @@ Row-Navigation discoverable und keyboard-freundlich machen.
 
 1. Konfigurierbares Link-Column: Die primaere Datenspalte (z.B. Name, Beschreibung) wird als klickbarer `<a>`-Link gerendert.
 2. Enter auf fokussierter Row loest dieselbe Navigation aus.
-3. Doppelklick bleibt als Fallback fuer Power-User.
+3. Doppelklick bleibt als Fallback für Power-User.
 4. Nur Rows mit Ziel-URL erhalten `data-row-open-url` und den Link im Link-Column.
 5. Rows ohne URL (z.B. fehlende Berechtigung) zeigen den Inhalt als Plain-Text ohne Link.
 
@@ -40,6 +40,6 @@ rowInteraction: {
 ## Guardrails
 
 1. Keine globale Tab-Stop-Flut auf allen Rows.
-2. Fokusstil fuer Row und Link-Element sichtbar.
-3. Explizite `actions.enabled: true` pro Seite darf Link-Column uebersteuern (eigene Action-Spalte).
+2. Fokusstil für Row und Link-Element sichtbar.
+3. Explizite `actions.enabled: true` pro Seite darf Link-Column übersteuern (eigene Action-Spalte).
 4. Link-Column darf keine Spalte mit verschachtelten `<a>`-Elementen umwickeln (z.B. Avatar mit Lightbox).

.agents/skills/starterkit-php-style-ci/SKILL.md

@@ -1,24 +1,24 @@
 ---
 name: starterkit-php-style-ci
-description: Standard-Skill fuer PHP Coding-Style im Starterkit (php-cs-fixer, dry-run in CI, lokaler fix/check workflow). Verwenden bei Style-Einfuehrung, CI-Checks oder grossen Format-Diffs.
+description: Standard-Skill für PHP Coding-Style im Starterkit (php-cs-fixer, dry-run in CI, lokaler fix/check workflow). Verwenden bei Style-Einführung, CI-Checks oder grossen Format-Diffs.
 ---
 
 # Starterkit PHP Style CI
 
 ## Ziel
 
-Coding-Style pruefbar, reproduzierbar und regressionsarm machen.
+Coding-Style prüfbar, reproduzierbar und regressionsarm machen.
 
 ## Wann verwenden
 
-1. Einfuehrung oder Nachschaerfung von Style-Regeln.
-2. CI-Dry-Run fuer Style-Checks.
+1. Einführung oder Nachschaerfung von Style-Regeln.
+2. CI-Dry-Run für Style-Checks.
 3. Aufraeumen grosser Style-Diff-Wellen.
 
 ## Verbindliche Regeln
 
-1. MUST `vendor/bin/php-cs-fixer fix --config=tools/php-cs-fixer/.php-cs-fixer.dist.php --dry-run --diff --verbose` fuer nicht-mutierende Pruefung nutzen (Convenience-Alias: `composer cs:check`).
-2. MUST `composer cs:fix` nur bewusst und mit Diff-Kontrolle ausfuehren.
+1. MUST `vendor/bin/php-cs-fixer fix --config=tools/php-cs-fixer/.php-cs-fixer.dist.php --dry-run --diff --verbose` für nicht-mutierende Prüfung nutzen (Convenience-Alias: `composer cs:check`).
+2. MUST `composer cs:fix` nur bewusst und mit Diff-Kontrolle ausführen.
 3. MUST Style-Check vor Merge gruen halten (lokal und optional CI).
 4. MUST nach groesseren Fixes mindestens `phpunit` und `phpstan` laufen lassen.
 5. MUST NOT manuell Einzelstellen formatieren, wenn der Fixer sie zentral loesen kann.
@@ -26,8 +26,8 @@ Coding-Style pruefbar, reproduzierbar und regressionsarm machen.
 ## Workflow
 
 1. Baseline erfassen: `vendor/bin/php-cs-fixer fix --config=tools/php-cs-fixer/.php-cs-fixer.dist.php --dry-run --diff --verbose`.
-2. Falls noetig fixen: `composer cs:fix`.
-3. Diff fokussiert pruefen (Imports, Braces, Nebenwirkungen).
+2. Falls nötig fixen: `composer cs:fix`.
+3. Diff fokussiert prüfen (Imports, Braces, Nebenwirkungen).
 4. Qualitaetsgates laufen lassen.
 5. CI-Dry-Run konfigurieren oder validieren.
 

.agents/skills/starterkit-php-style-ci/references/ci-dry-run.md

@@ -2,7 +2,7 @@
 
 ## Ziel
 
-CI soll nur pruefen, nicht formatieren.
+CI soll nur prüfen, nicht formatieren.
 
 ## Minimaler Check
 
@@ -13,7 +13,7 @@ vendor/bin/php-cs-fixer fix --config=tools/php-cs-fixer/.php-cs-fixer.dist.php -
 ## Erwartung
 
 1. Exit Code 0: Style konform.
-2. Exit Code != 0: Diff ausgeben, Entwickler fuehrt lokal `composer cs:fix` aus.
+2. Exit Code != 0: Diff ausgeben, Entwickler führt lokal `composer cs:fix` aus.
 
 ## Hinweise
 

.agents/skills/starterkit-php-style-ci/references/style-workflow.md

@@ -11,7 +11,7 @@ composer cs:fix
 
 1. Erst Style-Check laufen lassen (`vendor/bin/php-cs-fixer fix --config=tools/php-cs-fixer/.php-cs-fixer.dist.php --dry-run --diff --verbose`).
 2. Danach `cs:fix`.
-3. Nur relevante Diffs uebernehmen, grosse Misch-Diffs vermeiden.
+3. Nur relevante Diffs übernehmen, grosse Misch-Diffs vermeiden.
 4. Anschliessend:
 
 ```bash

.agents/skills/starterkit-planner/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: starterkit-planner
-description: Planungs-Skill fuer Architektur-, Rollout-, Refactor- und Standardisierungsaufgaben im Starterkit. Verwenden, wenn ein decision-complete Plan mit klaren Interfaces, Tests, Risiken und Annahmen benoetigt wird.
+description: Planungs-Skill für Architektur-, Rollout-, Refactor- und Standardisierungsaufgaben im Starterkit. Verwenden, wenn ein decision-complete Plan mit klaren Interfaces, Tests, Risiken und Annahmen benötigt wird.
 ---
 
 # Starterkit Planner
 
 ## Ziel
 
-Planungen so strukturieren, dass Implementierung ohne offene Entscheidungen moeglich ist.
+Planungen so strukturieren, dass Implementierung ohne offene Entscheidungen möglich ist.
 Bei Agent-Workflows muss der Plan maschinenlesbar in die Projekt-Contracts passen.
 
 ## Verbindliches Ausgabeformat
@@ -23,9 +23,9 @@ Bei Agent-Workflows muss der Plan maschinenlesbar in die Projekt-Contracts passe
 Wenn `.agents/` verwendet wird:
 
 1. Plan muss dem Schema `.agents/contracts/planner.schema.json` entsprechen.
-2. Success Criteria muessen stabile IDs tragen (`SC-001`, `SC-002`, ...).
-3. Success Criteria muessen so formuliert sein, dass Reviewer Acceptance sie direkt gegen `criterion_id` pruefen kann.
-4. Guard- und Quality-Gate-IDs muessen aus den Katalogen kommen (`GR-*`, `QG-*`).
+2. Success Criteria müssen stabile IDs tragen (`SC-001`, `SC-002`, ...).
+3. Success Criteria müssen so formuliert sein, dass Reviewer Acceptance sie direkt gegen `criterion_id` prüfen kann.
+4. Guard- und Quality-Gate-IDs müssen aus den Katalogen kommen (`GR-*`, `QG-*`).
 
 ## Vorgehen
 
@@ -33,7 +33,7 @@ Wenn `.agents/` verwendet wird:
 2. Entscheidungen mit Tradeoffs transparent machen.
 3. Oeffentliche Contracts explizit benennen.
 4. Success Criteria frueh mit stabilen IDs (`SC-*`) definieren.
-5. Reihenfolge und Rollout so planen, dass Rueckbau moeglich bleibt.
+5. Reihenfolge und Rollout so planen, dass Rueckbau möglich bleibt.
 6. Teststrategie nach Risiko priorisieren.
 
 ## Qualitaetskriterien
@@ -42,7 +42,7 @@ Wenn `.agents/` verwendet wird:
 2. Jeder betroffene Bereich hat klare Akzeptanzkriterien mit stabiler ID (`SC-*`).
 3. Risiken sind priorisiert und beobachtbar.
 4. Ungeklaerte Themen stehen explizit unter Annahmen.
-5. Guard-/Gate-Referenzen sind vollstaendig und pruefbar (`GR-*`, `QG-*`).
+5. Guard-/Gate-Referenzen sind vollstaendig und prüfbar (`GR-*`, `QG-*`).
 
 ## Out of Scope
 

.agents/skills/starterkit-planner/references/tradeoff-matrix.md

@@ -19,7 +19,7 @@
 ### Option B: Shared Partial/Helper
 
 - Vorteile: Schneller Nutzen, moderates Risiko
-- Nachteile: Teilweise Restduplikate moeglich
+- Nachteile: Teilweise Restduplikate möglich
 - Geeignet wenn: Wiederkehrendes UI-/Glue-Muster mit klaren Datencontracts
 
 ### Option C: Lokal belassen