roast-ai 0.1.7 → 0.2.1

data/examples/iteration/simple_workflow.yml

@@ -0,0 +1,58 @@
+name: Ruby Method Counter
+tools:
+  - Roast::Tools::ReadFile
+  - Roast::Tools::Grep
+  - Roast::Tools::WriteFile
+  - Roast::Tools::CodingAgent
+
+steps:
+  # Find all Ruby files in the specified directory
+  - find_ruby_files:
+      $(find lib/roast/workflow -type f -name "*.rb")
+
+  # Initialize a report object to store our results
+  - initialize_report:
+      $(echo '{"files_analyzed": 0, "total_methods": 0, "results": []}')
+
+  # Process each file found
+  - each: "{{output['find_ruby_files'].split('\n')}}"
+    as: "current_file"
+    steps:
+      # Read the file content
+      - read_file:
+          prompt: examples/iteration/prompts/analyze_file
+          model: claude-3-haiku-20240307
+          vars:
+            file_path: "{{ current_file }}"
+
+      # Update the report with the analysis result
+      - update_report:
+          prompt: examples/iteration/prompts/update_report
+          model: claude-3-haiku-20240307
+          vars:
+            file_path: "{{ current_file }}"
+            method_count: "{{ output['read_file']['method_count'] }}"
+            current_report: "{{ output['initialize_report'] }}"
+
+  # Generate the summary report after processing all files
+  - report_count:
+      $(echo "{{ output.initialize_report.files_analyzed }}")
+
+  # Repeat to generate the final summary - demonstrates the repeat construct
+  - repeat:
+      steps:
+        - generate_summary:
+            prompt: examples/iteration/prompts/generate_summary
+            model: claude-3-haiku-20240307
+            vars:
+              report_data: "{{ output['initialize_report'] }}"
+      until: "{{true}}"
+      max_iterations: 1
+
+  # Write the report to a file
+  - write_report:
+      prompt: examples/iteration/prompts/write_report
+      model: claude-3-haiku-20240307
+      vars:
+        report_data: "{{ output['initialize_report'] }}"
+        summary: "{{ output['generate_summary']['summary'] }}"

data/examples/iteration/update_fix_count/prompt.md

@@ -0,0 +1,26 @@
+I'll update the count of fixes that have been successfully applied.
+
+Current fix count: 
+```
+{{output.update_fix_count || 0}}
+```
+
+Verification result from the previous step:
+```json
+{{output.verify_fix}}
+```
+
+I'll increment the fix count if the verification was successful or partial, but not if it failed.
+
+```javascript
+let currentCount = parseInt({{output.update_fix_count || 0}});
+let verificationStatus = "{{output.verify_fix.status}}";
+
+if (verificationStatus === "success" || verificationStatus === "partial") {
+  currentCount += 1;
+}
+
+return { fixes_applied: currentCount };
+```
+
+This updated count will be used to determine whether we've met our target for the number of fixes to implement.

data/examples/iteration/verify_fix/prompt.md

@@ -0,0 +1,29 @@
+I'll verify that the fix implemented in the previous step correctly addresses the identified issue.
+
+Here are the details of the issue that was fixed:
+```json
+{{output.select_next_issue}}
+```
+
+And here is the implementation of the fix:
+```json
+{{output.implement_fix}}
+```
+
+Now I'll read the updated file to verify the changes:
+```ruby
+{{read_file(output.select_next_issue.file_path)}}
+```
+
+I'll evaluate the fix based on these criteria:
+1. Does it fully address the identified issue?
+2. Did it introduce any new issues or regressions?
+3. Does it maintain the original functionality?
+4. Does it follow Ruby best practices and style conventions?
+5. Is it minimal and focused (changing only what was necessary)?
+
+Based on this evaluation, I'll provide:
+1. A verification status (success, partial, failure)
+2. Detailed reasoning for the status
+3. Any recommendations for further improvements or adjustments
+4. An overall assessment of the code quality improvement 

data/examples/iteration/workflow.yml

@@ -0,0 +1,42 @@
+name: Code Quality Analyzer
+tools:
+  - Roast::Tools::ReadFile
+  - Roast::Tools::Grep
+  - Roast::Tools::WriteFile
+  - Roast::Tools::UpdateFiles
+  - Roast::Tools::CodingAgent
+  - Roast::Tools::Cmd
+
+steps:
+  # Get all Ruby files from the target directory
+  - get_files_to_analyze:
+      $(find {{resource.target}} -name "*.rb" -not -path "*/vendor/*" | grep -v "test")
+
+  # Analyze each file and generate improvement recommendations
+  - each: "{{output['get_files_to_analyze'].split('\n')}}"
+    as: "current_file"
+    steps:
+      - read_file:
+          $(cat {{current_file}})
+      - analyze_complexity
+      - generate_recommendations
+
+  # After analyzing all files, sort issues by priority
+  - prioritize_issues
+  
+  # Process the highest priority issues first, until we've addressed a sufficient number
+  # or reached our iteration limit
+  - initialize_fixes:
+      $(echo "0")
+  
+  - repeat:
+      steps:
+        - select_next_issue
+        - implement_fix
+        - verify_fix
+        - update_fix_count
+      until: "{{output['update_fix_count']['fixes_applied'] >= 5 || output['select_next_issue']['no_issues_left'] == true}}"
+      max_iterations: 10
+  
+  # Generate a summary report of all changes made
+  - generate_report

data/examples/json_handling/README.md

@@ -0,0 +1,32 @@
+# JSON Handling Example
+
+This example demonstrates how Roast handles JSON responses from LLM steps.
+
+## Key Features
+
+1. **JSON Arrays**: When a step has `json: true` and returns an array, the result is `flatten.first` - the first element after flattening the array. This is useful when the LLM returns an array with a single object.
+
+2. **JSON Objects**: Hash/object responses are maintained as proper Ruby hashes in the workflow output.
+
+3. **Replay Support**: JSON data structures are properly serialized and deserialized when saving/loading workflow state for replay functionality.
+
+## Running the Example
+
+```bash
+bin/roast examples/json_handling/workflow.yml
+```
+
+## How It Works
+
+1. The `fetch_users` step generates a JSON array of user objects
+2. The `fetch_metadata` step generates a JSON object with metadata
+3. The `process_data` step can access the structured data using `{{output.fetch_users}}` and `{{output.fetch_metadata}}`
+4. The structured data is preserved through the workflow, including during replay scenarios
+
+## Implementation Details
+
+When `json: true` is set on a step:
+- Array responses return `flatten.first` - the first element after flattening
+- Object responses are preserved as hashes
+- Non-JSON array responses (when `json: false`) are joined with newlines
+- The data maintains its structure when saved to and loaded from workflow state files

data/examples/json_handling/workflow.yml

@@ -0,0 +1,52 @@
+name: JSON Data Handling Example
+api_provider: openai
+model: gpt-4
+
+tools:
+  - type: write_file
+    allowed_paths:
+      - examples/json_handling/
+
+steps:
+  - name: fetch_users
+    prompt: |
+      Generate a JSON array of 3 user objects. Each user should have:
+      - id (number)
+      - name (string)
+      - email (string)
+      - active (boolean)
+    json: true
+
+  - name: fetch_metadata
+    prompt: |
+      Generate a JSON object with metadata about a dataset:
+      - total_records (number)
+      - last_updated (ISO date string)
+      - categories (array of strings)
+      - filters (object with status and sort fields)
+    json: true
+
+  - name: process_data
+    prompt: |
+      Based on the users data: {{output.fetch_users}}
+      And metadata: {{output.fetch_metadata}}
+      
+      Create a summary report describing:
+      1. How many active users there are
+      2. The categories available
+      3. When the data was last updated
+
+  - name: save_report
+    tool: write_file
+    path: examples/json_handling/report.txt
+    content: |
+      # JSON Data Processing Report
+      
+      ## Users Data
+      {{output.fetch_users}}
+      
+      ## Metadata
+      {{output.fetch_metadata}}
+      
+      ## Summary
+      {{output.process_data}}

data/examples/openrouter_example/workflow.yml

@@ -1,7 +1,7 @@
 name: OpenRouter Example
 api_provider: openrouter
 api_token: $(echo $OPENROUTER_API_KEY)
-model: anthropic/claude-3-haiku-20240307
+model: google/gemini-2.0-flash-001
 
 tools:
   - Roast::Tools::ReadFile
@@ -9,4 +9,4 @@ tools:
 
 steps:
   - analyze_input
-  - generate_response
+  - generate_response

data/examples/smart_coercion_defaults/README.md

@@ -0,0 +1,65 @@
+# Smart Coercion Defaults
+
+This example demonstrates how Roast applies intelligent defaults for boolean coercion based on the type of expression being evaluated.
+
+## Default Coercion Rules
+
+When a step is used in a boolean context (like `if`, `unless`, or `until` conditions) and no explicit `coerce_to` is specified, Roast applies these smart defaults:
+
+1. **Ruby Expressions** (`{{expression}}`) → Regular boolean coercion (`!!value`)
+   - `nil` and `false` are falsy
+   - Everything else is truthy (including 0, empty arrays, etc.)
+
+2. **Bash Commands** (`$(command)`) → Exit code interpretation
+   - Exit code 0 = true (success)
+   - Non-zero exit code = false (failure)
+
+3. **Prompt/Step Names** → LLM boolean interpretation
+   - Analyzes natural language responses for yes/no intent
+   - "Yes", "True", "Affirmative" → true
+   - "No", "False", "Negative" → false
+
+4. **Non-string Values** → Regular boolean coercion
+
+## Examples
+
+### Ruby Expression (Regular Boolean)
+```yaml
+- repeat:
+    until: "{{counter >= 5}}"  # Uses !! coercion
+    steps:
+      - increment: counter
+```
+
+### Bash Command (Exit Code)
+```yaml
+- repeat:
+    until: "$(test -f /tmp/done)"  # True when file exists (exit 0)
+    steps:
+      - wait: 1
+```
+
+### Prompt Response (LLM Boolean)
+```yaml
+- if: "Should we continue?"  # Interprets "Yes, let's continue" as true
+  then:
+    - proceed: "Continuing..."
+```
+
+## Overriding Defaults
+
+You can always override the default coercion by specifying `coerce_to` directly in the step:
+
+```yaml
+- each: "get_items"
+  as: "item"
+  coerce_to: iterable  # Override default to split into array
+  steps:
+    - process: "{{item}}"
+```
+
+## Supported Coercion Types
+
+- `boolean` - Standard Ruby truthiness (!! operator)
+- `llm_boolean` - Natural language yes/no interpretation
+- `iterable` - Convert to array (splits strings on newlines)

data/examples/smart_coercion_defaults/workflow.yml

@@ -0,0 +1,44 @@
+name: Smart Coercion Defaults Demo
+description: Demonstrates how different step types get smart boolean coercion defaults
+
+steps:
+  # Example 1: Ruby expressions default to regular boolean coercion
+  - set_counter: 
+      value: 3
+  
+  - repeat:
+      until: "{{counter >= 5}}"  # Ruby expression defaults to boolean
+      steps:
+        - increment_counter: 
+            value: "{{counter + 1}}"
+        - log: "Counter is now {{counter}}"
+  
+  # Example 2: Bash commands default to exit code interpretation
+  - check_file_exists:
+      repeat:
+        until: "$(ls /tmp/important_file 2>/dev/null)"  # Bash command defaults to exit code
+        max_iterations: 3
+        steps:
+          - create_file: "$(mkdir -p /tmp && touch /tmp/important_file)"
+          - log: "Waiting for file to exist..."
+  
+  # Example 3: Prompt/step names default to LLM boolean interpretation
+  - ask_user_ready:
+      prompt: "Are you ready to continue? Please respond yes or no."
+  
+  - conditional:
+      if: "ask_user_ready"  # Step name defaults to llm_boolean
+      then:
+        - proceed: "Great! Let's continue..."
+      else:
+        - wait: "Okay, take your time."
+  
+  # Example 4: Explicit coerce_to overrides smart defaults
+  - get_items:
+      prompt: "List three fruits, one per line"
+  
+  - each: "get_items"
+    as: "fruit"
+    coerce_to: iterable  # Override default llm_boolean to iterable
+    steps:
+      - process_fruit: "Processing {{fruit}}"

data/examples/step_configuration/README.md

