agentleFS
MarkPDFdownMarkPDFdown/markpdfdown/AGENTS.md

markpdfdown

AGENTS.md2.3k starsChanged 14 months agoApache-2.0View on GitHub

This file provides guidelines for AI agents working in this repository. markpdfdown - A tool that converts PDF documents and images to Markdown format using LLM vision capabilities. The project is built with Python 3.9+, uses uv for package management, ruff for linting/formatting, and pytest for testing. All commands should be run from the project root directory. Note: Test files should be placed in the tests/ directory. Test fixtures (sample PDFs, images, expected outputs) are in tests/cases/. Organize imports in…

We split this AGENTS.md into the rules it gives an agent

17 rules. About 0 are common, 6 are distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    All commands should be run from the project root directory.

    line 11
  2. Distinctive:

    Use relative imports for intra-package imports:

    line 60
  3. Very specific:

    Use make format to auto-format code.

    line 74
  4. Distinctive:

    Use Python type hints for function signatures:

    line 78
  5. Very specific:

    Avoid Union in favor of | syntax (e.g., str | None), but note that UP007 (use X | Y for type annotations) is ignored in the ruff config.

    line 91
  6. Distinctive:

    Write docstrings for all public functions, methods, and classes:

    line 103
  7. Distinctive:

    Use try/except blocks with specific exception types when possible

    line 121
  8. Very specific:

    Use logger.error(f"message: {str(e)}") for error logging

    line 123
  9. Very specific:

    Use logging.basicConfig in the main entry point:

    line 134
  10. Distinctive:

    Use parameterized logging in functions:

    line 144
  11. Very specific:

    Before committing, run make check to ensure all files pass pre-commit validation:

    line 182
  12. Very specific:

    Add production dependencies to dependencies in pyproject.toml

    line 193
  13. Very specific:

    Add development dependencies to dev in dependency-groups

    line 194
  14. Very specific:

    Run make update to refresh lock file and pre-commit hooks

    line 195
  15. Very specific:

    Factory pattern: Use create_worker() function in file_worker.py to instantiate appropriate worker class based on file type

    line 199
  16. Very specific:

    File handling: Use context managers (with open(...)) for file operations

    line 202
  17. Very specific:

    Path handling: Use os.path for cross-platform path operations

    line 203

≈ “Common” is an estimate: at least 1 in 5 of the 36,368 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

AGENTS.md

This file provides guidelines for AI agents working in this repository.

Project Overview

markpdfdown - A tool that converts PDF documents and images to Markdown format using LLM vision capabilities. The project is built with Python 3.9+, uses uv for package management, ruff for linting/formatting, and pytest for testing.

Build, Lint, and Test Commands

All commands should be run from the project root directory.

Installation

make install    # Install dependencies with uv sync

Development Tools

make format     # Format code with ruff format
make lint       # Run ruff check (no auto-fix)
make fix        # Auto-fix linting issues with ruff
make check      # Run all pre-commit hooks on all files
make update     # Update lock file and pre-commit hooks

Testing

make test       # Run all tests with pytest
uv run pytest   # Alternative: run tests with uv
uv run pytest tests/test_file.py  # Run specific test file
uv run pytest -v tests/test_file.py::test_function_name  # Run single test
uv run pytest -k "test_name"  # Run tests matching pattern

Note: Test files should be placed in the tests/ directory. Test fixtures (sample PDFs, images, expected outputs) are in tests/cases/.

Code Style Guidelines

Imports

Organize imports in three sections separated by blank lines:

  1. Standard library imports
  2. Third-party imports
  3. Local application imports
import logging
import os
from typing import Optional

import litellm

from markpdfdown.core import FileWorker

Use relative imports for intra-package imports:

from .core.file_worker import FileWorker, PDFWorker, ImageWorker
from .core.llm_client import LLMClient

Formatting

  • Line length: 88 characters (ruff default)
  • Indent style: Spaces (4 spaces per level)
  • Quote style: Double quotes
  • Trailing whitespace: None
  • EOF: Final newline required

Use make format to auto-format code.

Type Annotations

Use Python type hints for function signatures:

