Document Text Extractor
Turn common documents and healthcare attachments into processable plain text.
The code uses read-only file processing, an allowlisted child-process environment, and explicitly targets PHI without caches or temp files. However, HOME, temporary-directory, and proxy variables are still passed through; third-party parsing remains a supply-chain dependency; input permission boundaries, resource limits, rollback, and licensing are not fully documented, so 6 points are deducted.
The main paths, format mappings, PDF fallback, structured errors, and exit codes are implemented. However, the documented rtf-to-text dependency and method values conflict with the actual custom RTF/XML decoders, and no test suite or abnormal-input coverage is provided. This merits a 13-point deduction and remains subject to the static-review cap.
The skill targets multiple healthcare document formats and EHR attachments, supports extensions and MIME types, and documents table and extensionless-file limitations. It does not define Chinese/OCR quality, very large files, encrypted documents, or clear non-fit scenarios, so 5 points are deducted.
The documentation has clear setup, invocation, output, table caveat, and integration guidance. It lacks versioning policy, changelog, maintenance ownership, complete dependency locking, license details, and troubleshooting; some documentation is stale relative to the implementation, so 9 points are deducted.
The implementation covers PDF, Office formats, RTF, XML, and plain text, with page anchors and extraction-method metadata. Static review cannot verify extraction correctness; table interleaving, OCR, and formatting fidelity require human review, and outputs may need post-processing. This merits a 9-point deduction and is subject to the static-review cap.
The source, type configuration, and execution paths are auditable, with useful implementation comments. There are no committed tests, CI coverage, or third-party execution results, and dependency documentation conflicts with the code, so 6 points are deducted and the static-review cap applies.
- The documentation claims an rtf-to-text dependency and lists rtf-to-text as a method, while package.json and the code use custom decoders.mjs; the documentation, output contract, and dependency declaration should be synchronized.
- The skill launches a third-party parser and passes selected environment variables; deployers should review proxy, cache, temporary-directory, and resource-limit behavior to protect PHI and prevent resource exhaustion.
- There is no test evidence for table-column attribution, OCR, encrypted files, very large files, or malformed formats; clinical or billing conclusions should be checked against the original document with human review.
- License, versioning, changelog, and maintenance responsibility are not clearly specified in the supplied skill materials.
What it does & when to use it
doc-extract is a shared document-to-text skill in the healthcare plugin, covering PDF, DOCX, XLSX, PPTX, RTF, plain text, Markdown, and HTML. It reads a local input file and prints JSON to stdout without writing caches, temporary files, or other disk state. Paged formats retain page markers and the output identifies the extractor that produced the text. It fits workflows that need to pass contracts, EHR DocumentReference attachments, or other binary documents to downstream processing.
Runs scripts/extract.ts, detects formats from file extensions, and reads the input file. It uses liteparse for PDF, DOCX, XLSX, and PPTX, including OCR; rtf-to-text for RTF; pdftotext -layout as a PDF fallback; and passthrough for plain text, Markdown, or HTML. The command prints JSON with text, method, and an optional pages field to stdout; errors go to stderr and exit with status 1. Paged text includes === [page N] === markers between pages.
- A healthcare integrator needs to convert downloaded EHR DocumentReference attachments into text for downstream processing.
- A contract workflow needs to ingest text from PDF, DOCX, or RTF documents.
- A data engineer needs to extract text from XLSX or PPTX files for continued script-based analysis.
- A document pipeline needs an OCR path for PDF, DOCX, XLSX, or PPTX inputs.
- A PHI-sensitive workflow needs extraction without caches, temporary files, or other disk writes.
Pros & cons
- Handles PDF, DOCX, XLSX, PPTX, RTF, plain text, Markdown, and HTML.
- Returns structured JSON with the method used and available page count.
- Avoids disk writes, caches, and temporary files, which suits PHI-sensitive workflows.
- Provides an OCR path for PDF, DOCX, XLSX, and PPTX.
- Initial setup requires Bun plus the npm packages liteparse and rtf-to-text.
- Binary formats other than the PDF fallback require liteparse; extensionless files cannot use liteparse.
- Multi-value tables may interleave columns, making column ownership ambiguous.
- The source provides no test-suite, platform-coverage, or performance evidence.
How to install
Install the healthcare plugin with /plugin marketplace add anthropics/healthcare, then run /plugin install healthcare@healthcare. In the skill directory plugins/healthcare/skills/doc-extract/, run bun install. The source does not document how to install Bun or how client-specific plugin paths may differ.
How to use
From the skill directory, run: bun scripts/extract.ts <input-file> [--content-type <mime>]. Example: bun scripts/extract.ts attachment.pdf. For an extensionless healthcare attachment, use bun scripts/extract.ts attachment --content-type application/pdf. The command returns JSON containing the extracted text and method; other skills can also import extract and resolveLit directly from Bun TypeScript.
Compared to similar skills
For PDFs, pdftotext -layout is the documented fallback when liteparse is unavailable or unsuitable; RTF uses rtf-to-text. The source does not provide a comparison with other full products.