feat: Extend git subcommand coverage (ls-files, rm, tag)

[LMS927369]

The rtk git handler covers diff, status, log, add, stash, show, branch, worktree, fetch, pull, push — but misses several commonly-used subcommands.

Currently not intercepted:

$ rtk hook check "git ls-files"     # → exit 1, no rewrite ✗
$ rtk hook check "git rm"           # → exit 1, no rewrite ✗
$ rtk hook check "git tag"          # → exit 1, no rewrite ✗
$ rtk hook check "git cherry-pick"  # → exit 1, no rewrite ✗
$ rtk hook check "git rebase"       # → exit 1, no rewrite ✗
$ rtk hook check "git merge"        # → exit 1, no rewrite ✗
$ rtk hook check "git checkout"     # → exit 1, no rewrite ✗

Highest value:

• git ls-files (98 calls/month) — in monorepos this can return hundreds of paths. Compact tree output (like rtk find) would be ideal.
• git rm (92 calls/month) — bulk deletes produce one rm 'path' line per file. Summary format would help.

Lower priority (write operations where full output matters for confirmation):

• git cherry-pick, git rebase, git merge, git checkout — these have important status output but could still benefit from ANSI stripping.

Usage context: ~280 calls/month for the missing subcommands, primarily in a 12-service monorepo with Claude Code.

[pszymkowiak]

[w] wshm · Automated triage by AI

🔍 Automated Triage

✨ Category	feature
🟡 Priority	medium
🎯 Confidence	95%

Summary

Request to extend rtk git handler to cover additional subcommands (ls-files, rm, tag, cherry-pick, rebase, merge, checkout); well-scoped with usage data provided.

---

Triaged automatically by wshm · This is an automated analysis, not a human review.

[VictorAurelius]

+1 with concrete data from a different project (multi-service Java+TS monorepo, kitehub/kiteclass platform).

rtk discover over 30 days, 123 sessions:

git checkout               352    git checkout -b feature/roadmap-refres..
git cherry-pick             29    git cherry-pick 3fc5e5aa 2>&1

381 calls combined for just these two — second-highest unhandled-command category in this project after mvn/mvnw (188 + 25, tracked separately as a hook-routing gap I just filed).

Pain points specific to this codebase:

• git checkout -b wave/X.Y-... is the canonical wave-branch creation pattern (we ship sub-PRs frequently)
• git cherry-pick heavily used during wave-branch consolidation when sub-PRs need to land in a specific order
• Both produce 5-30 lines of output that ANSI-stripping + summarization could collapse to 1-3 lines

For git checkout, the highest-value compression is probably:

• Strip the ANSI color codes around branch names
• Collapse the "Switched to ... " + "Your branch is up to date" / "Your branch is ahead by N commits" into one line
• For checkout-with-N-files-changed, summarize the file count instead of listing each

For git cherry-pick, the typical output [<branch> <sha>] <subject> plus a 1-line file-changed summary is already concise — main saving is from auto-handling conflict noise (which RTK might choose to leave verbose intentionally for human review).

Happy to test PRs against this codebase if useful.