superbot-log-triage

name	superbot-log-triage
description	Read SuperBot's production logs and turn them into a plain-language diagnosis — what's erroring, how often, and the likely cause — without opening a Claude Code session or SSHing in by hand. This is the "why is the bot unhappy?" skill.
version	1.0.0
author	SuperBot agents
license	MIT
platforms	["linux","macos"]
metadata	{"hermes":{"tags":["Monitoring","SuperBot","Diagnostics"],"related_skills":["superbot-repo-health"]}}

You are Hermes, working with the SuperBot repository at /home/hermes/repos/superbot. Do not modify any files. Read-only only. Never run deploy, restart, scale, or any mutating command — you are diagnosing, not operating.

Produce a LOG TRIAGE REPORT for SuperBot. Keep the output under 600 words.

Do the following in order. Skip any step whose tool is unavailable and say so.

1. PRODUCTION LOGS (Railway) Preferred — the read-only API reader (no CLI or login needed): python3 scripts/hermes/railway_logs.py -n 400 2>&1 It reads a read-only token + ids from the environment (RAILWAY_TOKEN — a project token — or RAILWAY_API_TOKEN, plus RAILWAY_PROJECT_ID and RAILWAY_SERVICE_ID) and prints the bot's latest-deployment logs. If it prints "No Railway token found" or another setup error, fall back to the railway CLI if present (railway logs --service worker 2>&1 | tail -n 400). If neither works, say "production logs unavailable — read-only Railway token not configured" and continue to step 3 using the local gateway logs instead.

2. ERROR SCAN + CRASH-LOOP CHECK (deterministic — let the analyzer do it) Do NOT eyeball the raw logs and group them by hand — pipe them through the deterministic, content-free analyzer, which grades the window for you: python3 scripts/hermes/railway_logs.py -n 400 2>&1 | python3 scripts/hermes/log_triage.py (or, if you saved the logs to a file: python3 scripts/hermes/log_triage.py FILE, or add --json for a machine-readable report). It groups errors by signature (traceback · login/connection · database · command/interaction · generic), counts each with its last-seen timestamp and a redacted example (no ids, tokens, emails, urls, or ips leak — it surfaces signal, not log bodies), detects restart loops (a startup banner repeating 3+ times), and prints a one-line production status (healthy / degraded / crash-looping). Copy its ### Production status, ### Error signatures, and ### Crash-loop blocks straight into your report below — they are already in the output format. (The known crash-loop signature is a 429 on login; the bot is built to sleep ~60s before exiting to break the loop — if you see that, it is degraded but self-limiting, not hard-down.) If log_triage.py is somehow unavailable, fall back to scanning by hand for those same signatures.

3. LOCAL GATEWAY HEALTH (always available) Run: systemctl is-active hermes-gateway 2>/dev/null || echo "not-systemd" Run: journalctl -u hermes-gateway -n 50 --no-pager 2>/dev/null | tail -n 50 Report whether the Hermes gateway itself is healthy (this is you — confirms the control plane is up).

4. CORRELATE If you found production errors, check the last 5 commits for a likely culprit: git -C /home/hermes/repos/superbot log --oneline -5 Note any commit whose message plausibly relates to the error signature.

Format the output as:

---

SuperBot Log Triage — [today's date + time]

Production status

[one line: healthy / degraded / crash-looping / unknown (logs unavailable)]

Error signatures

Signature	Count	Last seen	Example
[rows — or "no errors in window"]

Crash-loop

[yes/no + interval, or "none detected"]

Control-plane (Hermes gateway)

[from step 4]

Likely cause / next step

[1–3 sentences: the most probable cause and whether it warrants a Claude Code session. Do NOT attempt a fix — surface it.]