Clawdbot Logs

**Judgement:** This skill is well-focused and practically useful for operating and debugging a local Clawdbot deployment. It offers targeted commands for response-time analysis, error inspection, session statistics, configuration validation, and cost/token visibility, making it a strong fit whenever a user asks “why is my bot slow / failing / expensive?” **Recommended scenarios:** - User reports slow or delayed replies from Clawdbot and wants concrete diagnostics (response times, token counts, long sessions). - User suspects configuration or gateway issues and needs to check `clawdbot-gateway.service` status and logs. - User wants visibility into session-level metrics (token usage, approximate cost, session length) to decide whether to compact or start a new session. - Debugging recent errors, failed tool calls, or Telegram gateway issues via filtered `journalctl` output. **Key risks / limitations:** - Environment-specific: assumes a typical Clawdbot layout (systemd user service, specific log paths, scripts directory). Custom setups may break commands or yield partial results. - Potential exposure of sensitive content from session logs (full conversations, including any secrets the user entered); this is acceptable for self-debugging but should be handled carefully if logs are shared. - Metrics like token usage and “costs” are only as accurate as the recorded session data and may not perfectly match billing systems. Use this skill when the question is about **bot performance, errors, runtime behavior, or token/cost stats** rather than about general application logic or unrelated system administration.