Summary
Add a rtk textutil proxy that wraps macOS's textutil for token-optimized document-text extraction.
Motivation
textutil is the standard macOS tool for converting between document formats (.docx, .doc, .rtf, .html, .txt, …). A very common LLM-assistant pattern is converting a document to plain text and piping the result into context:
textutil -convert txt -stdout resume.docx
The raw output is the entire document body, often thousands of tokens, with no filtering — exactly the kind of large, repetitive system output rtk is designed to compress. Today every such call hits the LLM context at full size because textutil is unhandled.
In my own usage over the last 30 days, rtk discover flagged textutil as one of the top unhandled commands (7 invocations), all of them document-to-text conversions feeding an assistant.
Proposed behavior
A rtk textutil subcommand that:
- Passes native
textutil flags straight through (-convert, -stdout, -cat, -info, etc.) so it's a drop-in replacement.
- For text output, applies the same intelligent filtering
rtk read already uses — collapse runs of blank lines, strip trailing whitespace, optionally truncate with a [N more lines] marker.
- For
-info output, emits a compact one-line summary instead of the multi-line property block.
- Falls back to raw passthrough on any unrecognized invocation (no behavior change).
Why it fits rtk
rtk already proxies ls, cat/read, grep, find, json, etc. textutil is the same shape — a noisy, high-token system command — and is macOS-native, so it's relevant to a large share of the user base. Reusing the existing read/filtering pipeline should keep the implementation small.
Environment
- rtk 0.42.0 (Homebrew)
- macOS (Darwin 25.5.0)
Summary
Add a
rtk textutilproxy that wraps macOS'stextutilfor token-optimized document-text extraction.Motivation
textutilis the standard macOS tool for converting between document formats (.docx,.doc,.rtf,.html,.txt, …). A very common LLM-assistant pattern is converting a document to plain text and piping the result into context:The raw output is the entire document body, often thousands of tokens, with no filtering — exactly the kind of large, repetitive system output
rtkis designed to compress. Today every such call hits the LLM context at full size becausetextutilis unhandled.In my own usage over the last 30 days,
rtk discoverflaggedtextutilas one of the top unhandled commands (7 invocations), all of them document-to-text conversions feeding an assistant.Proposed behavior
A
rtk textutilsubcommand that:textutilflags straight through (-convert,-stdout,-cat,-info, etc.) so it's a drop-in replacement.rtk readalready uses — collapse runs of blank lines, strip trailing whitespace, optionally truncate with a[N more lines]marker.-infooutput, emits a compact one-line summary instead of the multi-line property block.Why it fits rtk
rtkalready proxiesls,cat/read,grep,find,json, etc.textutilis the same shape — a noisy, high-token system command — and is macOS-native, so it's relevant to a large share of the user base. Reusing the existingread/filtering pipeline should keep the implementation small.Environment