You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Would an opt-in Texio recipe complement RTK on named Markdown tasks?
#4946
RTK's contribution guide distinguishes bash-output reduction from billing savings and favors transparent filters. I am proposing an explicit companion recipe for a user-requested Markdown section task, rather than a core filter or a rewrite of arbitrary read commands. Would maintainers or users be interested in comparing RTK's current read/edit workflow with Texio selecting a named section before the output enters context? This targets operation selection upstream of output compression; whether it adds value over RTK's current file operations needs measurement. No request to add a core dependency.
I maintain Texio, an MIT-licensed early-preview CLI. A minimal disposable-file trial with Texio 0.1.3 installed is:
The preview does not write. Replacement covers the entire selected body, including nested subsections; preserve any content you want to retain. Missing or ambiguous headings cause refusal. Installation and platform limits.
There are no measured token savings for this integration yet. Measure total task input/output (including cached tokens where available), retries, correctness and setup cost against your normal tools. Would a small comparison be useful? I can help prepare it before any implementation PR.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
RTK's contribution guide distinguishes bash-output reduction from billing savings and favors transparent filters. I am proposing an explicit companion recipe for a user-requested Markdown section task, rather than a core filter or a rewrite of arbitrary read commands. Would maintainers or users be interested in comparing RTK's current read/edit workflow with Texio selecting a named section before the output enters context? This targets operation selection upstream of output compression; whether it adds value over RTK's current file operations needs measurement. No request to add a core dependency.
I maintain Texio, an MIT-licensed early-preview CLI. A minimal disposable-file trial with Texio 0.1.3 installed is:
texio headings README.md --json texio section README.md Installation texio replace README.md --section Installation --text 'New installation instructions.' --dry-runThe preview does not write. Replacement covers the entire selected body, including nested subsections; preserve any content you want to retain. Missing or ambiguous headings cause refusal. Installation and platform limits.
There are no measured token savings for this integration yet. Measure total task input/output (including cached tokens where available), retries, correctness and setup cost against your normal tools. Would a small comparison be useful? I can help prepare it before any implementation PR.
All reactions