Quick Actions#

A Quick Action saves a command you want to find again. It shows you the command before you use it. Ordinary actions insert or copy text; a reviewed multi-step workflow can submit commands only after you explicitly choose Run. This guide is for development builds that expose Quick Actions. Website package downloads are withdrawn, and an older build may not have this feature. Check the development status and the automexia actions --help output for the source revision you use. If the command is absent, keep using your shell or project task runner; there is no setting that turns it on.

Use the in-app editor for a quick saved command. Use one action file when your build exposes the source-build CLI and you need a reviewable definition. A reviewed workflow is a separate, explicitly approved multi-step path. Aliases and built-in packs are optional additions; neither schedules a background job.

Choose the right tool#

Use a Quick Action for a command you repeat but still want to inspect each time. Use a shell alias for a short, mature command you know well. Keep a multi-step or project-specific procedure in a project script or task runner, then save its invocation as a Quick Action if your build supports it. Quick Actions are not scheduled or unattended automation. The current application binding is Ctrl+Shift+O on Linux/Windows and Cmd+Shift+O on macOS; check the palette in your build for the effective shortcut.

Create an action in the interface#

In development revisions with the Quick Actions editor, open the action surface and choose New Quick Action. Give the action a clear name and command, choose the shell that will interpret it, and optionally add a description. Bash, Zsh, Fish, PowerShell, and CMD can interpret the same text differently, so review the actual shell and quoting. Do not put a password, token, or private key in a saved definition. Saving does not execute it.

The action becomes a saved suggestion, not a running job. Open Quick Actions with Ctrl+Shift+O on Linux (or Cmd+Shift+O on a macOS development build), search by name, inspect its command and context, fill supported public parameters where the action requests them, and choose Insert or Copy. Insert leaves the command in your shell for review. You decide whether to press Enter. If your revision has no editor, use the source-build CLI flow below instead.

Use Manage saved actions to edit, duplicate, disable, or delete a saved action. Built-ins are copied before editing. If another window changes the action store while your editor is open, the save fails instead of overwriting the newer version; reopen or duplicate your draft after reviewing the change.

Create an action from a file#

For example, save this as git-status.toml in a development workspace. This is one action per file for the put command, not an entire action library:

schema_version = 1
revision = 0

[[actions]]
id = "shell.git-status"
display_name = "Show Git status"
description = "Review changes in the current repository."
tags = ["git", "read-only"]
scope = "global-user"
shells = ["bash", "zsh", "fish", "powershell", "cmd"]
risk = "read-only"
execution = "insert"
enabled = true

[actions.template]
kind = "typed-argv"
executable_id = "git"
arguments = [{ kind = "literal", value = "status" }]

[actions.working_directory_policy]
kind = "inherit"

[actions.provenance]
kind = "user"

inherit uses the current working directory; git status is useful only when that directory is inside the repository you intend to inspect. The separate argument tokens make the command easier to review and quote correctly than a single pasted shell string.

First preview the change. This validates the file but does not save it:

automexia actions put git-status.toml

Read the preview and its current revision. Only then apply with the revision shown by your own preview, not a copied number:

automexia actions put git-status.toml --apply --expected-revision N

Replace N with that number. If the store changed in between, preview again. To change an existing ID, edit the file, preview it, then explicitly add --replace to the apply command. Do not use --replace to silence an unexpected collision.

Adapt the pattern to your work#

These are examples of commands worth saving, not claims that Automexia installs or configures the named tools. Each tool must already be installed; check its own behavior before pressing Enter.

For Docker, the template portion of a separate action file would be:

[actions.template]
kind = "typed-argv"
executable_id = "docker"
arguments = [{ kind = "literal", value = "ps" }]

Give that file its own unique ID, name, description, scope, shell list, risk, working-directory policy, and provenance as in the Git example. For a target that changes, use the editor's typed placeholder fields where available, then inspect the fully expanded command. Do not copy the uppercase CONTEXT and NAMESPACE words literally into a live Kubernetes command. Prefer a project task over a global Quick Action if the command depends on repository scripts or environment variables. For several ordered steps, use a reviewed workflow only if shell integration can verify each step.

Build a reviewed workflow#

In builds that expose New workflow, give it a name and add steps in the editor. Each step has command text, the shell that will receive it, a timeout, and a completion rule: wait for success, wait for a new integrated shell, or pause after success. You can reorder and remove steps. The source bounds a workflow to 32 steps, but a shorter sequence is easier to review and recover.

For example, a local review workflow could run git status --short, wait for success, then run git diff --stat. Use the same shell and the current working directory for both. Read each full step in the review before choosing Run workflow. A destructive or privileged workflow requires another confirmation. Saving or opening the workflow does not run it.

Automatic submission needs an empty, integrated prompt. After a step, Automexia waits for that command's matching successful status and the next empty prompt. A failed command, timeout, missing status, keyboard/paste input, terminal reset, or unexpected shell change pauses remaining steps. It does not retry the failed command or skip it on Resume. Stock CMD cannot provide the verified generic command identity/status required for this mode; use insert-only actions there.

For an SSH or other interactive shell transition, choose Wait for a new integrated shell, complete authentication yourself, and explicitly resume from Workflow progress after the new shell's scope and empty prompt are visible. A normal unintegrated SSH login does not authorize later steps. Pause prevents future steps, not an already submitted command. Cancel remaining steps leaves the active command to the shell. Switching panes pauses the run; closing or restoring a terminal does not resume it.

Find, update, transfer, or remove actions#

The source-build CLI keeps changes preview-first:

Keep credentials and personal paths out of shared action files. Review an imported file as carefully as an imported shell script. A saved action in one local environment does not silently become an action in WSL, a container, or a remote shell. An action with a missing tool or the wrong scope should be fixed or removed, not forced to run. For build-specific flags, use that revision's automexia actions --help output.

The file example above is a typed-argument action for the source-build CLI. The in-app editor may show shell command text instead; follow the actual form and preview in your build rather than pasting CLI TOML into a GUI field.

Optional aliases for stable actions#

Ordinary aliases in your Bash, Zsh, Fish, or PowerShell setup remain yours. Automexia can also project an eligible saved Quick Action as an opt-in native shell alias. This is for a short, familiar command you intentionally want to type. It does not make Quick Actions run in the background. The shell still executes the alias only after you type and submit it.

Start with automexia aliases list and automexia aliases preview in a source build to inspect what is configured and what would be generated. Use automexia aliases test to check the selected shell's generated form. For example, after reviewing a saved git status action, you might project it under a distinct name such as gstatus for your current shell. Run automexia aliases enable --help and use its preview-first flow; applying needs the exact current revision and generation reported by your own preview. Check for collisions with your existing aliases, functions, and commands before consenting. A mutating action needs explicit acknowledgement, not a read-only label borrowed from a different action.

automexia aliases doctor reports source and generation health. disable, disable-all, and rollback provide explicit reversal paths; reload explains how to load the published alias into a live shell. Removing a projection does not remove the original Quick Action. If native alias support is absent or fails, keep using the reviewed action in Automexia or your own shell alias. Never paste a generated alias file into a profile without reviewing its exact source and ownership.

Try a reviewed built-in pack#

Built-in packs are static suggestions, not tool installers or provider connections. Use automexia packs list, then automexia packs show PACK_ID to inspect one pack and its action templates. automexia packs doctor PACK_ID can evaluate tool/version observations you supply; it does not run a provider CLI to discover them. automexia packs enable PACK_ID ACTION_ID previews one selected action; applying needs the current action-store revision. It creates a reviewable action with native aliases still disabled. For example, choose a read-only status action from a pack only after verifying its target CLI is already installed and the active account/context is the one you intend. Packs do not authorize a remote operation or claim an account is healthy.

Keep action and workspace scopes distinct#

A Quick Action describes a command to review. Declarative workspace metadata describes how related connection entries belong together; it does not run the action or open sessions. If you are preparing several environments, first save and review the workspace description, then inspect each connection and command in its own shell. See Workspaces, tabs, and panes and Connection Hub for the separate boundaries.