An Actionfile is a special Markdown-based configuration file that describes a set of actions, scripts, or tasks for use in automation workflows, dotfile management, or application deployment. It is designed for human readability and machine parsing, combining documentation, configuration, and executable code blocks in one file.

An Actionfile is organized into sections with Markdown headers. Each section can contain:

• Introduction/Description:
  General information about the action.
• Config Block: INI-style configuration, usually under a ### config header and fenced in a code block.
• Variables Block: Shell variable assignments, under a ### vars header and fenced in a code block.
• Action Sections: Individual actions, typically under ### {action-context} headers, containing documentation and executable code blocks.

• action.sh
• action.js
• action.py

The following has specific changes that I use for my own dotfiles

• action.zsh
• app.zsh and apps.md
• Application definitions
• gbraad's Actionfiles

myapp.md

This Actionfile defines actions for installing and configuring MyApp.

[install]
  user = "myuser"
  path = "/opt/myapp"

APP_VERSION="1.2.3"
COPFIG_REPO="..."

shared_function() {
   # ...
}

# other overrides

Installs MyApp to the configured path.

echo "Installing MyApp version $APP_VERSION to $INSTALL_PATH"
# installation script goes here

Configures MyApp after installation.

echo "Configuring MyApp for user $INSTALL_USER"
# configuration script goes here

echo "Starts the application for $INSTALL_USER"
# ...

• Config blocks (INI) are only parsed if under ### config and inside a ini code block.
• Vars blocks are only parsed if under ### vars and inside a sh code block.
• Actions are discovered by scanning for ### headers; code blocks under these are the scripts to run.
• Comments and documentation outside code blocks are ignored by automation tools but helpful for users.