# Jev Logscan

> Pull the handful of lines that matter out of a long command output, keeping them in their original order. Use when a test run, build, install, CI job, or training loop dumps hundreds or thousands of lines and you need the few that answer a specific question — why it failed, where it got slow, what changed, what ran out of memory. Say what you are looking for with --goal; the ranking is conditioned on it, so the same log returns different lines for different questions. Do NOT use for short output you can just read, or for structured data (JSON, CSV) where you want a parser rather than a filter.

- Skill: `wanlanglin/jev-logscan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add wanlanglin/jev-logscan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wanlanglin/jev-logscan/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- License: MIT
- Author: WanLanglin (https://skillmd.com/u/wanlanglin)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/wanlanglin/jev-logscan

---


# jev-logscan

A build just printed 17,000 lines and six of them explain the failure. Reading
all of it costs your context; scrolling for the error costs your turn.

## Use it

```bash
pytest -v 2>&1 | python3 "$CLAUDE_SKILL_DIR/../../scripts/logscan.py" \
  --goal "find out which test failed and why"
```

```bash
python3 .../logscan.py --log build.log --goal "find out why the link step failed"
python3 .../logscan.py --log train.log --goal "find where loss became NaN" --budget 60
```

**`--goal` is the whole interface.** The ranking is conditioned on it, so ask
for what you actually want:

- `"why did this fail"` → errors, tracebacks, the failing assertion
- `"where did it get slow"` → timings and durations, not errors
- `"what configuration was used"` → the settings echoed at startup
- `"what ran out of memory"` → allocation and OOM lines

Same log, different lines out.

## Reading the output

Lines come back **in their original order**, with elided runs marked, because a
log read out of sequence is unusable. Original line numbers are preserved so you
can go back to the source. A `!` marks a line that matched an error shape
(traceback, `SyntaxError:`, `FAILED`, `panic:`) and was kept regardless of score.

If nothing in the log addresses your goal, it says so instead of padding the
output with the least-bad lines.

## How it decides

Logs are templated — a build prints `Compiling './x'...` seventeen thousand
times — so lines are collapsed to their shape first (paths, numbers and hashes
normalised away), each distinct shape is scored once, then expanded back. On a
17,591-line build log that is 24 distinct shapes, which is why this is fast and
cheap on logs that would otherwise be enormous.

Three signals combine: **goal relevance** from Jev, **rarity** (a shape seen
once matters more than one seen 17,000 times), and **error shape** as a floor
that catches crashes whatever you asked for.

## Flags

- `--budget N` — keep at most N lines, best first. Without it, everything above
  `--keep-floor` (default `0.10`, the measured noul floor) is kept.
- `--no-always` — stop force-keeping error-shaped lines.
- `--no-jev` — rarity and error shape only, no network, no key.
- `--json` — machine-readable, with per-line scores and original line numbers.

Under 40 lines the script just echoes the input; short logs do not need this.

## Setup

```bash
export TYPESAFE_API_KEY=...   # https://typesafe.ai
```