/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
How it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/review-session-log
Context preview
What this command does when you run it.
Use when the user asks what a session did, wants to review session history, or needs to find errors in a session log
Command definition
review-session-log.mddescription: Use when the user asks what a session did, wants to review session history, or needs to find errors in a session log
allowed-tools: Bash, Read, Grep
argument-hint: <session-name>
context: fork
/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.
Read more
description: Use when the user asks what a session did, wants to review session history, or needs to find errors in a session log allowed-tools: Bash, Read, Grep argument-hint: <session-name> context: fork
/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.
Open-source control plane for AI coding agents — run, monitor & orchestrate dozens of parallel Claude Code, Codex & Gemini sessions from one web dashboard or your phone. Self-healing, single-file, tmux-native.
Repo: mixpeek/amux
Other commands on amux.
- /aissue
Pick up an open issue from the amux issue tracker, mark it doing, work it, and mark it done.
Open command - /amux-board
Use when the user says "add to board", "create a task", or wants to track a todo on the amux kanban board
Open command - /amux
Use when you need to interact with the amux system — manage board tasks, check sessions, send emails, automate browsers, or work with CRM contacts
Open command - /chrome-cdp
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.
Open command - /orchestrate
Scaffold a closed orchestrator loop — creates the mission note, state/constraints notes, and a scheduler entry from the v2 template.
Open command - /playwright-auth
Use when the user needs to log into a website for browser automation, save auth cookies, or sync browser profiles to cloud
Open command

