| 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.
-
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.
-
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.
-
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).
-
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.]