@@ -0,0 +1,87 @@
+# Step Configuration Example
+
+This example demonstrates how to configure various step types in Roast workflows, including:
+- Inline prompts
+- Iterator steps (each/repeat)
+- Regular steps
+
+## Configuration Options
+
+All step types support the following configuration options:
+
+- `model`: The AI model to use (e.g., "gpt-4o", "claude-3-opus")
+- `loop`: Whether to enable auto-looping (true/false)
+- `print_response`: Whether to print the response to stdout (true/false)
+- `json`: Whether to expect a JSON response (true/false)
+- `params`: Additional parameters to pass to the model (e.g., temperature, max_tokens)
+- `coerce_to`: How to convert the step result (options: "boolean", "llm_boolean", "iterable")
+
+## Configuration Precedence
+
+1. **Step-specific configuration** takes highest precedence
+2. **Global configuration** (defined at the workflow level) applies to all steps without specific configuration
+3. **Default values** are used when no configuration is provided
+
+## Inline Prompt Configuration
+
+Inline prompts can be configured in two ways:
+
+### As a top-level key:
+```yaml
+analyze the code:
+  model: gpt-4o
+  loop: false
+  print_response: true
+```
+
+### Inline in the steps array:
+```yaml
+steps:
+  - suggest improvements:
+      model: claude-3-opus
+      params:
+        temperature: 0.9
+```
+
+## Iterator Configuration
+
+Both `each` and `repeat` steps support configuration:
+
+```yaml
+each:
+  each: "{{files}}"
+  as: file
+  model: gpt-3.5-turbo
+  loop: false
+  steps:
+    - process {{file}}
+
+repeat:
+  repeat: true
+  until: "{{done}}"
+  model: gpt-4o
+  print_response: true
+  steps:
+    - check status
+```
+
+## Coercion Types
+
+The `coerce_to` option allows you to convert step results to specific types:
+
+- **`boolean`**: Converts any value to true/false (nil, false, empty string → false; everything else → true)
+- **`llm_boolean`**: Interprets natural language responses as boolean (e.g., "Yes", "Definitely!" → true; "No", "Not yet" → false)
+- **`iterable`**: Ensures the result can be iterated over (splits strings by newlines if needed)
+
+This is particularly useful when:
+- Using steps in conditional contexts (if/unless)
+- Using steps as conditions in repeat loops
+- Processing step results in each loops
+
+## Running the Example
+
+```bash
+bin/roast examples/step_configuration/workflow.yml
+```
+
+Note: This example is for demonstration purposes and shows the configuration syntax. You'll need to adapt it to your specific use case with appropriate prompts and logic.

data/examples/step_configuration/workflow.yml

@@ -0,0 +1,60 @@
+name: Step Configuration Example
+description: Demonstrates how to configure various step types including inline prompts, iterators, and regular steps
+
+# Global configuration that applies to all steps
+model: openai/gpt-4o-mini
+loop: true
+
+# Configuration for specific steps
+summarize the code:
+  model: claude-3-opus  # Override global model
+  loop: false          # Disable auto-loop for this step
+  print_response: true # Print the response
+  json: false          # Don't expect JSON response
+  params:
+    temperature: 0.7   # Custom temperature
+
+analyze complexity:
+  model: gpt-4o
+  json: true           # Expect JSON response
+  params:
+    temperature: 0.2   # Lower temperature for more consistent analysis
+
+# Iterator step configuration
+each:
+  each: "{{files}}"
+  as: file
+  model: gpt-3.5-turbo # Use a faster model for iteration
+  loop: false          # Don't loop on each iteration
+  steps:
+    - process {{file}}
+
+repeat:
+  repeat: true
+  until: "are all tests passing"  # This will be evaluated as a step
+  max_iterations: 5
+  model: gpt-4o
+  print_response: true
+  coerce_to: llm_boolean  # Interpret natural language response as boolean
+  steps:
+    - run tests
+    - fix failing tests
+
+# Step used in boolean context
+are all tests passing:
+  model: gpt-4o
+  coerce_to: llm_boolean  # Convert "Yes, all tests are passing!" to true
+  params:
+    temperature: 0.2
+
+# Steps can mix configured and unconfigured inline prompts
+steps:
+  - list all source files           # Uses global configuration
+  - summarize the code              # Uses step-specific configuration
+  - analyze complexity              # Uses step-specific configuration
+  - suggest improvements:           # Step-specific configuration inline
+      model: claude-3-opus
+      params:
+        temperature: 0.9
+  - each                           # Iterator with configuration
+  - repeat                         # Iterator with configuration

data/examples/workflow_generator/README.md

@@ -0,0 +1,27 @@
+# Workflow Generator
+
+This workflow generates new Roast workflows based on user descriptions. It's the engine behind the "New from prompt" option in `roast init`.
+
+## How It Works
+
+The workflow generator takes a user description and workflow name, then:
+
+1. **Analyzes the request** - Understands what type of workflow is needed, what steps are required, and what tools should be used
+2. **Generates structure** - Creates a complete workflow configuration including YAML and step prompts
+3. **Creates files** - Writes all the necessary files and directories to disk
+
+## Usage
+
+This workflow is typically invoked automatically by the `roast init` command, but can also be run directly:
+
+```bash
+# Run the generator workflow
+roast execute examples/workflow_generator/workflow.yml
+```
+
+## Generated Output
+
+The workflow creates a new directory with:
+- `workflow.yml` - Main workflow configuration
+- `step_name/prompt.md` - Individual step prompts
+- `README.md` - Documentation for the generated workflow

