daily-briefing

name	daily-briefing
description	Tägliches Briefing zu Beginn jeder Session — System-Status, letzte Aktivität, offene Punkte, Cron-Status.
version	1.0.0
author	Yuno
license	MIT
lane	koenigin
reasoning_effort	xhigh

Daily Briefing

Lade diese Skill zu Beginn jeder Session mit dem Benutzer (the user). Führe das Briefing durch, bevor du mit Aufgaben beginnst.

Ablauf

0. Skill-Loading (Duplicate Name Resolution)

⚠️ Bekanntes Problem: Es gibt ZWEI daily-briefing Skills:

• ~/.hermes/skills/productivity/daily-briefing/SKILL.md
• ~/.hermes/skills/skills/productivity/daily-briefing/SKILL.md

skill_view(name='daily-briefing') schlägt fehl mit "Ambiguous skill name". Fix: Immer den QUALIFIZIERTEN Pfad nutzen: skill_view(name='productivity/daily-briefing').

1. Letzte Session abrufen

Nutze session_search(limit=2, query="") (browse-Modus) um die letzten 1-2 Sessions zu finden. Lies die bookend_start + bookend_end der aktuellsten Session um zu sehen was zuletzt gemacht wurde und ob was offen blieb.

1.1. Context-Gap nach Modellwechsel (WICHTIG)

Wenn der User nach einem Modellwechsel einen spezifischen Begriff/eine Version/ein Feature nennt (z.B. "V6", "Option 1+2+3", "Phase 4"), das du nicht in der Session-History oder im Briefing findest:

1. Max 2 gezielte session_search-Queries — einen Discovery-Call mit dem Begriff, ggf. einen zweiten mit Synonym
2. Memory/Mnemosyne prüfen — memory(action='list', target='memory') oder mnemosyne_recall(query='...')
3. Schnelle System-Checks — grep -ri "V6" ~/relevant/path/ (1-2 max, nicht tief)
4. Nicht gefunden → FRAGEN. Sofort clarify(choices=[...]) mit 2-4 Optionen. Kein weiteres Session-Scrollen.
5. NIEMALS: große Session-Transcripts (>50KB) scrollen um einen Begriff zu finden. Das kostet >5000 Tokens pro Scroll-Call und produziert selten Treffer. Lies stattdessen bookend_start + bookend_end der letzten relevanten Session — da stehen Goal + Resolution drin.
6. NIEMALS: session_search(limit=10) — 5 ist die Obergrenze. Bei 10 kommen Sessions die nichts mit dem Thema zu tun haben.

Warum: Diese Session hat 10+ session_search- + 8 terminal-Calls + Hunderttausende Bytes Output verbraucht, nur um einen Begriff ("V6") zu finden den es nicht gab. Ein clarify() nach 2 Minuten hätte das verhindert.

2. Cron-Jobs prüfen

Nutze cronjob(action='list') um den Status der aktiven Cronjobs zu prüfen. Achte auf:

• Fehlgeschlagene Läufe (last_status)
• Bevorstehende Läufe (next_run_at)
• Ob einer kürzlich gelaufen ist und Ergebnisse hatte
• delivery_error Feld — auch wenn last_status=ok, kann die Telegram-Delivery fehlschlagen!

⚠️ WICHTIG: Die nachfolgende Tabelle ist ein SNAPSHOT — NIE als aktuell behandeln! IMMER live prüfen.

the user's aktive Cronjobs (Stand 2026-07-03 nach Fix — IMMER live validieren!):

Job	Zeit	Modus	Deliver	Status
yuno-morning-briefing	08:00 täglich	LLM (daily-briefing)	origin	✅
yuno-mittags-check	12:00 täglich	LLM (daily-briefing)	local	⚠️ error → fixed
yuno-abend-wrapup	18:00 täglich	LLM (daily-briefing)	local	⚠️ error → fixed
gateway-watchdog	stündlich	Script	local	✅
hermes-network-monitor	alle 15 Min	Script	local	✅
mnemosyne-sleep	04:00 täglich	Script	local	✅
mnemosyne-backup	stündlich	Script	local	✅
gmail-organizer	08:00 sonntags	Script	telegram	✅
orch-hourly-audit	stündlich	Script	telegram	✅
orch-weekly-improve	04:00 sonntags	Script	telegram	✅
orch-weekly-pipeline	05:00 sonntags	Script	local	✅
greyhack-ci-watch (MaxClaw)	stündlich	LLM (greyhack)	telegram:7222661188	⚠️ Model-Error #44585
greyhack-tool-builder (MaxClaw)	alle 2h	LLM (greyhack)	telegram:7222661188	✅
github-pr-monitor (MaxClaw)	09:00 + 17:00 täglich	LLM	telegram:7222661188	✅
greyhack-mobil-watchdog (NEU 2026-07-04)	alle 2h	LLM (skill-navigator)	telegram:7222661188	✅
Todoist Weekly Review	Mo 09:00	LLM (daily-briefing)	local	⚠️ error → fixed

