[Feature] Declarative YAML filter system for user-extensible patterns

Summary

Adopt a declarative YAML filter system (similar to snip) so users can add custom command handlers without forking rtk or waiting for upstream releases.

Problem

rtk's pattern matchers are hardcoded in the Rust binary. Adding a new tool/subcommand requires:

1. Open an issue (e.g., #1641 for kubectl exec/config, git checkout/switch, uv run)
2. Wait for maintainer review + PR + release cycle
3. Users in the meantime have no escape hatch — patterns the binary doesn't recognize fall through unfiltered.

Heavy users (~38K Bash commands/month in my data engineering work) hit unhandled patterns continuously. Even with v0.38.0's recent glab addition, top remaining gaps account for ~200K tokens/week of missed savings ‚Äî and the long tail of niche tools (per-user) compounds this.

Reference: snip's approach

snip ships 126 filters as YAML files in a filters/ directory. Each filter declares match conditions + an output pipeline:

# filters/kubectl-logs.yaml
name: "kubectl-logs"
match:
  command: "kubectl"
  subcommand: "logs"
pipeline:
  - action: "strip_ansi"
  - action: "dedup"
    normalize: ["\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}", "\\d+\\.\\d+\\.\\d+\\.\\d+"]
    top: 30
  - action: "truncate_lines"
    max: 120
on_error: "passthrough"

Key properties that benefit users:

• Extensible without recompile: users drop YAML in a config dir, no Rust toolchain needed.
• Generic fallback: filter without subcommand matches all subcommands of a command (e.g., kubectl-get.yaml catches kubectl exec, kubectl config, etc.)
• Per-user customization: project-specific patterns possible (~/.config/rtk/filters/myorg-cli.yaml)
• Community contributions: PR a YAML file vs. PR Rust code ‚Äî much lower barrier.

Proposed implementation for rtk

Suggested layered approach to avoid disrupting current users:

1. Phase 1 — Add YAML loader as fallback for commands not matched by built-in Rust handlers.
   • Search order: built-in Rust handlers ‚Üí ~/.config/rtk/filters/*.yaml ‚Üí passthrough.
   • This preserves all current behavior; YAML only fills gaps.
2. Phase 2 — Allow YAML to override built-ins (opt-in via flag/setting) for users who want full control.
3. Phase 3 — Migrate built-in handlers to YAML progressively, keeping Rust runtime for performance-critical primitives (dedup, ANSI strip).

Pipeline action vocabulary could start small (matching snip): strip_ansi, head, truncate_lines, dedup, keep_lines, remove_lines ‚Äî covers ~80% of filter logic.

Benefits

For users:

• Add filters for niche tools (uv run, glab, internal CLIs) without waiting on upstream.
• Per-org/per-project filters without forking rtk.
• Faster iteration on filter quality.

For maintainers:

• Reduce PR queue for "add handler X" requests.
• Built-in handlers can be authored as YAML by non-Rust contributors.
• Filter changes ship as data, not binary releases ‚Äî faster fix cycle.

Backward compatibility

• Phase 1 is purely additive (new fallback path). No existing behavior changes.
• Existing Rust handlers continue to take precedence by default.
• Users opt into YAML override later if desired.

Volunteer

Happy to:

• Test prototype builds against my workload (~1.2M tokens saved/month, 38K Bash commands/month).
• Contribute YAML filter authoring guide / examples.
• File follow-up FRs as the YAML vocabulary stabilizes.

Related

• #1641 ‚Äî Specific handler requests (kubectl exec/config, git checkout/switch, uv run). YAML approach would let users self-serve all of these without upstream changes.