rtk-ai/rtk

Allow user TOML filters to customize built-in command output

Open

#821 opened on Mar 25, 2026

View on GitHub
 (1 comment) (0 reactions) (0 assignees)Rust (2,914 forks)batch import
area:configeffort-mediumenhancementfilter-qualityhelp wantedpriority:medium

Repository metrics

Stars
 (48,085 stars)
PR merge metrics
 (Avg merge 11d 1h) (45 merged PRs in 30d)

Description

Problem

Built-in Rust commands (git, kubectl, npm, docker, etc.) are routed by Clap before the TOML engine runs. User TOML filters can only target commands that RTK doesn't already handle natively.

This means there's no way to customize how built-in commands filter output. For example, kubectl top and kubectl exec go through the built-in kubectl handler, but their output characteristics are very different from kubectl get. A user can't write a TOML filter to handle kubectl top differently because kubectl as a whole is claimed by the Rust binary.

Use case

# This doesn't work — kubectl is a built-in command
[filters.kubectl-top]
description = "Compact kubectl top output"
match_command = "^kubectl\\s+top\\b"
strip_ansi = true
strip_lines_matching = ["^\\s*$"]

The TOML engine never sees kubectl top because Clap routes all kubectl * to the built-in handler first.

Proposed approach

Allow user TOML filters to match specific subcommands of built-in commands. For example, if a user defines a filter matching ^kubectl\s+top\b, it should take precedence over the generic built-in kubectl handler for that specific subcommand pattern.

The priority could be: user TOML (specific subcommand match) > built-in Rust handler > user TOML (generic).

Happy to send a PR if this approach makes sense.

Contributor guide