2.2. Cron Delivery "Chat not found" Detection

Wenn last_status=ok UND last_delivery_error="Telegram send failed: Chat not found" (oder ähnlich):

• Bedeutung: Cron lief durch, Inhalt wurde generiert, aber Gateway konnte nicht in den Home-Channel senden.
• Häufigste Ursache: ~/.hermes/.env (TELEGRAM_HOME_CHANNEL=@username) überschreibt config.yaml (home_channel: <numerische_id>). .env gewinnt immer. Bei Username-Versand via Bot kann das Home-Channel-Mapping fehlschlagen, selbst wenn allowed_chats korrekt gesetzt ist.
• Diagnose-Schritte (read-only zuerst):
  1. grep -E "TELEGRAM_HOME_CHANNEL|home_channel|TELEGRAM_ALLOWED_USERS|allowed_chats" ~/.hermes/.env ~/.hermes/config.yaml — vergleichen, Mismatch suchen
  2. Direkttest mit curl (entscheidet, ob Token + Chat-ID überhaupt ok sind):

set -euo pipefail TOKEN=$(grep ^TELEGRAM_BOT_TOKEN ~/.hermes/.env | cut -d= -f2-) curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage"
-d "chat_id=<numerische_id>" -d "text=test" ``` → {"ok":true,...} heißt: Token + Chat-ID funktionieren direkt. Dann liegt's an der Hermes-Gateway-Home-Channel-Logik (= meist .env-Override). 3. Gateway-Log checken: journalctl --user -u hermes-gateway --no-pager -n 50 | grep -A1 "home-channel\|Chat not found" — bestätigt, ob Gateway selbst die .env-Einstellung nutzt.

• Fix (nur nach Bestätigung des Mismatch):

set -euo pipefail

Numerische Chat-ID in .env setzen (BEIDE Felder, nicht nur home_channel!)

sed -i 's/^TELEGRAM_HOME_CHANNEL=@./TELEGRAM_HOME_CHANNEL=<numerische_id>/' ~/.hermes/.env sed -i 's/^TELEGRAM_ALLOWED_USERS=@./TELEGRAM_ALLOWED_USERS=<numerische_id>/' ~/.hermes/.env systemctl --user restart hermes-gateway.service

- **Verify:** `cronjob(action='run', job_id=<id>)` triggert Job manuell, prüft `last_delivery_error`.
- **Cross-Reference:** the user's Memory hält das gleiche Pattern fest: _"Telegram Config: `telegram.allowed_chats` AND `telegram.home_channel` in config.yaml are PRIMARY. .env can override config.yaml — check BOTH."_

**Pitfall:** Nicht nur `home_channel` fixen — auch `allowed_chats` und `TELEGRAM_ALLOWED_USERS` müssen als numerische ID vorliegen, sonst greift der DM-Filter und blockt weiter.

**Letzte Änderungen (chronologisch):**

**2026-07-04:**
- `greyhack-mobil-watchdog` (job_id `6003e431dad7`, alle 2h) NEU
LLM-watchdog für yuno_mobil-Setup-Bundle: checkt greyhack-tools + hermes-v7
auf neue Files, meldet nur bei Änderung via Telegram
- `greyhack-ci-watch` (MaxClaw, job_id `6732ae8278ce`) Model-Error → pausiert
Yuno's Duplikat-Cron `a167de38428d` pausiert um Doppel-Sends zu vermeiden.
Lesson: **Immer `hermes cron list` VOR `cron create`** — Cron-Namen sind global

**2026-07-03:**
- `yuno-mittags-check` (job_id `14b4ed9fbc42`, 12:00 täglich): `deliver` → `local`
LLM-generierter Mittags-Check, Output > 10KB → Telegram-Send-Timeout
- `yuno-abend-wrapup` (job_id `e7f24d9bb484`, 18:00 täglich): `deliver` → `local`
LLM-generierter Wrap-up, gleiches Timeout-Problem
- Todoist Weekly Review (job_id `08ff393b7004`, Mo 09:00): `deliver` → `local`
LLM-generierter Todoist-Review, Output > 10KB
- **Pattern:** Alle 3 sind **LLM-Cronjobs** (kein `no_agent=true` Script!) mit
großen Reports. Telegram-Timeout trifft sowohl Skript- als auch Agent-Output.
→ Fix identisch: `deliver='local'`, Output landet in `~/.hermes/cron-output/`

**2026-06-28:**
- `orch-weekly-pipeline`: `deliver` von `telegram:7222661188` → `local`
Pipeline lieferte ~14KB stdout → Telegram-Send-Timeout (30s).
Fix: Nur lokales Logging. Logs unter `~/.hermes/orchestrator-*.log`.

**Script-Pfade (Stand 2026-06-28):**
- Live-Skripte: `~/.hermes/scripts/` (NICHT `~/scripts/`)
- Orchestrator: `~/.hermes/scripts/orchestrator-*.sh`
- Mnemosyne-Logs: `~/.hermes/orchestrator-*.log`

**Deprecatete/entfernte Jobs:**
- `esl-tech-news`, `greyscripts-daily-status`, `greyhack-daily-scan`, `greyhack-daily-fix` — existieren nicht mehr

### 2.1. Cron Delivery Error Detection

Wenn `last_status=ok` ABER `last_delivery_error` gesetzt ist — oder ein
Cron-Job schlicht nicht ankommt — immer **drei Patterns** checken:

| Pattern | Error-Stichwort | Diagnose | Detail |
|---|---|---|---|---|
| 1 | `Telegram send failed: Chat not found` | `TELEGRAM_HOME_CHANNEL`/`ALLOWED_USERS` auf `@username` statt numerischer `chat_id` | `references/telegram-delivery-errors.md` |
| 2 | `Telegram send failed: Timed out` | Output (Script ODER LLM-Agent) > ~10KB → Gateway-Send-Timeout (30s) | siehe unten |
| 3 | `Provider authentication failed` / `HTTP 401` | API-Key in `.env` tot | `references/telegram-delivery-errors.md` |

**Volle Diagnostic-Befehle + Fix-Schritte:** `references/telegram-delivery-errors.md`

**Pattern 2 (Timed out) — Kurzfassung:**
- **Ursache:** Job lief erfolgreich, aber Output > ~10KB verursacht Gateway-Send-Timeout
- **Fix:** `cronjob(action='update', job_id=..., deliver='local')` — Output bleibt lokal
- **Alternative:** Script/Job umbauen auf "silent on success" Pattern (nur bei Alerts output generieren)
- **Relevante Jobs:** Alle Jobs (Script ODER LLM-Agent) mit `deliver=telegram` die >5KB Output produzieren

### 2.5. Tech/Cybersecurity News (optional)
Wenn aktuell relevant oder the user fragt:
- `curl https://www.bleepingcomputer.com/news/security/` für Security-News
- ODER: `web_search("cybersecurity news today", limit=3)` für aktuelle Incidents
- Nur einfließen lassen, wenn the user explizit nach fragt oder Bedeutendes passiert



