Is your feature request related to a problem? Please describe.
I've noticed that rtk already does a great job supporting and extracting context for individual linters and formatters like mypy, ruff, and others. However, many repositories orchestrate these tools through a composite pre-commit setup rather than running them independently.
Because the project's formatting and linting rules are often locked inside .pre-commit-config.yaml, the AI might miss the full picture of the repository's constraints if it only looks for standalone linter config files.
Describe the solution you'd like
I'd like to propose adding support for parsing and tokenizing pre-commit configuration files. Since rtk already understands the concept of linters, supporting the framework that runs them feels like a natural extension.
I am framing this as an open-ended discussion because I'm not entirely sure what the "right" implementation looks like for rtk's architecture. Some possibilities:
- Should
rtk parse the .pre-commit-config.yaml to identify the underlying hooks (e.g., ruff, black, clippy) and extract their specific arguments/overrides to pass to the LLM?
- Or should it be handled differently, perhaps by generating a higher-level summary of the pre-commit constraints?
Describe alternatives you've considered
Continuing to rely on rtk reading standard generic files (like pyproject.toml or ruff.toml). The downside is that sometimes specific arguments, formatting overrides, or custom hooks are defined exclusively in the pre-commit yaml, meaning the true source of truth for the project's code standards is missed.
Additional context
Giving the LLM explicit context about a repository's pre-commit setup would help it generate code that passes the project's quality gates on the first try, reducing friction. I'd love to hear the maintainers' thoughts on whether this fits into the roadmap and the best way to approach it!
Is your feature request related to a problem? Please describe.
I've noticed that
rtkalready does a great job supporting and extracting context for individual linters and formatters likemypy,ruff, and others. However, many repositories orchestrate these tools through a compositepre-commitsetup rather than running them independently.Because the project's formatting and linting rules are often locked inside
.pre-commit-config.yaml, the AI might miss the full picture of the repository's constraints if it only looks for standalone linter config files.Describe the solution you'd like
I'd like to propose adding support for parsing and tokenizing
pre-commitconfiguration files. Sincertkalready understands the concept of linters, supporting the framework that runs them feels like a natural extension.I am framing this as an open-ended discussion because I'm not entirely sure what the "right" implementation looks like for
rtk's architecture. Some possibilities:rtkparse the.pre-commit-config.yamlto identify the underlying hooks (e.g.,ruff,black,clippy) and extract their specific arguments/overrides to pass to the LLM?Describe alternatives you've considered
Continuing to rely on
rtkreading standard generic files (likepyproject.tomlorruff.toml). The downside is that sometimes specific arguments, formatting overrides, or custom hooks are defined exclusively in thepre-commityaml, meaning the true source of truth for the project's code standards is missed.Additional context
Giving the LLM explicit context about a repository's
pre-commitsetup would help it generate code that passes the project's quality gates on the first try, reducing friction. I'd love to hear the maintainers' thoughts on whether this fits into the roadmap and the best way to approach it!