Feature Request: Script-Based Workflow Support for roocode

[sanathusk]

1. Current Limitation

• Markdown-only workflows: At present, roocode supports crafting custom workflows exclusively via Markdown files.
• Reliability issues: Markdown workflows often encounter inconsistent or unpredictable results due to the non-deterministic behavior of language models (LLMs).

2. Proposed Enhancement

• Support for script-based workflows: Enable workflows defined in executable formats like Bash, Node.js, or Python, allowing explicit, deterministic execution of sequential steps.
• User interaction primitives: Expose features to trigger user prompts (e.g., <ask_followup_question>), similar to Markdown workflows.
• JavaScript SDK: Provide a JavaScript SDK that allows script-based workflows to interact with core roocode workflow functions directly.

3. Inspiration from Kestra (YAML-Based Workflow Orchestration)

Kestra offers a highly structured, declarative approach using YAML for defining workflows. Key features worthy of inspiration include:

• Flow structure: YAML workflows define a flow with metadata (id, namespace, description, labels, inputs, variables, tasks, pluginDefaults).
• Tasks and orchestration: Supports modular task definitions (e.g., flowable for control logic, runnable for compute tasks), with rich constructs like error handling, retries, concurrency limits, SLA checks, and conditional branches.
• Strong input typing and validation: Inputs can be defined with strict data types (STRING, INT, FLOAT, SELECT, BOOLEAN, DATETIME, etc.) and validations, improving reliability.
• Variables and templating: Support for variables that can be reused across tasks using templating for dynamic behavior.
• Triggers and scheduling: Workflow execution can be triggered by schedules, webhooks, flow completions, and more.

Drawing from Kestra’s model, roocode could adopt these structural and functional benefits to enrich its custom workflow capabilities.
Reference: Kestra Workflow Components Documentation

4. Use Case

Scenario: A developer wants to automate a multi-phase deployment: build → test → deploy, while intermittently prompting the user for input.

Current Markdown-based approach:

• Relies on the LLM interpreting high-level instructions (e.g., “build project”, “run tests”).
• Susceptible to misinterpretation—like skipping steps or misordering tasks—due to LLM unpredictability.

With Script-based workflows (proposed):

1. Build step: A Bash or Node.js script executes the build reliably.
2. Prompt user input: Script triggers a user prompt—for instance, “Select deployment environment: staging or production.”
3. Conditional logic: Based on user input, script decides next actions, e.g., run staging tests vs production deployment.
4. Deploy step: Executes deployment reliably, with explicit scripting rather than inferred intent.

Benefits:

• Determinism: Each step runs predictably, reducing errors from ambiguous instructions.
• Interactivity: Inline prompts make workflows adaptive and user-friendly.
• Modularity & reuse: Scripts can leverage SDK methods; tasks can be organized similarly to Kestra's flow components (inputs, variables, error handling).
• Better maintenance: Scripts are easier to version-control, test, and debug compared to prose-based workflows.