openakari: Skill for Claude Code

/slack-diagnosis

Diagnose Slack bot issues by reading actual Slack messages, correlating with system logs, and implementing fixes.

The argument is context about what to investigate — a problem description, a thread URL, a channel:timestamp pair, or recent. Regardless of argument type, always start by fetching real Slack messages.

Step 0: Verify runtime environment (ALWAYS do this first)

Before analyzing application logs, verify the process topology. This catches orphan processes, duplicate instances, and deployment issues that application logs alone cannot reveal.

pm2 list

Check for scheduler processes outside PM2:

ps aux | grep -E 'cli.js|scheduler' | grep -v grep

If multiple instances found:

• This is likely the root cause.
• Document which PIDs are running.
• Check when they started: ps -o pid,lstart,cmd -p <PID>
• Identify which log files each uses.

Check for orphan log files:

ls -la /tmp/akari-*.log

If orphan log files exist or multiple scheduler processes are running:

• Cross-reference their timestamps with the issue being diagnosed.
• Messages may have been handled by the orphan process (logged to /tmp/) instead of PM2 logs.
• This explains "ghost sessions" where Slack shows bot responses but PM2 logs are empty.

Only proceed to Step 1 if the runtime environment is clean (single PM2-managed instance, no orphan logs).

Step 1: Fetch Slack messages

The DM channel ID is D0AF4CX9U3U. The bot token is read inline from infra/scheduler/.env.

Always fetch recent DM history first to see the latest conversations:

curl -s "https://slack.com/api/conversations.history?channel=D0AF4CX9U3U&limit=20" \
  -H "Authorization: Bearer $(grep '^SLACK_BOT_TOKEN=' infra/scheduler/.env | cut -d= -f2)" | jq '.messages[] | {ts, user, bot_id, text: (.text // "" | .[0:200]), thread_ts, reply_count}'

Then, for any message that has thread_ts (i.e., is part of a thread) and looks relevant to the reported issue, fetch the full thread: