Code2Prompt: your codebase rendered as one Markdown prompt

--path takes a file, a directory, or the same flag three times

The invocation has one required argument, `--path`, and it is repeatable:

code2prompt --path /path/to/your/code [OPTIONS]

code2prompt --path /path/to/dir1 --path /path/to/file2.py [OPTIONS]

So a mixed selection of directories and files is expressed by repeating the flag rather than by a glob, which keeps the tool predictable when a project has an unusual layout. `--path` has the short form `-p`, `--output` is `-o`, `--gitignore` is `-g`, and `--filter` is `-f` for comma-separated patterns to include.

Three quick-start examples cover the cases most people need. A single file is just the path. A whole project becomes a file with `--output project_summary.md`. And multiple roots with a glob exclusion:

code2prompt --path /path/to/src --path /path/to/lib --exclude "*/tests/*" --output codebase_summary.md

Output is either written to a file or printed to the console, and the clipboard is a destination too, since the feature list includes being clipboard-ready for a quick paste into a chat window.

The output is a Markdown document, not a raw concatenation

The tool's claim is a well-structured Markdown prompt that captures the project's essence, and the structure is what separates it from `cat`-ing every file together.

Two pieces of that structure are named separately in the feature list. The first is an intelligent source tree generation: a clear hierarchical view of the codebase structure, so a model can see how the files relate before reading any of them. The second is enhanced code readability, which means adding line numbers inside the source blocks so a conversation can refer to a specific line rather than to a file and a guess.

The rest of the format is delivery. Output can go to a named Markdown file with `--output`, be printed to the console, or be copied to the clipboard, which is why `pyperclip` and `colorama` are both direct dependencies rather than optional extras.

The intended uses are stated as code analysis, documentation and improvement tasks, with additional claims about interdependency analysis for refactoring and about helping a model pick up project-specific patterns and idioms. Those last two are model-side effects rather than things the tool can enforce, which is worth keeping in mind when a prompt looks like it is reasoning well.

--syntax-map teaches the highlighter about your own extensions

Custom file extensions are handled by pairing an extension with a syntax name, in the format `extension:syntax`, through the `--syntax-map` option:

code2prompt --path /path/to/your/code --syntax-map "inc:bash,customext:python,ext2:javascript"

That treats `.inc` files as bash, `.customext` files as python and `.ext2` files as javascript. Mappings can be comma-separated inside one value, or the option can be repeated, and both forms work with ordinary invocations:

code2prompt --path /path/to/your/script.py --syntax-map "inc:bash"

code2prompt --path /path/to/your/project --syntax-map "inc:bash,txt:markdown" --output project_summary.md

The reason this matters is that the output is Markdown with fenced blocks, and a fence labelled for the wrong language changes how a model reads the code. A `.inc` include file rendered as plain text loses its quoting; the same file rendered as bash keeps it.

It is also the option people tend to miss, since it is absent from the first two installation examples and appears only in the syntax highlighting section.

Token counting is a feature, not an afterthought

Smart token management is one of the named capabilities: counting and optimising tokens so the result stays compatible with various LLM token limits, which the feature list frames as preventing errors during processing.

The implementation choice is visible in the dependency list, where `tiktoken` at `^0.7.0` is annotated as being there for tokenization tasks. That means counts are computed with OpenAI's encoding rather than with a character or word heuristic, so a count is comparable with what a model will actually see, at least for the encodings tiktoken knows about.

That dependency is also the reason the tool cannot count every model's vocabulary for you. If your provider's tokenizer differs, the number is an approximation, and the useful habit is to treat the output as a size signal rather than as a hard limit.

The tool also has a configuration file, `.code2promptrc`, whose presence at the repository root doubles as the documented example, plus a `TEMPLATE.md` and a `docs/` directory for the template reference.

Gitignore plus globs, and the difference between filter and exclude

Two mechanisms decide what gets into the prompt, and they answer different questions.

