Community Outreach & Solution Recommender
Ein anbieter-, LLM- und betriebssystemneutraler Skill zur automatisierten, lösungsorientierten Vorstellung von Open-Source-Software, Repositories und Werkzeugen in Entwickler-Communities, Reddit-Threads, Foren und Videokommentaren.
🌟 Kernprinzipien & Sicherheits-Garantien
- Human-in-the-Loop und fail-closed Veröffentlichung:
- Kein automatischer Post geht ohne menschliche Sichtung live.
- Entwürfe werden in
POST-EINGANG.md vorgelegt. Das Häkchen - [x] Genehmigt erlaubt nur den Veröffentlichungsversuch.
- Erst ein vollständiger, auf Plattform und Ziel-URL gebundener
PublishReceipt darf History, Rotation, Ausgang und Duplikatregister fortschreiben. Ohne angebundenen Publisher bleibt der Eintrag in der Queue.
- Anti-Spam & 100% Relevanz („Lieber kein Post als ein unpassender“):
- Jeder Post löst ein konkret im Ziel-Thread formuliertes technisches Problem.
- Strikte Beachtung der jeweiligen Community- und Plattformregeln (keine Schleichwerbung, transparente Nennung als Autor/Maintainer).
- Strikter Duplikatschutz:
posts_history.json und POSTVERZEICHNIS.md protokollieren jede durch Receipt belegte Ziel-URL.- Kein Thread oder Video wird jemals doppelt adressiert.
- Fair Round-Robin & Plattform-Rotation:
- Projekte werden nach längster Abstinenz rotiert (jedes Repo kommt gleichmäßig zum Zug).
- Plattformen werden abgewechselt (Reddit $\rightarrow$ YouTube $\rightarrow$ Dev.to / Fachforen $\rightarrow$ Reddit).
- Cut-and-Clue Selbstarchivierung:
- Historische Postausgänge werden bei Erreichen einer Größengrenze automatisch nach
_archive/ ausgelagert und im Header referenziert.
📂 Standard-Infrastruktur
Der Skill baut in einem Ziel-Verzeichnis (<workspace_root>/.COMMUNITY_OUTREACH/ o. ä.) folgende modulare Struktur auf:
| Datei |
Zweck |
USECASES.md |
Übersicht aller Repositories, deren Usecases und gelöster Zielprobleme |
usecases.json |
Maschinenlesbare Rotations-Datenbank mit Zeitstempeln und Metadaten |
POST-EINGANG.md |
Human-in-the-Loop Genehmigungs-Queue mit - [ ] Genehmigt Checkboxen |
POST-AUSGANG.md |
Monitoring veröffentlichter Beiträge und Inbound-Community-Feedback |
POSTVERZEICHNIS.md |
Globaler URL- und Thread-Duplikatschutz-Index |
ACCOUNTVERZEICHNIS.md |
Übersicht autorisierter Profile und SSO-Login-Mechanismen |
config.json |
Instanz-Konfiguration (Repos, Frequenzen, Zielplattformen) |
Die verifizierte Laufzeitbeschreibung liegt in references/runtime-readme.md.
🔄 Der 4-Phasen-Laufzyklus
flowchart TD
A[Start Laufzyklus] --> B[Phase 1: Monitoring-Inventar]
B --> C[Phase 2: Outbound Execution für freigegebene Posts]
C --> D[Phase 3: Research & Staging für nächstes Repo]
D --> E[Phase 4: Cut & Clue Selbstarchivierung]
E --> F[Abschluss & Logging]
- Phase 1 (Monitoring-Inventar): Zählt veröffentlichte History-Einträge als lokal zu prüfende Threads. Der Core ruft keine Plattformantworten ab; dafür wäre ein getrennter, autorisierter Inbound-Adapter nötig.
- Phase 2 (Outbound Execution): Prüft freigegebene Einträge, exakte URL-Duplikate und den angebundenen Publisher. Nur ein verifizierter
PublishReceipt löst lokale Zustandsänderungen aus. Der mitgelieferte CLI-Adapter veröffentlicht selbst nichts.
- Phase 3 (Research-Auftrag): Wählt via Fair Round-Robin das am längsten nicht bespielte Repo aus und liefert
needs-action. Erst eine getrennte Recherche darf eine echte, aktuelle und noch unbenutzte Ziel-URL sowie einen geprüften Entwurf in POST-EINGANG.md persistieren; Platzhalter werden nicht erzeugt.
- Phase 4 (Selbstarchivierung): Archiviert die ältesten vollständigen Einträge nach
_archive/, hält die neuesten Einträge live und ist bei Wiederholung idempotent.
Ein Lauf mit --dry-run ist eine reine Planberechnung: Er ruft keinen Publisher auf, verändert keine Datei und legt kein Verzeichnis an.
⚙️ Multi-Scheduler & Multi-Agent Betrieb
Der Skill unterstützt alle gängigen Scheduler- und Agentenumgebungen:
1. Antigravity Sidecar / Scheduled Task
Wird als nativer Sidecar in .gemini/config/sidecars/community-outreach/sidecar.json registriert.
- Vorteil: Läuft nur bei geöffneter App, vollständige Kontrolle im GUI-Dashboard.
- Frequenz: z. B. 1x täglich (
0 10 * * *) oder 4x täglich (0 8,12,16,20 * * *).
2. Codex & Claude Code / Cron
3. Windows Task Scheduler (schtasks)
📋 Schnellstart (Bootstrap)
- Workspace initialisieren:
python scripts/init_outreach_workspace.py --target-dir ./outreach_data --repo-list ./repos.json
- Portablen Runtime-Adapter projizieren:
python scripts/deploy_runtime.py --target ./outreach_data --json
Der Deploy kopiert nur Core, Adapter, Runtime-README und Runtime-Smoke-Test; Daten- und Queue-Dateien bleiben unberührt. --check prüft die Projektion ohne Schreibzugriff.
- Testlauf durchführen (Dry-Run):
python scripts/outreach_engine.py --workspace ./outreach_data --dry-run
Der Rückgabestatus bleibt needs-action, solange echte Recherche oder ein Publisher fehlt. Das ist kein Fehler und kein Veröffentlichungsbeleg.
- Scheduler aktivieren:
python scripts/setup_scheduler.py --backend antigravity --workspace ./outreach_data
🔒 Private / Lokale Konfiguration
Spezifische Pfade, Anmeldedaten und persönliche SSO-Profile werden in config.private.json oder .env gespeichert. Diese Dateien sind per .gitignore ausgeschlossen und gelangen niemals in öffentliche Repositories.
Changelog
1.1.0 (2026-08-29)
- Kanonischer Core mit dünnem Runtime-Adapter und kompatiblen Lesewegen für beide bisherigen Datenschemata.
- Fail-closed
PublishReceipt, exakter Duplikatschutz, byte-erhaltende Queue-Verarbeitung und wiederanlauffähige lokale Projektion.
- Schreibfreier Dry-Run, eintragsbasierte idempotente Archivierung und wahrheitsgemäßer
needs-action-Status für Phase 3.
1.0.0 (2026-08-13)
- Initiales Release: Universeller Community Outreach & Solution Recommender Skill.
- 4-Phasen-Engine mit Human-in-the-Loop, Duplikatschutz, Fair-Round-Robin und Cut-and-Clue Archivierung.
- Multi-Scheduler Support (Antigravity, Windows Task Scheduler, Cron, ellmos-scheduler, Codex, Claude Code).
1---2name: community-outreach3description: Systemneutrale Automatisierung für lösungsorientierten Community Outreach und Repo-Recommender in Foren, Reddit und Plattformen nach dem Human-in-the-Loop-Prinzip (EU AI Act konform).4---56<img src="banner.png" width="100%" alt="community-outreach banner">78# Community Outreach & Solution Recommender910Ein anbieter-, LLM- und betriebssystemneutraler Skill zur automatisierten, lösungsorientierten Vorstellung von Open-Source-Software, Repositories und Werkzeugen in Entwickler-Communities, Reddit-Threads, Foren und Videokommentaren.1112---1314## 🌟 Kernprinzipien & Sicherheits-Garantien15161. **Human-in-the-Loop und fail-closed Veröffentlichung:**17 * Kein automatischer Post geht ohne menschliche Sichtung live.18 * Entwürfe werden in `POST-EINGANG.md` vorgelegt. Das Häkchen `- [x] Genehmigt` erlaubt nur den Veröffentlichungsversuch.19 * Erst ein vollständiger, auf Plattform und Ziel-URL gebundener `PublishReceipt` darf History, Rotation, Ausgang und Duplikatregister fortschreiben. Ohne angebundenen Publisher bleibt der Eintrag in der Queue.202. **Anti-Spam & 100% Relevanz („Lieber kein Post als ein unpassender“):**21 * Jeder Post löst ein konkret im Ziel-Thread formuliertes technisches Problem.22 * Strikte Beachtung der jeweiligen Community- und Plattformregeln (keine Schleichwerbung, transparente Nennung als Autor/Maintainer).233. **Strikter Duplikatschutz:**24 * `posts_history.json` und `POSTVERZEICHNIS.md` protokollieren jede durch Receipt belegte Ziel-URL.25 * Kein Thread oder Video wird jemals doppelt adressiert.264. **Fair Round-Robin & Plattform-Rotation:**27 * Projekte werden nach längster Abstinenz rotiert (jedes Repo kommt gleichmäßig zum Zug).28 * Plattformen werden abgewechselt (Reddit $\rightarrow$ YouTube $\rightarrow$ Dev.to / Fachforen $\rightarrow$ Reddit).295. **Cut-and-Clue Selbstarchivierung:**30 * Historische Postausgänge werden bei Erreichen einer Größengrenze automatisch nach `_archive/` ausgelagert und im Header referenziert.3132---3334## 📂 Standard-Infrastruktur3536Der Skill baut in einem Ziel-Verzeichnis (`<workspace_root>/.COMMUNITY_OUTREACH/` o. ä.) folgende modulare Struktur auf:3738| Datei | Zweck |39| :--- | :--- |40| `USECASES.md` | Übersicht aller Repositories, deren Usecases und gelöster Zielprobleme |41| `usecases.json` | Maschinenlesbare Rotations-Datenbank mit Zeitstempeln und Metadaten |42| `POST-EINGANG.md` | Human-in-the-Loop Genehmigungs-Queue mit `- [ ] Genehmigt` Checkboxen |43| `POST-AUSGANG.md` | Monitoring veröffentlichter Beiträge und Inbound-Community-Feedback |44| `POSTVERZEICHNIS.md` | Globaler URL- und Thread-Duplikatschutz-Index |45| `ACCOUNTVERZEICHNIS.md` | Übersicht autorisierter Profile und SSO-Login-Mechanismen |46| `config.json` | Instanz-Konfiguration (Repos, Frequenzen, Zielplattformen) |4748Die verifizierte Laufzeitbeschreibung liegt in [`references/runtime-readme.md`](references/runtime-readme.md).4950---5152## 🔄 Der 4-Phasen-Laufzyklus5354```mermaid55flowchart TD56 A[Start Laufzyklus] --> B[Phase 1: Monitoring-Inventar]57 B --> C[Phase 2: Outbound Execution für freigegebene Posts]58 C --> D[Phase 3: Research & Staging für nächstes Repo]59 D --> E[Phase 4: Cut & Clue Selbstarchivierung]60 E --> F[Abschluss & Logging]61```62631. **Phase 1 (Monitoring-Inventar):** Zählt veröffentlichte History-Einträge als lokal zu prüfende Threads. Der Core ruft keine Plattformantworten ab; dafür wäre ein getrennter, autorisierter Inbound-Adapter nötig.642. **Phase 2 (Outbound Execution):** Prüft freigegebene Einträge, exakte URL-Duplikate und den angebundenen Publisher. Nur ein verifizierter `PublishReceipt` löst lokale Zustandsänderungen aus. Der mitgelieferte CLI-Adapter veröffentlicht selbst nichts.653. **Phase 3 (Research-Auftrag):** Wählt via Fair Round-Robin das am längsten nicht bespielte Repo aus und liefert `needs-action`. Erst eine getrennte Recherche darf eine echte, aktuelle und noch unbenutzte Ziel-URL sowie einen geprüften Entwurf in `POST-EINGANG.md` persistieren; Platzhalter werden nicht erzeugt.664. **Phase 4 (Selbstarchivierung):** Archiviert die ältesten vollständigen Einträge nach `_archive/`, hält die neuesten Einträge live und ist bei Wiederholung idempotent.6768Ein Lauf mit `--dry-run` ist eine reine Planberechnung: Er ruft keinen Publisher auf, verändert keine Datei und legt kein Verzeichnis an.6970---7172## ⚙️ Multi-Scheduler & Multi-Agent Betrieb7374Der Skill unterstützt alle gängigen Scheduler- und Agentenumgebungen:7576### 1. Antigravity Sidecar / Scheduled Task77Wird als nativer Sidecar in `.gemini/config/sidecars/community-outreach/sidecar.json` registriert.78* **Vorteil:** Läuft nur bei geöffneter App, vollständige Kontrolle im GUI-Dashboard.79* **Frequenz:** z. B. 1x täglich (`0 10 * * *`) oder 4x täglich (`0 8,12,16,20 * * *`).8081### 2. Codex & Claude Code / Cron82* Aufruf über eine CLI-Session oder einen vorhandenen Task-Runner:83 ```bash84 python scripts/outreach_engine.py --full-run85 ```8687### 3. Windows Task Scheduler (`schtasks`)88* Optional für autarke OS-Hintergrundausführung:89 ```powershell90 python scripts/setup_scheduler.py --backend windows --schedule 09:0091 ```9293## 📋 Schnellstart (Bootstrap)94951. **Workspace initialisieren:**96 ```bash97 python scripts/init_outreach_workspace.py --target-dir ./outreach_data --repo-list ./repos.json98 ```992. **Portablen Runtime-Adapter projizieren:**100 ```bash101 python scripts/deploy_runtime.py --target ./outreach_data --json102 ```103 Der Deploy kopiert nur Core, Adapter, Runtime-README und Runtime-Smoke-Test; Daten- und Queue-Dateien bleiben unberührt. `--check` prüft die Projektion ohne Schreibzugriff.1043. **Testlauf durchführen (Dry-Run):**105 ```bash106 python scripts/outreach_engine.py --workspace ./outreach_data --dry-run107 ```108 Der Rückgabestatus bleibt `needs-action`, solange echte Recherche oder ein Publisher fehlt. Das ist kein Fehler und kein Veröffentlichungsbeleg.1094. **Scheduler aktivieren:**110 ```bash111 python scripts/setup_scheduler.py --backend antigravity --workspace ./outreach_data112 ```113114---115116## 🔒 Private / Lokale Konfiguration117118Spezifische Pfade, Anmeldedaten und persönliche SSO-Profile werden in `config.private.json` oder `.env` gespeichert. Diese Dateien sind per `.gitignore` ausgeschlossen und gelangen niemals in öffentliche Repositories.119120---121122## Changelog123124### 1.1.0 (2026-08-29)125- Kanonischer Core mit dünnem Runtime-Adapter und kompatiblen Lesewegen für beide bisherigen Datenschemata.126- Fail-closed `PublishReceipt`, exakter Duplikatschutz, byte-erhaltende Queue-Verarbeitung und wiederanlauffähige lokale Projektion.127- Schreibfreier Dry-Run, eintragsbasierte idempotente Archivierung und wahrheitsgemäßer `needs-action`-Status für Phase 3.128129### 1.0.0 (2026-08-13)130- Initiales Release: Universeller Community Outreach & Solution Recommender Skill.131- 4-Phasen-Engine mit Human-in-the-Loop, Duplikatschutz, Fair-Round-Robin und Cut-and-Clue Archivierung.132- Multi-Scheduler Support (Antigravity, Windows Task Scheduler, Cron, ellmos-scheduler, Codex, Claude Code).
ellmos-ai