legal-ops-germany

Open-Source-Library aus Claude-Skills und deterministischen Python-Executors für die
non-billable Workflows deutscher Boutique- und Kleinkanzleien — Fristenberechnung
(ZPO/BGB) mit Kalender-Export, Gebühren (RVG/GKG), GwG-Risikoklassifizierung mit
verifizierter Hochrisiko-Länderliste, Aktenkopf-Extraktion, Interessenkollisions-Check,
DATEV-EXTF-Export und mehr. 19 Skills, davon 1 getestet und 9 in beta (Status-Tabelle unten).
Funktionsweise ausschließlich nach deutschem Recht.

Keine Rechtsberatung. Diese Library unterstützt organisatorische und rechnerische
Abläufe der Kanzlei. Jedes Ergebnis unterliegt der Zweitkontrolle durch die Kanzlei;
Fristen- und Gebührenergebnisse ersetzen keine anwaltliche Kontrolle.

Unofficial & in aktiver Entwicklung. Unabhängiges Community-Projekt für
Claude Code — not affiliated with, endorsed,
or sponsored by Anthropic PBC; „Claude" und „Anthropic" sind Marken der
Anthropic PBC. Die Library wird laufend weiterentwickelt; Feedback, Issues
und Erfahrungsberichte sind ausdrücklich willkommen.

Zulässigkeit & Grenzen

Diese Library ist in Gänze Beta und kein geprüftes Produkt — es hat keine unabhängige
juristische oder aufsichtsrechtliche Prüfung stattgefunden. Das gilt auch dann, wenn ein Label „getestet" lautet oder von händischen oder automatisierten Testläufen gesprochen wird. Sie trifft keine Aussage
zur Zulässigkeit eines Einsatzes im konkreten Mandat oder Unternehmen. Ob und wie die
Skills produktiv genutzt werden dürfen, muss die Kanzlei vor dem Einsatz selbst prüfen —
insbesondere im Hinblick auf:

• Berufsrecht & Mandatsgeheimnis — §§ 203, 204 StGB, § 43a Abs. 2 / § 43e BRAO, § 2
  BORA, §§ 53, 97, 160a StPO.
• Datenschutz — DSGVO / BDSG, einschließlich Drittlandtransfer (Art. 44 ff. DSGVO)
  und der Reichweite von US Cloud Act / FISA beim gewählten Modell- und Hosting-Anbieter.
• KI-Verordnung — VO (EU) 2024/1689 (Risiko-Einstufung, Transparenz- und
  Betreiberpflichten).

Mandantendaten gehören ausschließlich in regulatorisch und technisch sichere Tools. Optionale Live-Anbindungen (vorhandene MCP-Konnektoren, z. B. Microsoft 365;
EU-/UN-Sanktionslisten geplant) geben Daten nach außen — Freigabe des jeweiligen
Datenflusses ist Sache der Kanzlei.

Wie es funktioniert

• Claude orchestriert, Python rechnet. Alles mit Zahlen, Daten, Fristen oder Geld
  wird von Executors in plugins/legal-ops/core/calc/
  deterministisch berechnet — nie vom Modell generiert.

