Markdownizer

Extract existing documentation from Python projects into Markdown.

Markdownizer never generates, rewrites, summarizes, or improves documentation. It only extracts what is already present in your source code: docstrings, comments, decorators, and source.

Installation

pip install markdownizer

Or with pipx for an isolated CLI:

pipx install markdownizer

Requires Python 3.9+. No runtime dependencies.

Usage

CLI

markdownizer /path/to/project -o ./docs

This recursively scans the project, parses every Python file with the AST, builds a deterministic Project IR, and writes one Markdown file per package into ./docs.

The compiler-style form is equivalent and supports format selection:

markdownizer build /path/to/project -o ./docs --format markdown
markdownizer build /path/to/project -o ./docs --format json
markdownizer build /path/to/project -o ./docs --format compact

Budgeted context

Produce the best possible representation of a project within a token budget:

markdownizer context . --max-tokens 20000 --profile api
markdownizer context . --profile django --query "user model"

Writes context.md. Options: --max-tokens (default 20000), --profile (architecture default, api, debugging, refactor, django, onboarding), --rank (pagerank default, fanout, simple), and --query (deterministic keyword prefilter).

Statistics

markdownizer stats . --rank pagerank
markdownizer stats . --json

Shows project counts, a token estimate, and top-ranked files/symbols. Ranking is deterministic: PageRank over the import graph with framework-aware boosts (Django models, URL configs, management commands), combined with public/documented factors per symbol.

Common options:

markdownizer . -o ./docs \
  --exclude "tests/*" --exclude "migrations" \
  --only-documented --no-source

Run markdownizer --help for the full list.

Python API

from pathlib import Path
from markdownizer import extract_project, build_project_ir, optimize_context

written = extract_project(
    Path("."),
    Path("docs"),
    exclude=["tests/*"],
    include_source=False,
)
print(written)  # list of written output files

# Or build the Project IR directly:
ir = build_project_ir(Path("."), exclude=["tests/*"])
print(ir.ir_version, ir.hash, ir.stats.symbol_count)

# Or generate a budgeted, ranked context artifact:
ctx = optimize_context(ir, max_tokens=20000, profile="api", query="auth")
print(ctx.estimated_tokens, ctx.included_symbols)
print(ctx.text)

Output formats

The pipeline builds a deterministic Project IR (packages → modules → symbols, plus import/inherit/define edges) and renders it through a backend:

The legacy invocation markdownizer <project> -o <out> is kept as a compatibility alias for markdownizer build <project> --format markdown.

Signature mode

Instead of full source or no source, extract_project() accepts include_source="signature" to emit only declaration lines:

extract_project(Path("."), Path("docs"), include_source="signature")

Functions render as def foo(x: int = 1) -> str:, async functions as async def ..., classes as class User(models.Model): (with base classes), and methods with their parameters. Modules render without source. The boolean modes (True/False) are unchanged.

Project IR

build_project_ir(project_root, exclude=None) returns a ProjectIR with:

• ir_version — schema version (currently 1), independent of the package version
• packages, modules, symbols — the project hierarchy
• imports, inherits, defines — relationship edges
• stats — file/module/symbol counts
• hash — deterministic blake2b of the canonical IR content

The hash and JSON serialization are deterministic: the same repository content always produces the same hash and the same project.json, making the output suitable for version control and caching. Machine-specific metadata (root, python_version, git) is excluded from the hash.

Import resolution is conservative and fully static: project code is never imported or executed. Imports that cannot be resolved to a project module are marked external.

What is extracted

For every documented object (modules, packages, classes, dataclasses, enums, functions, async functions, methods, properties, Django models, Django forms, Django admin classes, DRF serializers, DRF viewsets, signals, middleware, management commands, URL configuration, and any other object with a docstring):

• The docstring, verbatim
• Comments that belong to the object (preceding and inline)
• Decorators
• The complete source code

Output format

Each generated Markdown file groups all modules inside a single package and uses specialized headers such as:

# Django Model: User
# DRF Serializer: UserSerializer
# DRF ViewSet: UserViewSet
# Enum: Status
# Dataclass: Point
# Async Function: fetch_data

Every section preserves the original formatting of the source documentation.

Development

See CONTRIBUTING.md for setup, checks, and release steps. Changes are recorded in CHANGELOG.md.

License

MIT — see LICENSE.