Preface

Common practices for enabling agents in DeepSeek Harness (DSH) to read PDFs, Word documents, Excel spreadsheets, or scanned documents involve connecting to remote document conversion services, spinning up Docker containers, or uploading files to cloud OCR services with API keys. These approaches either depend on network connections and additional deployments or involve sending documents off the local machine.

dsh-doc (GitHub repository Sqhao-O/dsh-docs) takes a different approach: it parses documents using a local engine within the DSH process. On Windows x64, it can also mount a prebuilt offline Python + Xberg runtime, working with local Tesseract language packs for OCR. No Docker, HTTP services, or API keys are required, and documents never leave the disk.

The following sections detail the plugin’s positioning, capability boundaries, installation steps, and typical usage. All facts are sourced from the project README, package.json, and the SkillHub directory page.

What Is This

dsh-doc is a DSH plugin published by maintainer Sqhao-O. Its npm package name and plugin ID are both dsh-doc (tool prefix dshdoc_*; previously named dsh-docling / docling_*, now renamed). SkillHub categorizes it under “Model Inference,” the repository has about 12 stars, the license is MIT, and the current release version is 0.1.1.

In one sentence: it provides fully local document intelligence capabilities for DSH agents—parsing PDFs, Office documents, images, or scans into Markdown, plain text, or structured JSON for subsequent reasoning and Q&A.

Core Features

Supported Input Formats

The README lists the following formats, which have been verified through integration tests:

  • Documents: PDF, DOCX, XLSX, PPTX, Markdown, HTML, CSV, and plain text
  • Images and scans: PNG, JPEG, TIFF, WebP, and scanned PDFs requiring OCR

Other formats supported by Xberg can be verified on your own corpus before use in production.

Output Formats

Conversion results can be in Markdown, plain text, or JSON-structured Tool Results. The page_range parameter performs interval extraction by page numbers (starting from 1) for Markdown/plain text; JSON output preserves the full structured document.

Dual-Engine Architecture

Platform Recommended Engine OCR
Windows x64 engine: python, pointing to the prebuilt runtime Enabled by default (defaultOcr: true), includes English and Simplified Chinese Tesseract data
Other Platforms engine: node (Xberg Node binding) Disabled by default; if OCR is needed, tessdataPath must be configured locally. Missing language packs return ENGINE_OCR_UNAVAILABLE and will not automatically download models

The Windows prebuilt runtime includes CPython 3.11.9, xberg==1.0.14, and fixed eng / chi_sim language packs. Downloads and extraction are verified with SHA-256. The Python worker only receives file byte snapshots, display names, MIME types, and conversion options via stdio—it does not receive user paths or URLs, runs offline, and has document-derived OCR caching disabled.

Provided Tools

Tool Purpose
dshdoc_health Checks if the currently selected local engine is ready
dshdoc_extract Convenient entry point for parsing local files (recommended)
dshdoc_convert_file Parses local files within the whitelist
dshdoc_convert_url Compatibility stub, returns UNSUPPORTED_URL for HTTP(S) inputs

The plugin detects URL inputs and directly rejects them to avoid forwarding remote addresses to Xberg or Python. Remote documents must first be downloaded to a local directory that is allowed to be read, then parsed using the local tools.

Paths and Permissions

The session workspace is readable by default. To access persistent directories outside the workspace (e.g., shared document libraries), configure allowedLocalRoots in cordis.patch.yml. Relative paths are resolved relative to the DSH session workspace, not the shell directory from which dsh web was started.

Installation and Enabling

Prerequisites: A working dsh CLI is installed locally, and the Node version is ^22.19 or >= 24.

1. Install the Plugin Package

Install the published npm package in the target profile (using web as an example):

dsh plugin --profile web add dsh-doc

2. Windows x64: Download the Offline OCR Runtime

Place the prebuilt runtime outside node_modules to avoid deletion during plugin upgrades:

node <home>/.dsh/profiles/web/node_modules/dsh-doc/scripts/fetch-runtime-win32-x64.mjs <home>/.dsh/runtimes/dshdoc-runtime-win32-x64

Replace <home> with the absolute path to your user home directory. The script verifies the archive’s SHA-256 and performs a manifest check on extracted files. Skip this step on non-Windows x64 platforms; use engine: node subsequently.

3. Edit Profile Configuration

In <home>/.dsh/profiles/web/cordis.patch.yml, retain existing entries and add or update:

Windows x64 (Full OCR Capability):

- id: dsh-doc
  config:
    engine: python
    runtimeDir: <home>/.dsh/runtimes/dshdoc-runtime-win32-x64
    maxFileBytes: 52428800
    maxOutputChars: 32000
    defaultOcr: true
    defaultTableMode: accurate
    defaultOutputFormat: md

Other Platforms (Node Fallback, No Default OCR):

- id: dsh-doc
  config:
    engine: node
    defaultOcr: false
    maxOutputChars: 32000

4. Verify and Restart

Confirm the configuration is active:

dsh --profile web --dump-config

Check that the dsh-doc entry in the output contains the expected config. After restarting dsh web, call dshdoc_health to confirm the engine status.

The README also provides a “one-click install” prompt that can be pasted into a running DSH session, allowing the agent to complete the above steps in the terminal; see the repository’s INSTALL.md for details.

Typical Usage

After installation and restarting dsh web, you can ask the agent to read local files within the workspace in a session, for example:

Read ./reports/annual-report.pdf and give me the three main risks.
Extract the tables from ./financials.xlsx.
Read the text from ./scanned-invoice.png.

You can also directly call dshdoc_extract at the tool layer to parse specified paths. Only paths within the workspace or allowedLocalRoots are readable.

Use Cases and Notes

Who It’s For

  • Developers who need to process local documents like contracts, reports, slides, or scanned invoices in DSH workflows while ensuring data does not leave the machine
  • Windows x64 users who need out-of-the-box offline OCR (Chinese and English) and prefer the Python engine path
  • Teams that do not want to maintain Docling Serve, Docker, or remote document APIs

Usage Notes

  1. The plugin runs with the permissions of the current dsh process. Review the source code and MIT license before installation.
  2. Do not connect Docling Serve, Docker containers, or downloadable OCR backends to this plugin; the project explicitly prohibits such remote or auto-pulling model configurations.
  3. Non-Windows platforms have no offline OCR by default; if your use case heavily relies on scanned document recognition, deploy the Python runtime on Windows x64 or prepare an audited local tessdataPath.
  4. Single file size is limited by maxFileBytes (default 52428800 bytes) and maxOutputChars (32000 in the example configuration); very large documents require segmentation or higher configuration limits.
  5. The SkillHub directory page (skillhub.cn/plugins/Sqhao-O/dsh-docs) is a community-collected site with no official affiliation to DeepSeek / High-Flyer; installation commands should follow the README and npm package dsh-doc.

Conclusion

dsh-doc consolidates the parsing of PDFs, Office documents, images, and scans into a DSH plugin. It provides a complete offline OCR path on Windows x64 and covers non-OCR parsing needs with the Node engine on other platforms. If your agent needs to “read local documents and then reason,” you can install it following the steps above and first use dshdoc_health to verify the environment.