| 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
- 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.
- 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 ").
- 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.
- 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.