### 2.7. Container/Docker-Awareness (NEU V1.1)
Wenn Hermes in einem Docker-Container läuft (Working directory = `/root`, Home = `/root`):
- `sysdoctor check` zeigt CONTAINER-Metriken, nicht Host!
- Cron-Jobs kommen vom HOST (werden via Hermes API injected, nicht via Dateisystem)
- `search_files` im Host-Pfad zeigt nicht die Host-Dateien
- Platten-Check zeigt Container-Overlay, nicht Host-SSD
→ **Bei System-Werten IMMER prüfen: Ist das der Container oder der Host?**
→ **Für System-Status besser:** `df -h /`, `free -h`, `uptime` statt `sysdoctor check`

### 3. System-Schnellcheck
Führe `df -h /`, `free -h`, `uptime` aus und fasse in EINEM Satz zusammen:
- Plattenbelegung (relevanteste Partition)
- RAM-Auslastung
- Load average

**Optional: Service-Status** — Wenn the user kürzlich gezockt hat oder Services auffällig sein könnten, prüf kurz ollama + tokentelemetry via `systemctl --user is-active`. Details und Toleranzen: `references/system-services-check.md`.

Nur erwähnen wenn etwas AUFFÄLLIG ist (Platte >80%, RAM >80%, >10 Updates).

### 4. Briefing ausgeben

Formatiere das Briefing als:

set -euo pipefail ╔══════════════════════════════════════╗ ║ ☕ YUNO'S DAILY BRIEFING ║ ║ ║ ╚══════════════════════════════════════╝

📋 LETZTES MAL: <was wir gemacht haben, 2-3 Zeilen>

⏰ CRONS: <Status der Cronjobs, wenn auffällig> (optional: "Nichts auffälliges" wenn alles läuft)

🖥️ SYSTEM: <ein Satz, nur bei Auffälligkeiten>

─── Bin bereit! Was steht an?

### Wichtige Regeln
- Das Briefing muss KURZ sein — max 10-15 Zeilen Text
- Nicht jede Kleinigkeit erwähnen, nur Relevantes
- Den Yuno-Ton wahren (kreativ/humorvoll, (kappa))
- Wenn System unauffällig, den System-Teil ganz weglassen
- Cron-Teil weglassen wenn keine Cronjobs existieren oder alle grün sind
- Bei vielen offenen Punkten aus letzter Session: den wichtigsten nennen, dann fragen ob sie den Faden aufnehmen wollen

