Teal / Launcher

I want RETUI automation to stay readable.

The useful kind of automation turns a repeated intention into something you can name. The dangerous kind disappears into the background until you no longer remember why your phone is doing something. RETUI is built around the first kind.

Begin with a line you can still understand

The launcher can execute several normal commands from one input. The default separator is a semicolon, and it can be changed through `multiple_cmd_separator` in Behaviour settings.

module -show timer; timer 25m; notifications -off

There is no hidden workflow format behind that line. RETUI splits it at the configured separator and runs the pieces in order. Each part remains a command you can try on its own.

When the line becomes a habit, give it a name

Aliases are the main RETUI workflow layer because they are local, inspectable, and easy to remove. The alias does not invent a second command language; it gives an ordinary command or chain a word that belongs to you.

For a multi-command workflow, open `alias -file` and add the whole line there. The prompt itself splits semicolons before `alias -add` sees them.

focus=module -show timer; timer 25m; notifications -off

focus

alias -ls

Read the aliases RETUI currently knows.

alias -file

Open `alias.txt` and inspect the source directly.

alias -rm focus

Remove a workflow without leaving an invisible trigger behind.

alias -add -s check /path/script.sh

Keep a Termux script alias in its separate script scope.

Aliases can also accept positional values through the configured alias parameter marker and separator. That is useful when the same shape of command needs different input, but the readable default is still the best place to begin.

read the Aliases post

A shell script should remain a shell script

Once a workflow needs Linux tools, branching, parsing, or a real script file, move that work to Termux. RETUI can dispatch the script or render its output in a module without pretending the launcher has become Bash.

termux -run check
module -add server termux:/data/data/com.termux/files/home/retui/server.sh
module -refresh server

The separation keeps both sides easier to reason about. The script is editable in Termux. The registration and panel stay visible in RETUI.

Webhooks are saved outbound intentions

A webhook stores a name, a URL, and a POST body template. `%1`, `%2`, and later placeholders are filled from the arguments you supply when you trigger it.

webhook -add deploy https://example.com/deploy "{\"env\":\"%1\"}"
webhook deploy prod

If the template looks like JSON, RETUI sends JSON; otherwise it sends plain text. The response status and body come back to the terminal. Use `webhook -ls` to see the saved names and targets, and `webhook -rm <name>` to remove one.

There is also a one-off `post <url> <body>` command. I would use that for an actual one-off request. If an endpoint matters enough to repeat, naming it makes the intent much easier to audit.

Callbacks are narrow on purpose

Termux, Tasker, or another local tool can send information back to RETUI through a package-scoped Android callback. That route is protected by a token and accepts a deliberately small set of actions:

output

Print text in the RETUI terminal.

notify

Print a notification-style title and message in the terminal output.

module_set / module

Update the body of an existing script module and refresh its panel.

Callbacks do not accept arbitrary commands to execute. That limit is more important than convenience. An external process can report state or update a known panel without quietly gaining the entire launcher command surface.

retui-token -status
retui-token -show
retui-token -rotate
retui-token -off

Showing, enabling, or rotating the token copies it to the clipboard for setup. Rotate it when a previous integration should stop working; disable callback auth when you do not need the route at all.

Tasker can work in both directions

RETUI can run an existing named Tasker task, including names with spaces.

tasker Work
tasker -run "Evening Setup"

Tasker can also call the RETUI Action plugin surface to apply a preset, set a theme value, show or refresh a module, update script-module text, or send terminal output. The integration is disabled until you enable it in Settings, grant Tasker's run-task permission, and allow external access inside Tasker.

The Settings Hub shows those pieces separately: integration state, Tasker installation, permission state, and whether task completion statuses should appear. Automation failures are much easier to fix when “not working” is not the only diagnosis.

Shortcuts and clocks are useful, but they are not schedulers

Android app shortcuts can be listed and launched from RETUI:

shortcut -ls Signal
shortcut -use <shortcutId> Signal

Timers, stopwatch, and Pomodoro provide visible time-based state. They can belong inside a workflow, but they are not a general background scheduling engine.

timer 25m
timer -add 5m
stopwatch
pomodoro deep-work

If a workflow truly needs Android conditions, times, profiles, or background triggers, that is the point where Tasker earns its place.

Use the smallest mechanism you can inspect

command chain

A few launcher actions belong together once.

alias

The same understandable sequence has become part of your routine.

Termux script

The work needs a real programming and shell environment.

webhook

A named workflow ends with an explicit outbound POST.

callback

An external tool needs to report narrow state back into RETUI.

Tasker

Android context and background triggers are the actual problem.

Automation should make a phone feel more like yours, not make its behaviour harder to explain. If I cannot point to the alias, script, webhook, token, or Tasker action that caused something, the system has become too clever.