{"owner":"docling-project","repo":"docling","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":1815,"categories":["root-instruction","claude-rule","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"docling":{"command":"npx","args":["-y","@modelcontextprotocol/server-docling"]}}},"found":["AGENTS.md","CLAUDE.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# Docling\n\nThis file provides guidance to AI coding agents when working with code in this\nrepository.\n\n## Communication\n\nUse ASD-STE100 Simplified Technical English when you communicate with the user.\nUse short sentences, active voice, and consistent terms. Keep code identifiers,\nAPI names, and quoted source text exact. State the result and any limits clearly.\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  Select the applicable skills from the\n  [task routes](.agents/skills/skill-router.json). For PR reviews and re-reviews,\n  use [review](.agents/skills/review/SKILL.md) before you assess the changes.\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",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# Docling\n\nThis file provides guidance to AI coding agents when working with code in this\nrepository.\n\n## Communication\n\nUse ASD-STE100 Simplified Technical English when you communicate with the user.\nUse short sentences, active voice, and consistent terms. Keep code identifiers,\nAPI names, and quoted source text exact. State the result and any limits clearly.\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  Select the applicable skills from the\n  [task routes](.agents/skills/skill-router.json). For PR reviews and re-reviews,\n  use [review](.agents/skills/review/SKILL.md) before you assess the changes.\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",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/docling-project/docling/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Docling\n\nThis file provides guidance to AI coding agents when working with code in this\nrepository.\n\n## Communication\n\nUse ASD-STE100 Simplified Technical English when you communicate with the user.\nUse short sentences, active voice, and consistent terms. Keep code identifiers,\nAPI names, and quoted source text exact. State the result and any limits clearly.\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  Select the applicable skills from the\n  [task routes](.agents/skills/skill-router.json). For PR reviews and re-reviews,\n  use [review](.agents/skills/review/SKILL.md) before you assess the changes.\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","isInternal":false,"tokens":879,"sizeBytes":4103},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/docling-project/docling/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","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","isInternal":false,"tokens":36,"sizeBytes":149},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/docling-project/docling/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":202},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/docling-project/docling/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":188},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/docling-project/docling/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":181}],"systemPromptSnippet":"<yakaai_skills repo=\"docling-project/docling\">\n<!-- File: AGENTS.md (Tokens: ~879 | Category: root-instruction) -->\n# Docling\n\nThis file provides guidance to AI coding agents when working with code in this\nrepository.\n\n## Communication\n\nUse ASD-STE100 Simplified Technical English when you communicate with the user.\nUse short sentences, active voice, and consistent terms. Keep code identifiers,\nAPI names, and quoted source text exact. State the result and any limits clearly.\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  Select the applicable skills from the\n  [task routes](.agents/skills/skill-router.json). For PR reviews and re-reviews,\n  use [review](.agents/skills/review/SKILL.md) before you assess the changes.\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\n<!-- File: CLAUDE.md (Tokens: ~36 | Category: claude-rule) -->\n# 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\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/docling-project/docling/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}