Skill-Bundle für nachvollziehbare Office-, Wissens- und Verwaltungsarbeit nach dem Dual-Evidence-Ansatz — mit föderierter System Map, hermetischer Testsuite und dokumentierten Fachverträgen.
Der Root-SKILL.md ist ein Router: Er wählt einen Fach-Desk aus,
ersetzt ihn aber nicht. Das Bundle ist kein Agent-Workspace und bringt keine eigene
Workspace-Control-Plane oder Agent-Lifecycle-Verwaltung mit.
| Sub-Skill | Einsatzbereich | Nicht zuständig für |
|---|---|---|
| 🗂 cloud-atlas | Projekt- und Topic-Cloudspeicher, Konvertierung, Filemaps und lokale Markdown-Mirrors | Projekt-/Topic-Katalogeinträge |
| 📮 mail-desk | Fachliche Bearbeitung einzelner Mails sowie Batch-/Stapelverarbeitung (draft→execute→verify): Routing, Reply-/Todo-Entscheidungen, Anhang-Bewertung und leichte Mail-Logs |
Mailbox-Transport und vollständige Aufgaben-Triage |
| 📅 calendar-desk | CalDAV-Kalenderabfragen, Terminplanung, Slot-Suche, ETag-Preconditions und Zwei-Phasen-Write (Einladungs-Responses als CD-5 vorbereitet) | Dokumentation eines gesamten Events |
| 🎥 meeting-desk | Intake, Klassifikation, Evidenz und Nachbereitung einzelner Meetings, Konferenzschaltungen und Vorträge | Dokumentation eines gesamten größeren Events |
| 📰 event-documentation | Konferenzen, Tagungen und Seminare mit Programm, Aufzeichnungen und Action-Item-Triage | allgemeiner Meeting-Intake außerhalb eines Events |
| ✅ task-desk | Action-Item-Extraktion, Priorisierung, Deduplizierung und Vorbereitung der Aufgaben-Synchronisation | Mailbox-Routing oder Pflege von Katalogstrukturen |
| 🏭 project-catalog-entry | projects.json und zugehörige Projektarbeits- und Wissensstruktur |
Topic-/Subtopic-Katalogpflege |
| 🧭 topic-catalog-entry | topics.json und zugehörige Topic-/Subtopic-Arbeits- und Wissensstruktur |
Projektkatalogpflege |
Important
mail-desk ist grundsätzlich ein kontrollierter Fall-für-Fall-Workflow; Batch- und
Stapelverarbeitung (draft→execute→verify) läuft fachlich durch den mail-desk-Skill —
der Batch-Runner und seine Werkzeuge setzen dessen Verträge durch (Review-Hash-Bindung,
Final-Index-Hardrules, JSON-Manifest-Client, Katalogpflege-Router). Jede Mail
durchläuft denselben vollständigen Compliance-Flow; die Desk-Regeln bestimmen die
Grenzen. Consumer-Pipelines (z. B. eine Batch-SOP im konsumierenden Workspace) laden
vor allen Phasen die Pflicht-Referenzen des Skills und ersetzen sie nicht —
„Pipeline und Fachvertrag".
Installiere oder verlinke den vollständigen Ordner office-intelligence/ einschließlich
aller acht Ordner unter skills/. Öffne zunächst den Root-SKILL.md und
danach nur den für die konkrete Aufgabe passenden Sub-Skill. Konsumierende Workspaces
stellen ihre eigenen Kataloge, Evidenz- und Datenpfade bereit; die dort geltenden
Workspace-Regeln bleiben maßgeblich.
Warning
Vor einer Mutation im konsumierenden Workspace ist dessen workspace-lock mit einer
Lease des ausführenden Harnesses erforderlich. Lesende Auswertungen sind lockfrei.
Die automatischen Writer erlauben keinen lockfreien Legacy-Bypass.
Python 3 und die separate, vertrauenswürdige
workspace-lock-Installation sind
für schreibende Tools erforderlich. Guard und CLI werden dort in place benutzt,
nicht ins Bundle kopiert. Das private Skills-Superprojekt wird nicht benötigt.
Die Clone-Anleitung setzt Leserechte für beide Repositories voraus; insbesondere
ist die separate workspace-lock-Quelle derzeit zugangsbeschränkt. Nutzer ohne
Zugriff benötigen eine vom Betreiber freigegebene Bezugsquelle, bevor sie Writer
nutzen können. Das Bundle veröffentlicht oder ersetzt den Guard nicht selbst.
git clone https://github.com/martinderm/office-intelligence.git
git clone https://github.com/martinderm/workspace-lock.git
Mit diesen beiden parallelen Ordnern funktioniert der Sibling-Fallback. Bei einer
anderen Anordnung setze im aufrufenden Harness WORKSPACE_LOCK_ROOT auf den
Installationsordner, der scripts/workspace_lock_guard.py enthält (nicht auf das
Skript selbst):
export WORKSPACE_LOCK_ROOT="$(pwd)/workspace-lock"$env:WORKSPACE_LOCK_ROOT = (Resolve-Path ./workspace-lock).PathReihenfolge: expliziter API-/CLI-Installationspfad, WORKSPACE_LOCK_ROOT, vorhandene
Desk-Aliase (EVENT_DOCUMENTATION_WORKSPACE_LOCK_ROOT,
MEETING_DESK_WORKSPACE_LOCK_ROOT, MAIL_DESK_DIAGNOSTIC_WORKSPACE_LOCK_ROOT),
zuletzt ausschließlich ../workspace-lock relativ zum installierten Bundle.
Event-/Meeting-CLI: --workspace-lock-root; Cloud-Refresh-API:
workspace_lock_root. Ein gesetzter ungültiger Pfad wird nicht durch einen
Fallback ersetzt. Keine Suche nach ausführbarem Guard-Code im aktuellen
Arbeitsverzeichnis, keine Pfade aus Mails, Records oder Handoffs.
Fehlt die Installation, verweigert der Schreibpfad die Mutation mit Hinweis auf
WORKSPACE_LOCK_ROOT und diese Anleitung. Cloud-Refresh behält
reason: lock_unavailable und liefert in diesem Setup-Fall zusätzlich das
hashgebundene Feld installation_guidance. Ein ausgewählter Guard ersetzt keine
Lease: Der Harness muss im Consumer, nicht im Bundle, vorab seine eigene
aktive Lease über scripts/invoke_workspace_lock.py erwerben und nach dem Lauf
freigeben. Es gibt keine Ersatz-Locks und keine automatische Lease-Übernahme.
Regeln für Beiträge und Tests stehen in CONTRIBUTING.md.
Die acht oben aufgeführten Ordner sind die Mitglieder dieses Bundles. Technische Adapter gehören nicht dazu und werden bei Bedarf separat eingebunden:
| Zweck | Adapter (separat einzubinden) |
|---|---|
| Meeting-Intake | fireflies-api, zoom-api |
| Aufgaben-Sync | todoist-api |
| Mailbox-Zugriff | Gmail-, Himalaya- oder IMAP-Adapter |
Die fachliche Entscheidung bleibt jeweils beim zuständigen Office-Intelligence-Desk.
Die Katalog-Desks arbeiten mit memory/references/projects/projects.json und
memory/references/topics/topics.json. Fachliche Struktur liegt in den zugehörigen
Projekt- und Topic-Unterordnern; operative Nachweise bleiben von diesen Referenzen
getrennt. Konkrete Pfade, Formate und Schreibregeln sind absichtlich nur in den
zuständigen Sub-Skills beschrieben.
Für Entwickler, Refactorings und Coding-Agenten (wie Daedalus) existiert eine vollständige, föderierte System Map nach ICM Form 6:
| Ebene | Karte | Inhalt |
|---|---|---|
| L1 | Paket System Map | Router, Zusammenspiel der 8 Desks, Data Zones, Bundle-Invarianten |
| L2 | Mail-Desk System Map | Quarantäne-Engine, Himalaya-Adapter, Batch-Runner/-Verträge, Dossier-Modi |
| L2 | Cloud-Atlas System Map | Filemap-Generierung, Dokumentkonvertierung, OCR-Verzweigung |
| L2 | Calendar-Desk System Map | CalDAV-Client, RFC-5545-Codec, Free/Busy-Engine, Zwei-Phasen-Write (plan/apply), ETag-Preconditions, Journal |
Ein kompaktes Änderungsprotokoll liegt im CHANGELOG.md; abgeschlossene
Feature Requests im historischen
Archiv. Einziger aktiver Backlog sind die
GitHub Issues;
Arbeitsstatus und Run-Abnahme stehen im jeweiligen Issue/PR, aktuelle Verträge
weiterhin in den Fachreferenzen und System Maps.