• Datei rein, Datei raus. Jeder Skill arbeitet über Datei-Schnittstellen (CSV, PDF,
  EML, iCal, DATEV-EXTF, DOCX) — kompatibel mit dem Export/Import jeder Kanzleisoftware.
  Live-Anbindung ist optional und nutzt vorhandene MCP-Konnektoren (z. B.
  Microsoft 365), gebündelt in genau einem Skill (kontext-sync) — eigener
  Integrations-Code für Kanzleisoftware ist bewusst nicht enthalten (Verweis auf
  die API-Doku des Herstellers bzw. „Integration geplant").

• Kontext-Layer. Ein per-Kanzlei-Ordner kontext/ (Mandate, Kontakte,
  Kanzlei-Profil) ist die einzige Schnittstelle der Skills zu Kanzlei-Wissen —
  Details im Abschnitt Der Kontext-Layer.

• Ehrliche Labels. Jeder Skill trägt sichtbar seinen Reifegrad:

  • 🚧 Work-in-progress — noch nicht entwickelt (Stub) oder Code vorhanden, aber noch kein Test-Run.
  • 🧪 beta — gegen Testdaten durch Agenten getestet (Tests/Orakel-Fälle laufen grün in CI).
  • ✅ getestet — live (händisch) getestet durch den Maintainer, aber keine Garantie für die Funktionsweise in Production.

  Automatisierte Tests allein rechtfertigen höchstens beta; getestet ist eine ehrliche Live-Abnahme, kein Produktions-Freibrief.

• Berufsrechts-Gate. Jeder Skill dokumentiert im Frontmatter seine RDG-Einordnung,
  Datenhinweise (§ 203 StGB, DSGVO/BRAO) und Haftungsgrenzen — vom Lint erzwungen.

Hausregeln: CONVENTIONS.md · Struktur: ein Plugin
legal-ops bündelt alle Skills (fachlich in Prozessbereiche
plus Querschnitt gegliedert, Feld bereich: im Frontmatter) und die
geteilten Rechner unter plugins/legal-ops/core/ —
so ist core/ Teil der Auslieferung und jeder Executor-Skill nach dem Install
lauffähig.

Der Kontext-Layer

Die Skills brauchen Kanzlei-Wissen — Mandate, Parteien, Fristen, Kontakte. Statt dass jeder Skill selbst Kanzleisoftware anspricht, gibt es genau eine Schnittstelle: einen Ordner kontext/ mit Markdown-Dateien.

Kette: Kanzleisoftware / M365 → Adapter oder MCP-Sync → kontext/ → Skills. Kein Skill spricht Kanzleisoftware direkt an; ob dahinter DATEV, ein M365-Konnektor oder ein händischer Datei-Export steckt, ist den Skills egal.

Aufbau:

kontext/
  kanzlei.md        Kanzlei-Profil (Pflicht, formfrei — nur H1 wird geprüft)
  kontakte.md       Kontaktliste (empfohlen, formfrei)
  mandate/
    2026-001.md     ein File je Mandat — das einzige streng geschemte Format
  posteingang/      Rohdokumente eingehend (optional)
  export/           ausgehende Schreiben (optional)

Nur die Mandats-Datei hat ein striktes Schema, weil Rechenketten darauf aufbauen: Frontmatter mit az, mandant, stand (Pflicht) sowie gegenseite, streitwert, status, mandatsende. Letzteres speist den Retention-Executor — dieser markiert nach § 50 Abs. 1 BRAO, welche Unterlagen löschbar wären, löscht aber niemals automatisch. Vier Pflicht-Abschnitte runden das Schema ab: Parteien, Kommunikation, Letzter Schritt, Nächste Frist.

Zwei bewusst defensive Grenzen:

• PII-Minimierung: „Kommunikation" ist eine reine Verweis-Liste (Datum — Betreff — Link auf posteingang/), nie Volltext-Duplikat. kontext/ ist ein schlanker Index, keine zweite Aktenverwaltung.
• Keine Neuberechnung (P3): „Nächste Frist" enthält nur die iCal-UID aus dem fristenrechner-Export — Fristen rechnet ausschließlich der Executor.

Validierung: Nach jedem Sync läuft core/context/validator.py (Exit 0 sauber / 1 Schema-Fehler / 2 Ziel fehlt). Claude liest nur den JSON-Report und entscheidet nie selbst über Schema-Konformität. Fehlende empfohlene Felder sind Warnungen — abhängige Rechenketten weisen das Mandat dann als „nicht bewertbar" aus, statt zu blockieren.

Befüllung: Der Querschnitts-Skill kontext-sync speist zwei Wege: (1) vorhandene MCP-Konnektoren (z. B. Microsoft 365) oder (2) einen Filesystem-Referenzadapter für Daten, die schon als Dateien vorliegen — Pull/Push über Mapping-JSON mit Hash-Manifest für Idempotenz. Ein erkannter Konflikt wird nie automatisch aufgelöst — der Merge bleibt Kanzleisache. Der Filesystem-Adapter ist zugleich die Agnostik-Garantie: jeder künftige Adapter (DATEV, RA-MICRO, beA — „Integration geplant", kein Code im Repo) erfüllt denselben Vertrag und deklariert seine Fähigkeiten in einer capabilities.json (siehe core/adapters/).

Governance: Skills deklarieren ihre Zugriffe im Frontmatter (kontext_reads/kontext_writes) — vom Struktur-Lint in CI erzwungen. Details: core/context/README.md.

Skill-Status

Tabelle wird generiert von plugins/legal-ops/core/verify/struktur_lint.py (--write-readme).

Nutzung

Voraussetzung ist ein datenschutzkonformer Claude-Zugang der Kanzlei (z. B. Claude Code /
Cowork über AWS Bedrock, Region Frankfurt). Die Kanzlei lädt dieses Repo selbst — es gibt
kein Hosting und keine Datenhaltung durch die Library.

Weg 1 — mit Git (empfohlen, bekommt Updates): in Claude Code

/plugin marketplace add eliasreiche/legal-ops-germany
/plugin install legal-ops@legal-ops-germany

Aktualisieren später mit claude plugin marketplace update legal-ops-germany.

Weg 2 — per ZIP (ohne Git): auf der
Releases-Seite
beim aktuellen Release „Source code (zip)" laden, entpacken, dann in Claude Code:

/plugin marketplace add /pfad/zum/entpackten/ordner
/plugin install legal-ops@legal-ops-germany

Die ZIP-Installation ist ein eingefrorener Stand — sie aktualisiert sich
nicht. Für einen neuen Stand das ZIP des neuesten Release laden und den
Marketplace-Eintrag auf den neuen Ordner zeigen lassen.

Details je Skill im jeweiligen SKILL.md; Manifest:
marketplace.json.

Voraussetzungen

Python ≥ 3.x und pytest sind unter Entwicklung beschrieben
(nur zum Ausführen der Tests nötig, nicht für den Skill-Betrieb selbst).

Optionale System-Werkzeuge — je nachdem, welche eingehenden
Dokumentformate ein Skill verarbeiten soll:

# macOS
brew install poppler pandoc

# Debian/Ubuntu
apt-get install poppler-utils pandoc

Ohne diese Werkzeuge laufen die Executors unverändert weiter — sie
bündeln keine Binärabhängigkeiten (Claude-Code-Plugin = Skripte + Markdown).
Nur die Dokument-Konvertierung davor (PDF/DOCX → Text/Markdown) braucht dann
Handarbeit oder andere Werkzeuge.

Entwicklung

python3 plugins/legal-ops/core/verify/struktur_lint.py   # Struktur-Lint (P4/P5 + Containment)
pip install pytest && pytest -q                           # Tests (inkl. Install-Smoke-Test)

Lizenz

Apache-2.0 · Attributionen: NOTICE