data/examples/workflow_generator/analyze_user_request/prompt.md

@@ -0,0 +1,34 @@
+You are an assistant that analyzes user requests to understand what kind of workflow they want to create.
+
+Based on the user input from the previous step:
+<%= workflow.output["get_user_input"] %>
+
+Roast information from previous step:
+<%= workflow.output["info_from_roast"] %>
+
+First, explore existing workflow examples in the examples directory to understand common patterns and structures. Look for ones that may be related to the user's intention.
+
+Then analyze the user's request and determine:
+
+1. **Required Steps**: Break down the workflow into logical steps. Each step should be a discrete task that can be accomplished with an AI prompt.
+
+2. **Tools Needed**: What Roast tools will be needed? Base this on the actual tools you read from info provided above. 
+
+3. **Target Strategy**: Will this workflow:
+   - Process specific files (needs target configuration)
+   - Be targetless (works without specific input files)
+   - Use shell commands to find targets dynamically
+
+4. **Model Requirements**: Should this use a specific model, or is the default (gpt-4o-mini) sufficient?
+
+Respond with a structured analysis in this format:
+
+```
+STEPS: [list of 3-5 logical steps]
+TOOLS: [list of required tools]
+TARGET_STRATEGY: [targetless/files/dynamic]
+MODEL: [model recommendation]
+COMPLEXITY: [simple/moderate/complex]
+```
+
+Be specific and actionable in your analysis.

data/examples/workflow_generator/create_workflow_files/prompt.md

@@ -0,0 +1,32 @@
+You are an assistant that creates the actual workflow files in the filesystem.
+
+Based on the user input:
+<%= workflow.output["get_user_input"] %>
+
+And the generated workflow structure from the previous step:
+<%= workflow.output["analyze_user_request"] %>
+
+And info from roast:
+<%= workflow.output["info_from_roast"] %>
+
+Your task is to create all the necessary files and directories for the workflow.
+
+Extract the workflow name from the user input JSON and create the workflow in the current directory under that folder name.
+
+Steps to complete:
+
+1. **Create the main directory**: Use Cmd to create the "{{ workflow_name }}" directory
+2. **Create step directories**: Create subdirectories for each workflow step  
+3. **Create workflow.yml**: Write the main workflow configuration file
+4. **Create step prompt files**: Write each step's prompt.md file
+5. **Create README.md**: Generate a helpful README explaining the workflow
+
+When writing files, extract the content from the structured response and write each file separately.
+
+Important notes:
+- Make sure all directories exist before writing files to them
+- Follow the exact structure specified in the previous step
+- Include helpful comments in the workflow.yml file
+- Make the README.md informative and include usage instructions
+
+At the end, confirm that all files have been created by listing the directory structure.

data/examples/workflow_generator/get_user_input/prompt.md

@@ -0,0 +1,14 @@
+You need to collect user input for generating a new workflow.
+
+Step 1: Ask for the workflow description using ask_user tool with prompt: "What should your workflow do?"
+
+Step 2: Ask for the workflow name using ask_user tool with prompt: "Enter workflow directory name:"
+
+Step 3: Return the result in JSON format:
+
+<json>
+{
+  "user_description": "what the user wants the workflow to do", 
+  "workflow_name": "directory_name_provided_by_user"
+}
+</json>

data/examples/workflow_generator/info_from_roast.rb

@@ -0,0 +1,22 @@
+# frozen_string_literal: true
+
+class InfoFromRoast < Roast::Workflow::BaseStep
+  def call
+    examples_path = File.join(Roast::ROOT, "examples")
+    tools_path = File.join(Roast::ROOT, "lib", "roast", "tools")
+
+    # Get list of available tools
+    available_tools = Dir.entries(tools_path)
+      .select { |file| file.end_with?(".rb") }
+      .map { |file| file.gsub(".rb", "") }
+      .reject { |tool| tool == "." || tool == ".." }
+      .sort
+
+    {
+      examples_directory: examples_path,
+      tools_directory: tools_path,
+      available_tools: available_tools,
+      message: "Examples directory and available tools provided for analysis step",
+    }
+  end
+end