/liteparse

name: liteparse
description: Use this skill whenever a task involves a document file (PDF, DOCX, PPTX, XLSX, or image) and you need to read it or pull text, tables, or specific values out of it — to answer a question about its contents, look up a figure, or extract data. Provides fast, local, model-free extraction via the `lit` CLI with disciplined, low-cost search patterns.
compatibility: Requires Node 18+ and `@llamaindex/liteparse` (`npm i -g @llamaindex/liteparse`, verify `lit --version`). LibreOffice for Office files; ImageMagick for images. The bundled search.py helper needs `uv`.
license: MIT
metadata:
  author: LlamaIndex
  version: "1.0.1"

LiteParse

Extract text from documents locally with the `lit` CLI — a fast, model-free parser. This skill is about using it **cheaply**: each `lit parse` re-runs full extraction, and every line you dump into the conversation is paid for on every subsequent turn. The patterns below come from analyzing real agent traces where the same PDF was parsed up to **9 times** and single image reads cost **140k+ characters** of context. Don't repeat those mistakes.

The golden rule: parse ONCE to a file, then search the file

`lit parse` re-extracts the whole document every time you call it. Re-parsing per search is the #1 waste seen in traces. Parse a document exactly once, to a temp file, then run all your searches against that file:

# ONE TIME, per document. --no-ocr for born-digital PDFs (almost all reports) — much faster.
lit parse "/abs/path/doc.pdf" --format text --no-ocr -o /tmp/doc.txt && wc -l /tmp/doc.txt

Then search the file with cheap shell tools — **never** re-run `lit parse` to search again.

Search discipline — minimize ROUND-TRIPS, then keep results small

Every Bash call is a full model round-trip (latency + re-read of context). The biggest waste after parsing is a **serial** loop: grep → look → grep again → `sed` to read the window → grep again. In traces this doubled the turn count versus just reading the doc. Two rules fix it:

**1. Get context in the SAME command — don't grep then `sed`.** Use `grep -C` so the surrounding lines come back with the hit. This removes the follow-up `sed` turn for the common case:

grep -n -i -C4 "total assets" /tmp/doc.txt | head -40      # location AND its window, one turn

Only fall back to `sed -n 'A,Bp'` when you already know the exact line and need a *wider* window than `-C` gave you.

**2. Batch independent lookups into ONE command.** When a question needs several distinct facts (e.g. emissions *and* revenue), don't spend one turn per term. Probe them together with labels:

for q in "carbon intensity" "scope 1" "total revenue"; do \
  echo "=== $q ==="; grep -n -i -C3 "$q" /tmp/doc.txt | head -25; done

Then keep results small:

• **Always bound output** with `head` and use `-n` for line numbers.
• **Don't fan out blindly.** Aim to resolve a question in ≤3 search commands. If two targeted greps

don't pin it down, switch to `search.py` (below) — don't keep firing keyword variations one per turn.

• Prefer **Bash `grep`/`sed` on the saved file over the Read and Grep tools** — fewer round-trips and

you control output size precisely.

Ranked search when keywords are uncertain (bundled helper)

When two targeted greps haven't pinned the answer, **stop greping** — don't iterate keyword variants one turn at a time. Run the bundled BM25 ranker ONCE to surface the most relevant line-windows in a single command:

scripts/search.py /tmp/doc.txt -q "materiality assessment priority topics" -k 8 -e 5

`-k` = number of matches, `-e` = lines of context around each (so the window comes back inline — no follow-up `sed` turn). It returns ranked windows with line numbers. Use a rich natural-language query (several synonyms in one string), not a single keyword. This replaces a long chain of speculative greps.

Born-digital vs scanned

• **Born-digital PDF** (real text layer — nearly all corporate/finance/ESG reports): always pass

`--no-ocr`. It's much faster and the text is identical. Leaving OCR on wastes time.

• **Scanned PDF / image**: drop `--no-ocr`. If the value is missing or digits look wrong, read the

page visually (see below) rather than trusting OCR.

Reading a page visually — last resort, ONE screenshot, modest DPI

Screenshots are the most expensive thing you can put in context: a single high-DPI page PNG ran **~140k characters** in one trace, and agents often rendered the same page twice (default + hi-res).

Only screenshot when text/tables genuinely can't answer the question (dense multi-column tables, figures, charts). Then:

• Render **one** page at a time with `--target-pages "N"` (note: it's `--target-pages`, NOT `--pages`).
• Use **modest DPI (~150–200)**. Do not start at 300+; do not re-render the same page at higher DPI

unless the text is actually illegible.

lit screenshot "/abs/path/doc.pdf" --target-pages "13" --dpi 150 -o /tmp/shots/   # then Read the PNG

Many questions about the same document

Parsing once to a file already covers this: keep the `/tmp/doc.txt` and reuse it across every question instead of re-parsing.

Don't waste turns on preamble

Skip `lit --version`, `ls -la`, and `lit … --help` unless something actually failed. Go straight to the parse. Core flags you need:

`--format text|json` · `--no-ocr` · `--target-pages "1-5,10"` · `--dpi <n>` (default 150) · `--ocr-language <iso>`. Use `--format json` only when you need bounding boxes/layout — it's much larger; still search it, never load it whole.

Setup

PDFs work out of the box. If `lit` is missing: `npm i -g @llamaindex/liteparse`. Office docs need LibreOffice; images need ImageMagick (both auto-converted to PDF).