### Telegram Morning Briefing (Cron Job, delivery: "origin")

Für das `yuno-morning-briefing` und ähnliche Telegram-Cron-Jobs mit `delivery: "origin"`:
Das Format hat **drei feste Sektionen** (ESL/CS2, Tech & Security, Gaming) mit strikten Constraints
(~2500 Zeichen, Deutsch, Yuno-Ton, keine offenen Fragen, kein `send_message`).

**Volle Spezifikation:** `references/telegram-morning-briefing-format.md`

Quick pattern:
1. Run MorphReader: `python3 ~/scripts/morphreader_summary_v6.py --no-cve-ids --days 1`
2. Fallback-Datei: `~/scripts/morphreader-briefing.md`
3. Web-Recherche wenn MorphReader leer: `curl` zu HLTV RSS + BleepingComputer
**Volle Spezifikation:** `references/telegram-morning-briefing-format.md`

### Delivery-Probleme (BadRequest, last_delivery_error)

Wenn Crons `last_delivery_error: "Telegram send failed: Chat not found"` oder ähnliches zeigen, ist die Troubleshooting-Tabelle in **`references/cron-delivery-patterns.md`** (Sektion "Troubleshooting") der schnellste Weg zur Lösung. Deckt u.a.:

- `.env` überschreibt `config.yaml` (`.env` wins)
- `@username` vs numerische `chat_id` in `TELEGRAM_HOME_CHANNEL`
- Gateway-Restart-Ordering (erster Restart nach `.env`-Patch kann noch alten Wert laden)
- `cronjob(action='update')` ohne Feld-Updates gibt "No updates provided"

### Esports / Tech News Briefing (Cron Job)

For the dedicated `esports-tech-briefing` cron job, use the resilient multi-source fallback chain. Key principle: **never rely on a single source** — HLTV and Liquipedia are frequently Cloudflare-blocked.

Full fallback recipes and source-specific curl commands: see `references/hltv-liquipedia-esports-research.md` in the `research-tools` skill.

Quick pattern:
1. Try `web_search` + `web_extract` first
2. If blocked → `curl` to **HLTV RSS** (`https://www.hltv.org/rss/news`) for esports titles (works without Cloudflare!)
3. If security news needed → `curl` to **BleepingComputer** (`https://www.bleepingcomputer.com/news/security/`)
4. If all fail → read local cache `~/Schreibtisch/wichtigsten Nachrichten.md` for last known state
5. Always note which sources were unavailable in the output

### Efficiency Notes

- **System check:** `sysdoctor check` is the preferred tool. It does disk/RAM/temp/GPU/cache/kernel/updates in one call. Fallback: manual `df -h`, `free -h`, `sensors`.
- **Gmail check:** Use server-side SEARCH (FROM/BEFORE/SUBJECT via IMAP), NOT one-by-one header fetch. Example:
  ```python
  conn.search(None, '(FROM "noreply")')     # instant
  conn.fetch(msg_id, '(BODY.PEEK[...])')     # slow - avoid for bulk

Server-side SEARCH is ~100x faster than fetching headers individually.

• Cron job check: Always use cronjob(action='list'). Check last_status and last_run_at to see if jobs ran.
• ⚠️ web_search Firecrawl-Fallback: web_search kann mit 'NoneType' object has no attribute 'status_code' fehlschlagen (Firecrawl-Backend offline). Sofort auf curl umsteigen — HLTV RSS und BleepingComputer sind direkt per curl erreichbar und oft zuverlässiger als die Such-API. web_extract generiert zudem manchmal kaputte URLs (/v2/scrape statt voller URL) — für RSS/HTML immer direkt curl nutzen.

Referenzen

• references/briefing-template.md — Vorlage zum Kopieren, Session-Such-Guide, Cron-Checkliste, System-Schwellwerte
• references/telegram-morning-briefing-format.md — Telegram Morning Briefing: 3-Sektionen-Format, Datenquellen-Reihenfolge, Parsing-Pitfalls
• references/telegram-delivery-errors.md — Drei Diagnostic-Patterns für Cron-Delivery-Fehler (Chat-not-found, Timed-out, Provider-401) + Provider-Switch-Workflow + Ollama-Cloud-vs-Local Klärung
• references/morphreader-data-source.md — MorphReader v6 CLI-Optionen, Format-Details, Fallback
• references/gmail-server-search.md — IMAP server-side SEARCH patterns
• references/cron-delivery-patterns.md — Cron output delivery conventions + Missing-Script Detection
• references/cron-job-validation.md — Validierungs-Checkliste nach Merges, Recovery-Flow für fehlende Skripte
• references/system-services-check.md — ollama/tokentelemetry service status
• research-tools/references/hltv-liquipedia-esports-research.md — Resilient esports/news source fallback chain