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/authz-idor-audit/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: authz-idor-audit
+description: >
+  Autorisierung einer App systematisch prüfen: Rollenmatrix aufstellen, jede Route gegen
+  Rollen und Objektbesitz abgleichen, IDOR- und Rechte-Lücken finden und als Tests abbilden.
+
+  TRIGGER WENN der User sagt: "IDOR", "Berechtigungen prüfen", "Rollen prüfen",
+  "wer darf was", "Rollenmatrix", "authz audit", "/authz-idor-audit", oder wenn neue
+  Endpunkte, Rollenänderungen, SSO/OIDC oder Team-/Mehrbenutzer-Funktionen dazukommen.
+
+  Ergebnis: Rollenmatrix, gefundene Lücken, neue Tests (erst rot, dann grün).
+---
+
+# authz-idor-audit
+
+Login allein schützt nichts: die häufigste Lücke in KI-Code ist „eingeloggt, aber sieht
+fremde Objekte“ (IDOR). Dieser Skill macht die Rechte explizit und testbar.
+
+## Ablauf
+
+### 1. Routen und Rollen erfassen
+- Alle Routen auflisten: FastAPI aus `app.openapi()["paths"]` (nicht aus `app.routes`,
+  eingebundene Router fehlen dort je nach Version), Express aus dem Routen-Inventar der
+  Baseline (`tests/security/routes.ts`) oder per `grep -rn "router\.\(get\|post\|put\|patch\|delete\)"`.
+- Rollen und Identitätsquelle aus dem Code ermitteln (Session, JWT, Proxy-Header, OIDC-Claims).
+
+### 2. Rollenmatrix aufstellen
+Pro Ressource und Aktion: wer darf? Zellen: `alle`, `eigene`, `Team`, `Admin`, `—`.
+```
+| Ressource      | Aktion | Mitarbeiter | Projektleiter | Admin |
+|----------------|--------|-------------|---------------|-------|
+| Projekt        | lesen  | zugewiesene | eigene        | alle  |
+| Projekt        | ändern | —           | eigene        | alle  |
+| Zuweisung      | anlegen| —           | eigene Proj.  | alle  |
+| Mitarbeiterdaten | lesen | sich selbst | Team        | alle  |
+```
+Unklare Zellen **nicht raten**, sondern dem User als Frage vorlegen. Die Matrix ist eine
+fachliche Entscheidung.
+
+### 3. Code gegen Matrix prüfen
+Pro Route: Wo genau wird die Matrix-Zelle durchgesetzt (Datei:Zeile)? Typische Lücken:
+- Objekt per ID geladen, Besitz nicht geprüft (lesen, ändern, löschen getrennt prüfen).
+- Liste ungefiltert, Filter nur im Frontend.
+- Fremdschlüssel im Body (`project_id`, `owner`, `leader`, `role`) wird übernommen.
+- Rechte nur im UI ausgeblendet, API offen.
+- Prüfung im GET vorhanden, im PATCH/DELETE vergessen.
+
+### 4. Tests schreiben (zuerst rot)
+Für jede Lücke und jede Matrix-Zelle mit Einschränkung ein Test mit **zwei** synthetischen
+Nutzern derselben Rolle (A besitzt, B nicht):
+- B liest/ändert/löscht Objekt von A → 403 oder 404
+- Liste von B enthält kein Objekt von A
+- B setzt im Body fremde `owner`/`project_id` → 403/422
+Bei eingebauter Baseline: Fälle in `IDOR_CASES` bzw. `MASS_ASSIGNMENT_CASES` der
+`conftest.py` / `security.config.ts` ergänzen. Test laufen lassen, **roten Lauf zeigen**,
+dann Code fixen, dann grün.
+
+### 5. Gegenprobe
+Eine der neuen Prüfungen im Code kurz auskommentieren → mindestens ein Test muss rot
+werden → zurücknehmen. Ohne diesen Nachweis gilt der Test als unbewiesen.
+
+## Ausgabe
+1. Rollenmatrix (mit offenen Fragen markiert)
+2. Lückentabelle: `| Route | Methode | Matrix sagt | Code macht | Datei:Zeile | Prio |`
+3. Liste der neuen Tests + Ergebnis roter/grüner Lauf + Gegenprobe