Configurable UI Shortcuts & Automated Triggers for Processes/Workflows

[jezweb]

1. Problem Statement:

• Executing predefined complex actions, such as Standard Operating Procedures (SOPs) or Workflows (e.g., run /path/to/sop for file1 file2), currently requires manually typing the full command and parameters. This can be repetitive, error-prone, and lacks discoverability for available standardized actions.
• Furthermore, there is no built-in, standardized mechanism to automate the execution of these processes based on workspace events, state, or time, requiring such logic to be potentially duplicated across different modes or rules.

2. Proposed Solution:

Part A: Configurable UI Shortcuts

• Concept: Introduce a system for defining user-configurable shortcuts accessible directly from the main chat interface.
• Mechanism:
  • Define shortcuts in a dedicated workspace configuration file (e.g., .ruru/shortcuts.toml or similar).
  • Each shortcut definition would include:
    • A user-friendly name (e.g., "Commit Changes", "Archive Rule").
    • The command template to execute (e.g., run /path/to/sop, git commit -m "{message}", mv {source} {destination}).
    • (Optional) Definitions for parameters that the user should be prompted for upon activation (e.g., {files_to_commit}, {commit_message}, {source_path}).
• User Interface:
  • Display these configured shortcuts in an accessible UI element, such as a dropdown menu or button bar located near the chat input area (as indicated in the user's screenshot).
  • Activating a shortcut would:
    • Execute the command directly if no parameters are needed.
    • Prompt the user for any required parameters before executing the command template with the provided values.

Part B: Standardized Automated Triggers

• Concept: Implement a dedicated system for defining rules that automatically trigger specific actions (like running a shortcut, an SOP, or a direct command) based on predefined conditions.
• Mechanism:
  • Define triggers in a separate configuration file (e.g., .ruru/triggers.toml).
  • Each trigger rule would specify:
    • Condition(s): Events or states that activate the trigger. Examples:
      • Time-based: Cron schedule (e.g., 0 0 * * * for daily at midnight).
      • Event-based: on_commit, on_file_change:*.py, on_workspace_open.
      • State-based: context_usage > 80%, uncommitted_files > 5, terminal_output_matches:"Error:".
    • Action: The command, shortcut name, or process path to execute when the condition is met.
• Standardization: This trigger system should be a core feature, distinct from individual mode or workspace rules, providing a consistent way to manage workspace automation.

3. Benefits:

• Efficiency: Reduces manual typing for frequent or complex operations.
• Consistency & Accuracy: Ensures standardized processes (SOPs) are used correctly by leveraging predefined templates.
• Discoverability: Makes common workspace actions more visible and accessible via the UI.
• Automation: Enables powerful, event-driven automation of routine tasks (e.g., auto-commits, context summarization, cleanup) based on clear, configurable rules.
• Decoupling: Separates automation logic from core mode/rule responsibilities.

4. Example Use Cases:

• UI Shortcut: A "Commit Rule" shortcut prompts for file paths and a commit message, then executes the Git commit SOP.
• Automated Trigger: A trigger automatically runs a "Session Summary" SOP when the context window usage exceeds 85%. Another trigger runs linting checks whenever a Python file is saved.

This breakdown clarifies the two main components (manual UI shortcuts and automated triggers) and provides a more structured explanation for a feature request.

[lambda125]

The automated trigger is super interesting / useful, when doing sub-agents / sub-tasks in different modes, because we can automated linting/formatting/compiling/type-checking/style-enforcement/unit-tests etc at various events (like file changed/created/deleted or a sub-task is completed - without prompting the agent/AI and determinisically run the same checks - and feed that back to the AI (saving both time and adding determinism).

It also lets devs choose the exact commands to run, since Roo would raise the event, the dev would define the commands to run (we could have standardised lint/type-check/compile/format/test etc commands that are customised to give just the required level of detail to the AI without bloating the context and have very fine-grained control - even have custom shell scripts that can do all sorts of things.

Pretty much like Claude-Code's hooks.

Is there any interest in doing this - happy to contribute.