watch-log

name	watch-log
description	Watch or investigate a Vortex log file (rotation- and session-aware). A router over six modes loaded on demand — live tail, session/crash/error investigation, persistence (duckdb/level_pivot) integrity, log-line-to-code correlation, single download/install/collection/deploy trace, and a collection-install audit (also serves as the LAZ-483 regression check). Defaults to the dev log; can target prod or a specific file.
when_to_use	When the user wants to watch/tail/follow a log live, or investigate/report on errors, crashes, warnings, persistence integrity, re-installs, version downgrades, a specific log entry, or a download/install/collection/deployment lifecycle in a Vortex log.
user-invocable	true

/watch-log (router)

Watch or investigate a Vortex log file. The log is rotation-aware and session-aware: it rolls at ~11 MB into vortex1.log, vortex2.log, … so one run can span several files and one file can hold several runs. This skill is a thin router: it picks the mode(s) and loads only the files needed, keeping context small.

How to run

1. Always read reference.md (the core) first — the universal log facts, the dev/prod/rotation log-set resolver, and an index of the on-demand shared/ chunks (sessions, lifecycle, persistence, multi-file, edge-cases) that modes load as needed.
2. Pick the mode(s) from $ARGUMENTS using the table below. More than one mode may be requested in a single invocation (e.g. "investigate + persistence", or "trace and correlate ").
3. For each selected mode, read its file under modes/ plus the shared/ chunks named in that mode's Prereq line, and follow it. Read reference.md and each chunk at most once, even when running several modes.
4. Running several modes: if they're independent (the common case), you may run them concurrently — e.g. dispatch each mode to its own subagent (pass it reference.md + the mode file + the resolved log target), then combine the results into one report with a section per mode. If a mode depends on another's output (rare), run them in order. Resolve the log set once (per reference.md) and share the target across all selected modes.

Mode picker

Mode	Trigger ($ARGUMENTS)	File
Live	default, or watch / live / follow / tail / monitor	modes/live.md (§A)
Investigate	investigate / analyze / report / crashes / errors / warnings / session / "what happened", or a date/session ref	modes/investigate.md (§B)
Persistence	persist / persistence / duckdb / level_pivot / slow write / did it save	modes/persistence.md (§C)
Correlate	a pasted/quoted specific log line, or correlate / why did this happen	modes/correlate.md (§D)
Trace	trace / track / follow this install / download / collection / deployment, or a mod id / archive name / nxm url / downloadId / collection name	modes/trace.md (§E)
Collection install audit	collection install audit / member stuck / requeue loop / did the collection finish / install completion / settled / interrupted install / resume / data loss on restart / 483	modes/collection-install.md (§F)

Trace vs Collection install audit: §E follows one entity and reports where it stalled; §F audits a whole collection install against the install-completion invariants (every member terminal, no requeue loop, phases advance, error paths settle) and names which invariant broke. Use §F to audit a whole install's health (this doubles as the LAZ-483 regression check), §E to chase one thread.

If no mode is implied, default to Live. If a request clearly spans several (e.g. "give me the full picture of this session and its persistence"), select and run all that apply.