{"owner":"docling-project","repo":"docling","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md"],"skills":{"AGENTS.md":"# Docling\n\nThis file provides guidance to AI coding agents when working with code in this\nrepository.\n\n## Project overview\n\nDocling is a Python SDK and CLI for converting PDFs, Office files, HTML,\nMarkdown, audio, images, XML, and other formats into a unified\n`DoclingDocument` representation for downstream AI workflows.\n\n## Project structure\n\n```text\ndocling/                 # main Python package\ndocling/.agents/skills/  # usage skills shipped inside the package (see below)\npackages/docling/        # full docling meta-package\npackages/docling-slim/   # slim package readme\ntests/                   # pytest suite and test data\ndocs/                    # MkDocs documentation and examples\nscripts/                 # project maintenance scripts\n```\n\n## Skills\n\n- **Development skills** (for contributors working *on* Docling) live in\n  [`.agents/skills/`](.agents/skills/) at the repo root, e.g. `dignified-python`\n  and `building-pydantic-ai-agents`.\n- **Usage skills** (for agents *using* Docling to convert documents) are shipped\n  inside the package at\n  [`docling/.agents/skills/docling/`](docling/.agents/skills/docling/SKILL.md).\n  They are packaged into the wheel/sdist so they are discoverable via\n  `uvx`-style library skills once `docling` is installed. Keep them in sync with\n  the CLI, the SDK (`PipelineOptions`), the Service Client, and the\n  `docling-slim` extras when user-facing behavior changes.\n\n## Key commands\n\n```bash\nmake setup          # install CI-style dev environment\nmake test           # run pytest\nmake check          # run read-only local checks\nmake validate       # run mutating hooks on the current changeset\n```\n\n## Code standards\n\n- Keep public APIs typed and compatible with Python 3.10+.\n- Use `uv add` or project-local dependency patterns when dependencies change.\n- Add focused tests for behavior changes; regenerate reference data only when\n  conversion outputs intentionally change.\n- Prefer structured models over loose dictionaries for durable schema-like data. Use Pydantic models or dataclasses when data crosses module boundaries, is serialized, or represents a stable contract. Exceptions may apply for internal datatypes and trivial data structures.\n- Prefer `pathlib.Path` for path-handling code. Use `Path` operations instead of `os.path` in new or edited code unless an API explicitly requires string paths.\n- Avoid `hasattr(...)`, broad `getattr(...)`, and similar attribute-probing patterns. These usually hide interface uncertainty. If such a check is genuinely required for compatibility with a documented third-party API, keep it narrowly scoped and explain in a comment.\n- Do not add trivial or self-validating tests. Tests should verify meaningful application behavior, regressions, or integration boundaries, not restate assumptions about well-established library functionality or implementation details introduced only to validate the agent’s own code changes. Avoid mock-heavy tests unless mocking is the clearest way to exercise a real contract or failure mode.\n\n## When making changes\n\n1. Keep edits scoped and consistent with the surrounding module.\n2. Update docs/examples when user-facing behavior changes.\n3. Run targeted tests for touched behavior.\n4. For reference output changes, use `DOCLING_GEN_TEST_DATA=1 uv run pytest`\n   and review generated data carefully.\n\n## Before finishing\n\nRun `make validate` before considering a task complete. If hooks modify files,\nreview the changes and rerun `make validate` until it passes cleanly. Also run\nthe affected tests for the files or behavior you changed. Use `make check` when\nyou need a read-only verification pass.\n","CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Project Overview\n\n@AGENTS.md\n"},"files":{"AGENTS.md":"# Docling\n\nThis file provides guidance to AI coding agents when working with code in this\nrepository.\n\n## Project overview\n\nDocling is a Python SDK and CLI for converting PDFs, Office files, HTML,\nMarkdown, audio, images, XML, and other formats into a unified\n`DoclingDocument` representation for downstream AI workflows.\n\n## Project structure\n\n```text\ndocling/                 # main Python package\ndocling/.agents/skills/  # usage skills shipped inside the package (see below)\npackages/docling/        # full docling meta-package\npackages/docling-slim/   # slim package readme\ntests/                   # pytest suite and test data\ndocs/                    # MkDocs documentation and examples\nscripts/                 # project maintenance scripts\n```\n\n## Skills\n\n- **Development skills** (for contributors working *on* Docling) live in\n  [`.agents/skills/`](.agents/skills/) at the repo root, e.g. `dignified-python`\n  and `building-pydantic-ai-agents`.\n- **Usage skills** (for agents *using* Docling to convert documents) are shipped\n  inside the package at\n  [`docling/.agents/skills/docling/`](docling/.agents/skills/docling/SKILL.md).\n  They are packaged into the wheel/sdist so they are discoverable via\n  `uvx`-style library skills once `docling` is installed. Keep them in sync with\n  the CLI, the SDK (`PipelineOptions`), the Service Client, and the\n  `docling-slim` extras when user-facing behavior changes.\n\n## Key commands\n\n```bash\nmake setup          # install CI-style dev environment\nmake test           # run pytest\nmake check          # run read-only local checks\nmake validate       # run mutating hooks on the current changeset\n```\n\n## Code standards\n\n- Keep public APIs typed and compatible with Python 3.10+.\n- Use `uv add` or project-local dependency patterns when dependencies change.\n- Add focused tests for behavior changes; regenerate reference data only when\n  conversion outputs intentionally change.\n- Prefer structured models over loose dictionaries for durable schema-like data. Use Pydantic models or dataclasses when data crosses module boundaries, is serialized, or represents a stable contract. Exceptions may apply for internal datatypes and trivial data structures.\n- Prefer `pathlib.Path` for path-handling code. Use `Path` operations instead of `os.path` in new or edited code unless an API explicitly requires string paths.\n- Avoid `hasattr(...)`, broad `getattr(...)`, and similar attribute-probing patterns. These usually hide interface uncertainty. If such a check is genuinely required for compatibility with a documented third-party API, keep it narrowly scoped and explain in a comment.\n- Do not add trivial or self-validating tests. Tests should verify meaningful application behavior, regressions, or integration boundaries, not restate assumptions about well-established library functionality or implementation details introduced only to validate the agent’s own code changes. Avoid mock-heavy tests unless mocking is the clearest way to exercise a real contract or failure mode.\n\n## When making changes\n\n1. Keep edits scoped and consistent with the surrounding module.\n2. Update docs/examples when user-facing behavior changes.\n3. Run targeted tests for touched behavior.\n4. For reference output changes, use `DOCLING_GEN_TEST_DATA=1 uv run pytest`\n   and review generated data carefully.\n\n## Before finishing\n\nRun `make validate` before considering a task complete. If hooks modify files,\nreview the changes and rerun `make validate` until it passes cleanly. Also run\nthe affected tests for the files or behavior you changed. Use `make check` when\nyou need a read-only verification pass.\n","CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Project Overview\n\n@AGENTS.md\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Docling\n\nThis file provides guidance to AI coding agents when working with code in this\nrepository.\n\n## Project overview\n\nDocling is a Python SDK and CLI for converting PDFs, Office files, HTML,\nMarkdown, audio, images, XML, and other formats into a unified\n`DoclingDocument` representation for downstream AI workflows.\n\n## Project structure\n\n```text\ndocling/                 # main Python package\ndocling/.agents/skills/  # usage skills shipped inside the package (see below)\npackages/docling/        # full docling meta-package\npackages/docling-slim/   # slim package readme\ntests/                   # pytest suite and test data\ndocs/                    # MkDocs documentation and examples\nscripts/                 # project maintenance scripts\n```\n\n## Skills\n\n- **Development skills** (for contributors working *on* Docling) live in\n  [`.agents/skills/`](.agents/skills/) at the repo root, e.g. `dignified-python`\n  and `building-pydantic-ai-agents`.\n- **Usage skills** (for agents *using* Docling to convert documents) are shipped\n  inside the package at\n  [`docling/.agents/skills/docling/`](docling/.agents/skills/docling/SKILL.md).\n  They are packaged into the wheel/sdist so they are discoverable via\n  `uvx`-style library skills once `docling` is installed. Keep them in sync with\n  the CLI, the SDK (`PipelineOptions`), the Service Client, and the\n  `docling-slim` extras when user-facing behavior changes.\n\n## Key commands\n\n```bash\nmake setup          # install CI-style dev environment\nmake test           # run pytest\nmake check          # run read-only local checks\nmake validate       # run mutating hooks on the current changeset\n```\n\n## Code standards\n\n- Keep public APIs typed and compatible with Python 3.10+.\n- Use `uv add` or project-local dependency patterns when dependencies change.\n- Add focused tests for behavior changes; regenerate reference data only when\n  conversion outputs intentionally change.\n- Prefer structured models over loose dictionaries for durable schema-like data. Use Pydantic models or dataclasses when data crosses module boundaries, is serialized, or represents a stable contract. Exceptions may apply for internal datatypes and trivial data structures.\n- Prefer `pathlib.Path` for path-handling code. Use `Path` operations instead of `os.path` in new or edited code unless an API explicitly requires string paths.\n- Avoid `hasattr(...)`, broad `getattr(...)`, and similar attribute-probing patterns. These usually hide interface uncertainty. If such a check is genuinely required for compatibility with a documented third-party API, keep it narrowly scoped and explain in a comment.\n- Do not add trivial or self-validating tests. Tests should verify meaningful application behavior, regressions, or integration boundaries, not restate assumptions about well-established library functionality or implementation details introduced only to validate the agent’s own code changes. Avoid mock-heavy tests unless mocking is the clearest way to exercise a real contract or failure mode.\n\n## When making changes\n\n1. Keep edits scoped and consistent with the surrounding module.\n2. Update docs/examples when user-facing behavior changes.\n3. Run targeted tests for touched behavior.\n4. For reference output changes, use `DOCLING_GEN_TEST_DATA=1 uv run pytest`\n   and review generated data carefully.\n\n## Before finishing\n\nRun `make validate` before considering a task complete. If hooks modify files,\nreview the changes and rerun `make validate` until it passes cleanly. Also run\nthe affected tests for the files or behavior you changed. Use `make check` when\nyou need a read-only verification pass.\n","category":"root","tokens":910},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n## Project Overview\n\n@AGENTS.md\n","category":"root","tokens":38}]}