Skip to content
Agentmart
Submit a tool

pdf-ingestion

Get a PDF into the model without blowing the context window or losing structure.

Skill by Archive228

IndexedMIT★ 755
Write a review

Install

Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install skill/archive228-pdf-ingestion

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Get a PDF into the model without blowing the context window or losing structure. Native PDF beats OCR-then-text for most cases; extract-then-summarize beats native for very long docs.

Use cases: documents

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.

Tools
No tools found
Secrets
None asked for
Install scripts
None found

Network hosts it talks to 1

  • codeload.github.com · found in install command

Files it touches

  • ~/.claude/skills/pdf-ingestion

What's inside

Skill name
pdf-ingestion
Description
Get a PDF into the model without blowing the context window or losing structure. Native PDF beats OCR-then-text for most cases; extract-then-summarize beats native for very long docs.
License
MIT
Instructions
55 lines in SKILL.md · view on GitHub

Files (1)

  • SKILL.md

SKILL.md (first lines)

# PDF Ingestion

Three ways to feed a PDF to the model, in increasing order of preprocessing:

1. **Native PDF input** — pass the file directly. Model sees pages as images + extracted text. Best for docs under ~100 pages with meaningful layout (tables, figures, forms). Preserves structure.

2. **Text extraction then send** — `pdftotext` / `pypdf` / equivalent, then send the text. Loses layout but cheap. Fine for prose-heavy docs where tables don't matter.

3. **Extract → chunk → summarize → send** — for docs >100 pages or when you'll query the same doc many times. Preprocess once, cache the summary.

## Deciding which path

| Doc shape | Path |
|---|---|
| <20 pages, layout matters (report, form, invoice) | Native |
| <20 pages, pure prose (article, memo) | Text extraction |
| 20-100 pages, mixed | Native, but chunk if context tight |
| >100 pages | Extract → chunk → summarize |
| Scanned PDF (no text layer) | OCR first (Tesseract or vision model), then treat as extracted text |
| Tables are the point | Native — text extractors mangle tables |
| Figures/diagrams are the point | Native + explicit "describe the figure on page N" prompt |

## Native PDF — the good defaults

- Cache the PDF at a prompt-caching breakpoint (see `prompt-caching`). Native PDFs are large — every uncached turn costs full input price on the whole doc.
- Ask about **specific pages** ("summarize section 3.2 on page 14") rather than the whole doc. The model handles targeted queries better than "summarize this 80-page report".
- Follow up with **page-cited claims** — "on which page does the doc say X?" — as a sanity check the model isn't hallucinating.

## Extract-then-send — the traps

- **`pdftotext` reading order.** Multi-column PDFs come out as interleaved lines. Use `pdftotext -layout` for column preservation, or `pdftotext -raw` for straight reading order — pick per doc, don't guess.
- **Tables become word soup.** If tables are load-bearing, native or per-table image extraction. Not text.
- **Headers/footers repeat on every page.** Strip them before sending, or the model will treat them as content.
- **Footnotes drift** to random positions in the extracted stream. Filter or accept the noise.

## Extract → chunk → summarize (long docs)

- Chunk by section, not by token count. A section-aware split respects the doc's logic; a naive 4K-token split cuts sentences and tables.
- Summarize per section into a "map" — 1-2 paragraphs each. Keep the map short enough to fit in context whole (~2-4K tokens for a 200-page doc).
- Store the full section text alongside the map (paths in a manifest). Fetch on demand when a question needs detail beyond the summary.
- Cache the map at a prompt-caching breakpoint so multi-turn Q&A over the doc doesn't reprocess.

## Red flags

- **Sending a 200-page PDF native to answer one question.** Extract the relevant page range first.
- **Trusting the text extractor on a form or invoice.** Layout carries meaning. Use native.
- **OCR'ing a PDF that already has a text layer.** Check `pdftotext -q file.pdf -` first — if text comes out, no OCR needed.
- **No page citations in output.** Model can hallucinate confidently across long PDFs. Force page numbers into the response format.
- **Re-uploading the same PDF every turn without caching.** Cost climbs linearly; a 5-minute cache fixes it.

## Loopkit-adjacent

If the PDF is a spec, extract it into `PROMPT.md` via `spec-first` — the agent should re-read prose, not re-scan the PDF, on every turn.

From Archive228/loopkit, MIT.

More from Archive228/loopkit

Signals

Stars
755
Forks
124
Open issues
0
Last commit (this folder)
Jul 7, 2026 (3 months ago)

From GitHub (fetched Oct 24, 2026).

Details

License
MIT
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

More from Archive228

Cite this page

pdf-ingestion skill. Agent Mart. https://agentmart.dev/skills/archive228-pdf-ingestion (last updated 2026-10-24)