[Feature] Add handlers for kubectl exec/config, git checkout/switch, glab, uv run
#1,641 opened on Apr 30, 2026
Repository metrics
- Stars
- (48,085 stars)
- PR merge metrics
- (Avg merge 11d 1h) (45 merged PRs in 30d)
Description
Summary
Across 30 days of data engineering work (38,377 Bash commands tracked via rtk discover), top patterns rtk doesn't handle account for ~250-300K tokens/week of missed savings.
Top unhandled patterns
| Pattern | Count/30d | Example | Suggested handler |
|---|---|---|---|
kubectl exec POD -- cmd |
907 | kubectl exec -n database postgres-0 -- psql ... |
Filter exec output (similar to existing rtk kubectl logs) |
kubectl config <subcmd> |
190 | kubectl config get-contexts |
Filter context list output |
git checkout <branch> |
439 | git checkout dev |
Add to rtk git handlers |
git switch <branch> |
(subset) | git switch dev |
Same — add to rtk git |
glab ci view / glab mr create |
290 | glab ci view 1412676 |
New rtk glab handler (similar to rtk gh) |
uv run <script> |
127 | uv run --isolated pytest tests/ |
New rtk uv handler (similar to rtk pip) |
Bonus: kubectl flag-before-subcommand pattern
The largest miss class is kubectl --context X -n NS <subcommand> and kubectl -n NS <subcommand>. The matcher only catches kubectl <subcommand> [flags]. Could the matcher be enhanced to recognize flag-before patterns for output filtering purposes? This would recover thousands of commands per week per heavy user.
Why this matters
Heavy users in DevOps / data engineering contexts hit these patterns continuously. Even with behavioral guidance (telling the assistant to put flags AFTER subcommand), kubectl exec and glab simply have no rtk handler today.
Volunteer
Happy to help test new handlers if useful.