Post transcription transformations

[cjenaro]

Is your feature request related to a problem? Please describe.
no.

Describe the solution you'd like
This already has the capability of adding transformations, but what if we could add BYOK prompting? I imagine asking to translate to a different language or maybe making it more like Slack friendly for example.

Describe alternatives you've considered
I've seen some some other apps that are not open source that allow for enhancements, for example, and they are aware of the app that you're actually entering text into, auto transforming the text to more casual, etc.

[alireza-ahmadi]

i might be claude-pilled but having a hooks system would've allowed for much easier customization. to make it easier for non-technical users, the hooks system can accompany a few pre-defined (official, non-changeable) presets (e.g. apply prompt using openrouter model).

for the first iteration, we can only define the basic hooks system:

• hooks. events (e.g. recording finished, transcription finished, etc.) and error events (e.g. transcription failed)
• internal API for triggering events plus executing hooks (ideally both bash and apple shortcuts. we can defer the apple shortcuts compatibility but design the system with it in mind)
• limits (e.g. timeouts)
• basic config format. a simple, versionable (is that a word?) json
• a toggle in the settings to enable the whole thing

in the second iteration, we can focus on defining presets.

and in the next iterations, we can implement user friendly ui for setting up hooks (or, setting up presets).

i think a hook system i superior because it allows for introducing programmatical customization into the app. in short term, various features (incl. command mode, transformation, etc.) can implemented using a hooks system and in the long term, the most used hooks (combination of events + actions) can be turned into native features of Hex.

however, based on my observations, @kitlangton prefers to keep this whole project minimal and such an extensive system might oppose his philosophy. especially considering the fact that a programmable interface can increase the chance of security issues.

---

for the context:
my friend (claude) and i, implemented a basic and unoptimized version of the system that i described. it works pretty well for a custom build. here is a sample script (uppercase.sh) and its output log:

LOG="/Users/alireza/Dev/Sandbox/Hex/log.txt"
echo "--- $(date '+%Y-%m-%d %H:%M:%S') ---" >> "$LOG"
echo "event: $HEX_EVENT" >> "$LOG"
echo "text:  $HEX_TEXT" >> "$LOG"
echo "app:   $HEX_SOURCE_APP ($HEX_SOURCE_BUNDLE_ID)" >> "$LOG"
echo "audio: $HEX_AUDIO_PATH" >> "$LOG"
echo "" >> "$LOG"
echo "$HEX_TEXT" | tr '[:lower:]' '[:upper:]'

--- 2026-04-04 22:51:14 ---
event: before-paste
text:  Hello.
app:   Google Chrome (com.google.Chrome)
audio: /var/folders/zk/f79r821962q9j8nzvgbmghhh0000gn/T/hex-capture-C8AA8B98-4BCD-462D-8AB6-081C046B5DE1.wav

and based on my explorations the main complexity lies in two things:

• how to make it secure
• how to make it user friendly