Add agent security skills for Codex and Claude Code

Same skills in .agents/skills (Codex) and .claude/skills (Claude Code):
codeguard, security-review, dependency-vetting, pre-release-gate,
authz-idor-audit, threat-model-light. Source: cj/claude-skills.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.claude/skills/threat-model-light/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: threat-model-light
+description: >
+  Leichtgewichtiges Threat-Model für eine App oder ein Feature: Assets, Angreifer, Vertrauensgrenzen,
+  Risiken mit Maßnahme und prüfbarem Beleg. Eine Seite, kein STRIDE-Roman.
+
+  TRIGGER WENN der User sagt: "Threat Model", "Bedrohungsanalyse", "was kann schiefgehen",
+  "Risiken", "/threat-model-light", zum Projektstart, oder bevor ein Feature mit Login, Rollen,
+  Zahlungen, Uploads, externen Schnittstellen oder personenbezogenen/Gesundheitsdaten gebaut wird.
+
+  Ergebnis: Risikotabelle mit Maßnahme und Beleg pro Risiko, als docs/THREATMODEL.md im Repo.
+---
+
+# threat-model-light
+
+## Ablauf
+1. **System skizzieren** (aus Code und Compose, nicht raten): Komponenten, Ports, Proxy
+   (Caddy/Authelia?), Datenbank, externe Dienste, wer sich wie anmeldet. Eine Zeile pro
+   Datenfluss: `Browser → Caddy → App:3141 → SQLite`.
+2. **Assets:** Was ist schützenswert? (Personendaten, Arbeitszeiten, Abwesenheiten, Zugangsdaten,
+   Kundendaten, Verfügbarkeit). Gesundheitsdaten (z. B. „krank“) und Daten Dritter markieren.
+3. **Angreifer:** anonym aus dem Internet, eingeloggter Nutzer mit niedriger Rolle, Kollege mit
+   gleicher Rolle (IDOR!), jemand im LAN am Proxy vorbei, kompromittiertes Paket, KI-Agent mit
+   Schreibrechten.
+4. **Vertrauensgrenzen** markieren: wo wird Identität festgestellt, wo geprüft, wo nur vertraut?
+   Typische Lücke: App vertraut einem Header, den nur der Proxy setzen sollte, Port ist aber
+   direkt erreichbar.
+5. **Risiken** je Grenze und Asset. Für jedes Risiko eine **konkrete Maßnahme** und einen
+   **prüfbaren Beleg** (Test, Scan, Konfiguration). Risiko ohne Beleg = offen.
+6. **Datensparsamkeit:** Für jedes sensible Feld fragen: brauchen wir es? Neutrale Alternative
+   (z. B. „abwesend“ statt „krank“) spart Datenschutzaufwand.
+
+## Ausgabe: `docs/THREATMODEL.md`
+```
+# Threat-Model <App> (Stand <Datum>)
+## System
+<Datenflüsse, eine Zeile je Fluss>
+## Assets
+| Asset | Schutzbedarf | Bemerkung |
+## Risiken
+| # | Risiko | Angreifer | Wirkung | Prio | Maßnahme | Beleg | Status |
+| 1 | Identitäts-Header fälschbar | LAN | Vollzugriff | K | Shared Secret + Port nur intern | Spoofing-Test, compose ports | offen |
+## Offene Entscheidungen
+<fachliche Fragen an den User, z. B. Rollenmatrix, Speicherung Abwesenheitsgrund>
+```
+Prioritäten wie ASVS-light: K / H / M. Offene K-Risiken blockieren den Release (`pre-release-gate`).
+Danach: Risiken mit Status „offen“ als Tests umsetzen (`authz-idor-audit`, `test-baseline-setup`).