Claude Code hook: `tail -N` rewrite produces invalid `rtk read -N` (should be `-n N`)

Summary

The Claude Code Bash tool hook that transparently rewrites tail <file> to rtk read <file> mishandles the short numeric flag form tail -N. It produces rtk read -N, which is not a valid rtk read invocation — rtk's read subcommand expects -n N (separate flag + value).

Environment

• Claude Code hook: the one that transparently rewrites common CLI commands (git, tail, head, etc.) to rtk <cmd> for token savings

Reproduction

Inside a Claude Code session with the rtk hook active, run any of these:

tail -20 /some/file
tail -5 /some/file
tail -100 /var/log/foo.log

Observed: the hook rewrites these to rtk read -20 /some/file (or -5, -100), which rtk rejects as an invalid argument.

Expected: the hook should rewrite to rtk read -n 20 /some/file (or the rtk equivalent of "last N lines"), separating the short flag letter from the numeric value.

Root cause (speculative)

GNU/BSD tail accepts the combined form tail -20 file (where -20 means "last 20 lines") as a legacy shorthand for tail -n 20 file. The hook's rewrite regex likely copies the argument verbatim into rtk's argv, but rtk's argument parser does not accept -20 as a valid flag — it expects -n 20.

Suggested fix

In the hook's rewrite logic for tail, detect the combined-short-form -<digits> pattern and normalize it to -n <digits> before inserting the rtk read prefix. Or: normalize to -n <digits> as part of a general tail argv canonicalization step, independent of the rtk substitution.

Impact

Low severity in isolation (user sees an rtk error and falls back to manual invocation), but it's a papercut that happens every time a user types a legacy-form tail -N. The failure mode is "command errors" rather than "command silently does the wrong thing," which is the right failure mode — but fixing it would eliminate the papercut.