Gitignore integration is about accuracy of representation: the feature is described as respecting your project's `.gitignore` rules so irrelevant files are excluded from processing. The option is `--gitignore`, short `-g`, taking the path to the file to use, which means it can point at a non-default location or at another repository's ignore file.

Glob patterns are about deliberate selection. `--filter` takes comma-separated patterns to include, `--exclude` takes glob patterns to drop, and the quick-start example uses `--exclude "*/tests/*"` to build a prompt about the source rather than about the test suite.

The difference in practice: a gitignore expresses what is not source, while a filter expresses what you want discussed. Combining them is what keeps vendored directories, lock files and build output out of a prompt that is meant to explain your architecture.

The tool's own repository uses both conventions on itself, with a `.gitignore` at the root and a `.cursorrules` file beside it for editor-assistant rules.

Jinja2 templates, with imports and input variables

Output shape is a Jinja2 template rather than a hardcoded string, listed as customizable prompt templates that let you tailor the output to a specific AI task, and `jinja2` at `^3.1.4` is the dependency annotated as being for template rendering.

Two template features are called out separately and both matter for anything beyond a one-off run. Template import support allows modular template design, so a header, a file section and a footer can live in separate files instead of one large template. Input variables in templates enable dynamic prompt generation based on user input, which is the hook for a task description, a target language or a focus area.

The build manifest ships the templates as package data, which is the detail that makes any of this work after installation: `code2prompt/templates/**/*` is included in the Poetry package list and repeated in a setuptools `package-data` mapping. So the templates are files inside the installed package, and a custom template has to live somewhere your Jinja2 environment can find.

The repository carries `TEMPLATE.md` and a `docs/` directory for reference, and the pyproject entry point is `code2prompt.main:cli`, so the CLI is one function in the main module.

Poetry, version 0.9.0, Beta status, and classifiers that stop at 3.11

The packaging metadata tells you where the project stands. It builds with Poetry and `poetry-core`, sits at version `0.9.0`, is classified as `Development Status :: 4 - Beta`, and is licensed MIT with the licence file named `LICENCE.md` in the British spelling. There are no GitHub releases, so the PyPI version is the only version marker, and the last push to `master` was 2026-07-07.

The Python constraint is `^3.8,<4.0`, while the classifiers list only 3.8 through 3.11. That gap is cosmetic but confusing on PyPI, since the package installs on newer interpreters while claiming untested support.

Every direct dependency carries a one-line comment explaining its job: `rich` for rich text and formatting, `click` for the command-line interface, `jinja2` for templates, `tiktoken` for tokenization, `pyperclip` for clipboard operations, `colorama` for coloured terminal output, plus `tqdm`, `tabulate`, `pydantic`, `prompt-toolkit` and `colorlog`. Dev tooling is broader than most projects of this size, with pytest, ruff, pylint and `vulture` for dead-code detection.

One redundancy is worth noting: the file carries both Poetry's `include` and a `[tool.setuptools]` `package-data` block, even though the build backend is Poetry alone. It does no harm, but it means the package layout is declared twice.

Editorial conclusion

Code2Prompt fits a developer who wants to hand a model a real slice of a repository rather than a few pasted snippets, especially for architecture questions, documentation drafts and refactoring discussions where the source tree matters. It does not fit a workflow that expects the tool to read your intent, because it produces text and stops, and any per-task framing has to come from your own template or from input variables. Check three things before you rely on it: that your `.gitignore` is passed or found, since generated files otherwise flood the prompt; that `--syntax-map` covers your own extensions, since an unlabelled fence changes how the code reads; and that you have looked at the token count, because `tiktoken` counts with OpenAI's encoding and that number is an approximation for any other provider. Install it with pipx rather than pip if you can, since the recommended path keeps its eleven dependencies out of your project environment.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. raphaelmansuy/code2prompt on GitHub
4. README