100 PDFs, one searchable Markdown index
Measured on 2026-11-14 — numbers from one real run
The run log here comes from an actual run, not an estimate. Where token usage was not captured it says so rather than guessing.
When to use
A folder piled with hundreds of PDFs whose filenames tell you nothing; you want to find things by topic.
Preparation
- Host version
- 0.1.2-alpha.5
- Model
- To fill
- Mode / permissions
- --profile headless / workspace-write / Windows 11 / node 22.22.2
- Plugins required
- None (add name & version after testing if used)
- Input materials
- 100 synthetic PDFs, one in five with no text layer. This run covered only the first 10 by filename (000–009)
Full instruction
Scan all PDFs under [DIRECTORY] and build a Markdown index for this folder.
For each record, write: the filename, a one-line description of what the file covers, 3 keywords taken from the original text, and the last-modified time.
Group by topic, and within each topic sort by time, newest first.
Requirements:
1. The one-line description must come from the body text; do not guess from the filename. For files whose body text cannot be read, mark them as 'READ FAILED' and list them in a separate section; do not skip them.
2. First print the first 10 records for me to confirm the format; only after I confirm should you write the full index.
3. Save the index as index.md; do not modify any original PDF.
4. Finally report: how many files were processed, how many succeeded, how many failed, and the reason for each failure.Run log
| Item | Value | Note |
|---|---|---|
| Time spent | 82 seconds | 2026-11-14 |
| Result | 10 processed / 8 succeeded / 2 failed; artifact index.md at 3,736 bytes; no source PDF modified | |
| In / out tokens | Not captured (headless does not print usage) | |
| Leftovers | None. |
What the run showed
- The clause 'descriptions must come from the body' did work: it surfaced and flagged a mismatch where a filename said brewing parameters while the body discussed storage locations, instead of following the filename.
- The two failures were not skipped. They got their own section with page count, image size (80 by 80 pixels), presence of embedded fonts, and whether annotations or attachments existed — plus a note that no OCR was available locally.
- It cleaned up its own temporary scripts, leaving only index.md. Nothing in the recipe asked for that.
- The eight readable files shared one body template, and it said so plainly: the repetition is in the source, not a lazy summary.
A lesson from building the fixture: writing Chinese with PyMuPDF's insert_text without a CJK font silently writes placeholder bytes (0xB7), which extract as dots. The first run therefore saw all 10 as unreadable — and it fabricated nothing, just reported failure, which incidentally proved the recipe behaves correctly on bad data.
Output
After a successful run, list files and screenshots here, and note whether originals changed.
Acceptance checklist
Tap to tick each item off as you verify.
- index.md has been generated and not a single original PDF was modified
- Each one-line description can be matched to content in the original text
- Unreadable files are listed separately and were not silently skipped
- Total processed = succeeded + failed
Failures & boundaries
- For scanned PDFs with no text layer, the body text cannot be read; they all land in the 'READ FAILED' section
- With very deep folder nesting or thousands of files, first try a small batch of 10 before running the full set
- This page is a recipe template and has not yet been tested on this site