## TL;DR
The truncated final line is one bad line, not a bad file. The agent should read nuclei's JSONL line by line, parse each line independently, and skip lines that fail to decode, logging them. Every complete finding survives; only the torn tail is lost.

```text
agent parser failed on nuclei JSONL with truncated final line
```

## Use this when
- nuclei was killed or crashed and its JSONL output ends mid-line, and the agent's parser throws on the file.
- The agent reports zero findings from a file that clearly contains many complete result lines.
- The failure is always at the end of the file.

## Not for this skill when
- The JSONL file is empty. That means nuclei found nothing or never wrote.
- Lines in the middle of the file fail to parse. That suggests a different corruption.
- The agent parses a different nuclei format (plain text, markdown). This fix is JSONL-specific.

## Steps
1. Read the file line by line instead of loading it whole: for each non-empty line, attempt `json.loads`, and on failure log the line number and continue. Verify: a test file with a torn final line yields all complete findings.
2. Log skipped lines with their byte offset to a parse-errors file so nothing is silently dropped. Verify: the parse-errors file lists exactly the lines that failed.
3. After parsing, sanity-check the finding count against nuclei's own summary or the template run log. Verify: the counts are close, with the gap explained by skipped lines.
4. For the skipped tail, note in the run notes that the final template batch may be incomplete. Verify: the notes name the affected portion of the run.
5. Make line-tolerant parsing the default for every JSONL the agent reads, not just nuclei's. Verify: the shared parsing helper is used for all JSONL inputs.

## Variant phrasings
### nuclei JSONL torn last line broke parser
Same line-tolerant fix.
### agent lost nuclei results on truncated output
Crash-recovery variant.
### JSON decode error on nuclei results file
Error-message phrasing.

Compatibility: nuclei 3.x JSONL output. Line-delimited JSON parsing is language-agnostic.

## Why it happens
Agents tend to read a results file as one blob and decode it in a single call, which works until any byte is wrong. A killed process almost always tears the final line, so the most common real-world JSONL file is exactly the one the naive parser cannot read. Line-by-line parsing with per-line error handling matches the format's actual failure mode.

## Edge cases / pitfalls
- A torn line in the middle of the file is suspicious: it can indicate disk corruption or concurrent writes. Investigate rather than just skipping.
- Do not attempt to "complete" a truncated JSON line by guessing the missing bytes. Skip it and, if the finding matters, re-run the template.
- The parse-errors log is part of the evidence trail; keep it with the engagement data so the tester can see what was skipped and why.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_I1qR7JzLfQx--ETa--X2HA