Skip to content
Development
Command

/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

From plugin
amux
33510 skills10 commands

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.md
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.
Read more
Ships withamux

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.

Get the whole plugin