def completion(
    self,
    user_message: str,
    system_prompt: Optional[str] = None,
    image_paths: Optional[list[str]] = None,
    temperature: float = 0.3,
    max_tokens: int = 8192,
    retry_times: int = 3,
) -> str:

Avoid Union in favor of | syntax (e.g., str | None), but note that UP007 (use X | Y for type annotations) is ignored in the ruff config.

Naming Conventions

  • Classes: PascalCase (e.g., PDFWorker, LLMClient)
  • Functions and variables: snake_case (e.g., convert_to_images, input_path)
  • Modules/Files: snake_case (e.g., file_worker.py, llm_client.py)
  • Constants: UPPER_SNAKE_CASE
  • Private methods/variables: Prefix with underscore (e.g., _encode_image)

Docstrings

Write docstrings for all public functions, methods, and classes:

def remove_markdown_wrap(text: str, language: str = "markdown") -> str:
    """
    Remove markdown code block wrapper from text

    Args:
        text: The input text to process
        language: The markdown language tag to remove

    Returns:
        str: The processed text with markdown fences removed
    """

Error Handling

  • Use try/except blocks with specific exception types when possible
  • Log errors using the module logger before re-raising or returning
  • Use logger.error(f"message: {str(e)}") for error logging
  • Define module-level logger at the top of each file:
import logging

logger = logging.getLogger(__name__)

Logging Configuration

Use logging.basicConfig in the main entry point:

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s - %(name)s - %(levelname)s - %(message)s",
    handlers=[logging.StreamHandler(sys.stderr)],
)

Use parameterized logging in functions:

logger.info("Processing PDF from page %d to page %d", start_page, end_page)

File Structure

markpdfdown/
├── src/markpdfdown/       # Source code (src layout)
│   ├── __init__.py        # Package init with version
│   ├── __main__.py        # Module entry point
│   ├── cli.py             # CLI entry point
│   ├── config.py          # Configuration
│   ├── main.py            # Core conversion functions
│   └── core/              # Core implementation
│       ├── __init__.py    # Core module exports
│       ├── file_worker.py # FileWorker, PDFWorker, ImageWorker, create_worker
│       ├── llm_client.py  # LLMClient for API calls
│       └── utils.py       # Utility functions
├── tests/
│   ├── __init__.py        # Tests package init
│   ├── conftest.py        # Pytest fixtures and configuration
│   ├── test_cli.py        # CLI module tests
│   ├── test_config.py     # Config module tests
│   ├── test_file_worker.py # FileWorker tests
│   ├── test_llm_client.py # LLMClient tests (mocked)
│   ├── test_main.py       # Main conversion tests (mocked)
│   ├── test_utils.py      # Utility function tests
│   └── fixtures/          # Test fixtures
│       ├── images/        # Test images
│       ├── pdfs/          # Test PDFs
│       └── expected/      # Expected outputs
└── pyproject.toml         # Project configuration

Pre-commit Hooks

Before committing, run make check to ensure all files pass pre-commit validation:

  • ruff (format + lint with auto-fix)
  • trailing-whitespace
  • end-of-file-fixer
  • check-yaml
  • check-toml
  • check-merge-conflict
  • check-added-large-files

Dependency Management

  • Add production dependencies to dependencies in pyproject.toml
  • Add development dependencies to dev in dependency-groups
  • Run make update to refresh lock file and pre-commit hooks

General Patterns

  1. Factory pattern: Use create_worker() function in file_worker.py to instantiate appropriate worker class based on file type
  2. Base classes: Define abstract interfaces in FileWorker (ABC) with abstract methods
  3. Error messages: Include file paths and specific error context in error messages
  4. File handling: Use context managers (with open(...)) for file operations
  5. Path handling: Use os.path for cross-platform path operations
  6. Src layout: Project uses src/markpdfdown/ layout for package source code

Download now (ZIP)

Trending

Quiet since January.thin dataabout the whole repository

Dec 2025: 0 mentionsJan 2026: 1 mentionFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 0 mentionsJun 2026: 0 mentionsJul 2026: 0 mentionsAug 2026: 0 mentionsSep 2026: 0 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the MarkPDFdown/markpdfdown repository that our weekly crawl found: only 4 in all, so this is a hint, not a trend. There is no adoption data for this file yet.
  • Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.

    Of the AGENTS.md files we read, the 28,693 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.