[Feature] Add handlers for kubectl exec/config, git checkout/switch, glab, uv run
#1.641 aberto em 30 de abr. de 2026
Métricas do repositório
- Stars
- (48.085 stars)
- Métricas de merge de PR
- (Mesclagem média 11d 1h) (45 fundiu PRs em 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.