review-session-log
Use when the user asks what a session did, wants to review session history, or needs to find errors in a session log
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/mixpeek/amux/HEAD/.claude/commands/review-session-log.md -o ~/.claude/commands/review-session-log.mdreview-session-log.md
# /review-session-log — Review a session's terminal log You are reviewing the full terminal output log of an amux session. ## How to get the log Session logs are stored at `~/.amux/logs/<session-name>.log` (up to 10 MB each, oldest output trimmed). 1. Determine the session name from `$ARGUMENTS`. If empty, ask the user. 2. Read the log file directly: `~/.amux/logs/<session-name>.log` 3. If the file is large (>2000 lines), read it in chunks — start from the end (most recent) and work backwards as needed. ## What to look for Analyze the log and produce a structured review covering: ### 1. Summary - What was the session working on? (1-3 sentences) - How long has it been active / how much output is there? ### 2. Current State - What is it doing right now? (last ~50 lines) - Is it waiting for input, actively working, errored out, or idle? ### 3. Key Actions Taken - Major tasks completed (commits, deploys, file changes, API calls) - Important decisions or branching points ### 4. Errors & Warnings - Any errors, exceptions, tracebacks, or failed commands - Permission denials, timeouts, or retry loops - If none found, say so explicitly ### 5. Notable Output - Any interesting results, URLs, or artifacts produced - Test results, build outputs, or deployment confirmations ## Instructions The user wants to review: **$ARGUMENTS** - Strip ANSI escape codes mentally — the log contains raw terminal output - Focus on substance, not boilerplate (skip tool call formatting, progress spinners, etc.) - If the log is very long, prioritize recent activity but note if earlier sections contain important context - Quote specific log lines when citing errors or key moments - Be concise — the user wants a quick situational overview, not a line-by-line walkthrough ## Gotchas - Logs contain raw ANSI escape codes — ignore formatting artifacts when parsing. - Logs are capped at ~10 MB with oldest output trimmed — very old activity may be missing. - Session names are case-sensitive — `~/.amux/logs/MySession.log` ≠ `~/.amux/logs/mysession.log`. - A missing log file means the session has never produced output (new or idle session), not an error.
Pick up an open issue from the amux issue tracker, mark it doing, work it, and mark it done.
Use when the user says "add to board", "create a task", or wants to track a todo on the amux kanban board
Use when you need to interact with the amux system — manage board tasks, check sessions, send emails, automate browsers, or work with CRM contacts
Use when the user asks to interact with a web page, take a screenshot of a site, click or type in Chrome, scrape content, or debug a web UI. Connects to real Chrome tabs with existing logins.
Scaffold a closed orchestrator loop — creates the mission note, state/constraints notes, and a scheduler entry from the v2 template.
Use when the user needs to log into a website for browser automation, save auth cookies, or sync browser profiles to cloud
Use when you need to test the amux dashboard UI, investigate a visual bug, or verify a frontend change works correctly
Use when the user wants to record a video of a browser task, create a screen recording, or produce an MP4 demo