roast-ai 0.4.6 → 0.4.8

data/examples/cmd/explore_project/prompt.md

@@ -1,67 +0,0 @@
-# Exploring Your Project Structure
-
-You need to analyze the project structure and provide a comprehensive overview. Gather information about the project layout, documentation, and configuration.
-
-**IMPORTANT COMMAND SYNTAX:**
-- The `find` command requires a path: `find . -name "*.md"` (not `find -name "*.md"`)
-- Use `head` to limit output: `find . -name "*.md" | head -10`
-- Check files efficiently - don't repeat commands
-
-Explore the project by:
-
-1. Identifying your current location: use `pwd`
-2. Listing all files and directories: use `ls -la`
-3. Finding documentation files: use `find . -name "*.md" -type f | head -10`
-4. Examining the README: use `cat README.md | head -20` (if it exists)
-5. Locating configuration files: use `find . -name "*.yml" -o -name "*.yaml" | grep -E "(config|workflow)" | head -10`
-
-**EFFICIENCY RULES:**
-- Run each command ONLY ONCE
-- If a file doesn't exist, note it and move on
-- DO NOT retry failed commands
-
-Based on your exploration, analyze:
-- Project root location and overall structure
-- Key directories and their likely purposes
-- Available documentation
-- Configuration files present
-- General project organization
-
-RESPONSE FORMAT
-Provide your analysis in JSON format:
-
-<json>
-{
-  "project_analysis": {
-    "current_directory": "/path/to/project",
-    "total_items": {
-      "files": 0,
-      "directories": 0,
-      "hidden_items": 0
-    },
-    "documentation": {
-      "readme_found": true,
-      "readme_summary": "Brief summary of README contents",
-      "other_docs": ["list of other .md files found"]
-    },
-    "configuration": {
-      "config_files": ["list of .yml/.yaml configuration files"],
-      "workflow_files": ["list of workflow-related files"]
-    },
-    "project_structure": {
-      "key_directories": [
-        {
-          "name": "src",
-          "purpose": "Source code directory"
-        },
-        {
-          "name": "test",
-          "purpose": "Test files directory"
-        }
-      ],
-      "project_type": "Identified project type based on files present"
-    }
-  },
-  "exploration_complete": true
-}
-</json>

data/examples/cmd/explorer_workflow.yml

@@ -1,21 +0,0 @@
-name: Project Explorer
-model: default
-
-# Navigate and explore your project using command functions
-
-tools:
-  - Roast::Tools::Cmd:
-      allowed_commands:
-        - pwd
-        - ls
-        - find
-        - name: cat
-          description: "cat command - display file contents, concatenate files, works with pipes"
-        - name: git
-          description: "git CLI - version control system with subcommands like status, log, branch"
-        - name: grep
-          description: "grep command - search text patterns with options like -E, -r, -i"
-
-steps:
-  - explore_project
-  - check_repository

data/examples/cmd/smart_tool_selection/prompt.md

@@ -1,99 +0,0 @@
-# Intelligent Tool Selection Examples
-
-You are demonstrating intelligent tool selection by completing various development tasks. Select and use the most appropriate tools based on what each task requires.
-
-**CRITICAL GUIDELINES:**
-- When working with JSON data, you MUST use jq to parse it - never return raw JSON
-- Be efficient - if a command fails, do NOT repeat it
-- Combine tools with pipes when needed (e.g., `curl -s ... | jq ...`)
-- Check for files ONLY ONCE - if they don't exist, note it and move on
-
-Complete the following development tasks:
-
-## Task 1: API Health Check
-Check if the GitHub API is accessible and responding properly.
-- Target: https://api.github.com
-- Goal: Verify the API returns a successful response (check HTTP status)
-
-## Task 2: Parse JSON Response
-Fetch GitHub's public information and extract specific data fields.
-- Target: https://api.github.com/users/github
-- Extract: The name and company fields from the JSON response
-- **REQUIRED**: Use curl to fetch and jq to parse in a single command: `curl -s <url> | jq '<filter>'`
-
-## Task 3: Check Container Environment
-Determine if Docker is available and check for running containers.
-- Try `docker ps` ONCE
-- If Docker daemon is not running, note this and move on - do NOT retry
-
-## Task 4: Check for Node.js Project
-Investigate if this is a Node.js project and examine its dependencies.
-- Check for package.json ONCE with `ls package.json`
-- If not found, note this and move on - do NOT retry
-
-## Task 5: Check Build System
-Determine if a build system is configured and what targets are available.
-- Check for Makefile ONCE with `ls Makefile`
-- If not found, note this and move on - do NOT retry
-
-**EFFICIENCY REMINDER**: Each file check or failed command should be attempted ONLY ONCE.
-
-RESPONSE FORMAT
-Report your findings in JSON format:
-
-<json>
-{
-  "tool_selection_demo": {
-    "task_1_api_check": {
-      "tool_selected": "curl",
-      "command_used": "curl -I https://api.github.com",
-      "rationale": "Selected HTTP request tool for API check",
-      "result": {
-        "api_accessible": true,
-        "status_code": 200
-      }
-    },
-    "task_2_json_parsing": {
-      "tools_selected": ["curl", "jq"],
-      "command_used": "curl -s https://api.github.com/users/github | jq '.name, .company'",
-      "rationale": "Combined tools for fetching and parsing JSON",
-      "result": {
-        "data_extracted": true,
-        "fields": {
-          "name": "GitHub",
-          "company": "@github"
-        }
-      }
-    },
-    "task_3_containers": {
-      "tool_selected": "docker",
-      "command_used": "docker ps",
-      "rationale": "Selected container platform tool",
-      "result": {
-        "docker_available": false,
-        "error": "Docker daemon not running",
-        "containers_running": 0
-      }
-    },
-    "task_4_nodejs": {
-      "tool_selected": "ls",
-      "command_used": "ls package.json",
-      "rationale": "Checked for package.json existence",
-      "result": {
-        "is_node_project": false,
-        "package_json_found": false
-      }
-    },
-    "task_5_build": {
-      "tool_selected": "ls",
-      "command_used": "ls Makefile",
-      "rationale": "Checked for Makefile existence",
-      "result": {
-        "makefile_found": false,
-        "targets": []
-      }
-    }
-  },
-  "summary": "Successfully demonstrated intelligent tool selection based on task requirements"
-}
-</json>

data/examples/coding_agent_with_model.yml

@@ -1,20 +0,0 @@
-name: CodingAgent with Model Configuration
-description: |
-  Example workflow demonstrating how to configure the CodingAgent tool
-  with specific model options like opus
-
-tools:
-  - Roast::Tools::CodingAgent:
-      model: opus
-      # You can also add other claude options here:
-      # temperature: 0.7
-      # max_tokens: 1000
-
-steps:
-  - analyze_code: |
-      Analyze the Ruby code in lib/roast/tools/coding_agent.rb
-      and explain how the CodingAgent tool works.
-      
-  - implement_feature: |
-      Create a simple Ruby script that demonstrates using command-line
-      options similar to how CodingAgent builds its commands.

data/examples/coding_agent_with_retries.yml

@@ -1,30 +0,0 @@
-name: CodingAgent with Retries Configuration
-description: |
-  Example workflow demonstrating how to configure the CodingAgent tool
-  with automatic retries on failure. The retries option will automatically
-  retry the coding agent if it encounters an error during execution.
-  Note: this is not the same as running the step
-
-tools:
-  - Roast::Tools::CodingAgent:
-      retries: 2  # Automatically retry up to 2 times on failure
-
-steps:
-  # This step invokes the coding agent directly using the specified number of retries
-  - ^implement_a_feature: |
-      Create a Ruby script that demonstrates robust error handling.
-      The script should:
-      1. Attempt to read a file that might not exist
-      2. Handle any errors gracefully
-      3. Log the results
-
-
-  # This step invokes the general workflow LLM which can in turn invoke the coding agent.
-  # When the general LLM invokes the coding agent, it will execute with the specified number of retries.
-  - add_tests: |
-      Add test for the feature you just implemented.
-      Run the tests and iterate until they all pass.
-      Use the CodingAgent tool to write the tests.
-
-add_tests:
-  retries: 4

data/examples/conditional/README.md

@@ -1,161 +0,0 @@
-# Conditional Execution in Roast Workflows
-
-This example demonstrates how to use conditional execution (`if` and `unless`) in Roast workflows.
-
-## Overview
-
-Conditional execution allows workflows to execute different steps based on runtime conditions. This feature supports:
-
-- `if` conditions - execute steps when a condition is true
-- `unless` conditions - execute steps when a condition is false  
-- `then` branches - steps to execute when the condition matches
-- `else` branches - steps to execute when the condition doesn't match (optional, only for `if`)
-
-## Syntax
-
-### If Statement
-
-```yaml
-- if: "{{expression}}"
-  then:
-    - step1
-    - step2
-  else:
-    - step3
-    - step4
-```
-
-### Unless Statement
-
-```yaml
-- unless: "{{expression}}"
-  then:
-    - step1
-    - step2
-```
-
-## Condition Types
-
-Conditions can be:
-
-1. **Ruby Expressions** - Wrapped in `{{...}}`
-   ```yaml
-   - if: "{{output.previous_step.success == true}}"
-   ```
-
-2. **Bash Commands** - Wrapped in `$(...)`
-   ```yaml
-   - if: "$(test -f /path/to/file && echo true || echo false)"
-   ```
-
-3. **Step References** - Reference to previous step output
-   ```yaml
-   - if: "check_condition"  # References a previous step
-   ```
-
-4. **File Checks**
-   ```yaml
-   - if: "{{File.exist?('/tmp/myfile.txt')}}"
-   ```
-
-## Examples
-
-### Basic Example
-
-```yaml
-name: Conditional Example
-tools:
-  - Roast::Tools::Cmd
-
-steps:
-  - check_status: "echo 'success'"
-  
-  - if: "{{output.check_status.strip == 'success'}}"
-    then:
-      - success_action: "echo 'Operation succeeded!'"
-    else:
-      - failure_action: "echo 'Operation failed!'"
-```
-
-### Unless Example
-
-```yaml
-name: Unless Example
-tools: []
-
-steps:
-  - check_file: "test -f /tmp/important.txt && echo exists || echo missing"
-  
-  - unless: "{{output.check_file.strip == 'exists'}}"
-    then:
-      - create_file: "touch /tmp/important.txt"
-      - notify: "echo 'Created missing file'"
-```
-
-### Nested Conditionals
-
-```yaml
-name: Nested Conditionals
-tools: []
-
-steps:
-  - outer_check: "echo 'true'"
-  - inner_check: "echo 'false'"
-  
-  - if: "{{output.outer_check.strip == 'true'}}"
-    then:
-      - if: "{{output.inner_check.strip == 'true'}}"
-        then:
-          - both_true: "echo 'Both conditions are true'"
-        else:
-          - only_outer: "echo 'Only outer condition is true'"
-    else:
-      - outer_false: "echo 'Outer condition is false'"
-```
-
-### Platform-Specific Actions
-
-```yaml
-name: Platform Detection
-tools:
-  - Roast::Tools::Cmd
-
-steps:
-  - detect_os: "uname -s"
-  
-  - if: "{{output.detect_os.strip == 'Darwin'}}"
-    then:
-      - mac_setup: "brew --version || echo 'Homebrew not installed'"
-    else:
-      - if: "{{output.detect_os.strip == 'Linux'}}"
-        then:
-          - linux_setup: "apt-get --version || yum --version"
-        else:
-          - unknown_os: "echo 'Unknown operating system'"
-```
-
-## Best Practices
-
-1. **Use Clear Conditions**: Make your conditions explicit and easy to understand
-2. **Handle Edge Cases**: Always consider what happens when conditions fail
-3. **Test Both Branches**: Ensure both `then` and `else` branches work correctly
-4. **Avoid Deep Nesting**: Keep conditional logic simple and readable
-5. **Use Unless Sparingly**: `unless` can be less intuitive than `if` with negation
-
-## Debugging
-
-To debug conditional execution:
-
-1. Check the workflow output to see which branch was executed
-2. Look for keys like `if_condition_name` or `unless_condition_name` in the output
-3. These keys contain information about the condition evaluation and branch taken
-
-## Running the Example
-
-```bash
-# Run the simple conditional example
-roast execute examples/conditional/simple_workflow.yml
-
-# Run the full conditional example (requires API configuration)
-roast execute examples/conditional/workflow.yml
-```

data/examples/conditional/check_condition/prompt.md

@@ -1 +0,0 @@
-Check if the OS is macOS or Linux and return true if it's macOS, false otherwise.

data/examples/conditional/simple_workflow.yml

@@ -1,15 +0,0 @@
-name: Simple Conditional Test
-tools: []
-
-steps:
-  - set_value: "$(echo 'true')"
-  
-  - if: "{{output.set_value.strip == 'true'}}"
-    then:
-      - success: "$(echo 'If condition worked!')"
-    else:
-      - failure: "$(echo 'If condition failed!')"
-  
-  - unless: "{{output.set_value.strip == 'false'}}"
-    then:
-      - unless_success: "$(echo 'Unless condition worked!')"

data/examples/conditional/workflow.yml

@@ -1,23 +0,0 @@
-name: Conditional Execution Example
-tools:
-  - Roast::Tools::Cmd
-
-steps:
-  - check_os: "$(uname -s)"
-  
-  - if: "{{output.check_os.strip == 'Darwin'}}"
-    then:
-      - mac_message: "$(echo 'Running on macOS!')"
-      - mac_info: "$(sw_vers)"
-    else:
-      - linux_message: "$(echo 'Running on Linux!')"
-      - linux_info: "$(lsb_release -a)"
-  
-  - check_file: "$(test -f /tmp/roast_test.txt && echo exists || echo missing)"
-  
-  - unless: "{{output.check_file.strip == 'exists'}}"
-    then:
-      - create_file: "$(touch /tmp/roast_test.txt && echo 'File created')"
-  
-  - verify_file: "$(ls -la /tmp/roast_test.txt)"
-  - cleanup: "$(rm -f /tmp/roast_test.txt)"

data/examples/context_management_demo/README.md

@@ -1,43 +0,0 @@
-# Context Management Demo
-
-This example demonstrates Roast's automatic context management feature, which helps prevent workflow failures when conversation history exceeds the LLM's context window.
-
-## Features Demonstrated
-
-1. **Automatic Token Tracking**: Monitors token usage throughout workflow execution
-2. **Configurable Thresholds**: Set when to trigger warnings or compaction
-3. **Context Preservation**: Specify critical steps to retain during compaction
-
-## Configuration
-
-```yaml
-context_management:
-  enabled: true          # Enable context management
-  strategy: auto         # Compaction strategy (auto, summarize, prune, none)
-  threshold: 0.8         # Trigger at 80% of context window
-  max_tokens: 10000      # Override default limit (for demo purposes)
-  retain_steps:          # Steps to always keep in full
-    - analyze_requirements
-    - generate_summary
-```
-
-## Running the Demo
-
-```bash
-roast execute context_management_demo
-```
-
-The workflow intentionally generates verbose responses to demonstrate how context management handles large amounts of text without failing.
-
-## What to Observe
-
-1. **Token Usage Warnings**: Watch for warnings as the context approaches limits
-2. **Automatic Handling**: The workflow continues even with large outputs
-3. **Preserved Context**: Critical steps remain accessible throughout execution
-
-## Customization
-
-Try modifying the configuration:
-- Lower `max_tokens` to trigger compaction sooner
-- Change `strategy` to test different compaction approaches
-- Add more steps to `retain_steps` to preserve additional context

data/examples/context_management_demo/workflow.yml

@@ -1,42 +0,0 @@
-name: Context Management Demo
-tools:
-  - Roast::Tools::ReadFile
-  - Roast::Tools::WriteFile
-
-# Context management configuration
-context_management:
-  enabled: true
-  strategy: auto
-  threshold: 0.8  # Trigger compaction at 80% of context window
-  max_tokens: 10000  # Demo with smaller limit for testing
-  retain_steps:
-    - analyze_requirements
-    - generate_summary
-
-steps:
-  - analyze_requirements: |
-      Analyze this text and list the key requirements:
-      
-      We need a system that can:
-      1. Process customer orders
-      2. Track inventory levels
-      3. Generate reports
-      4. Handle refunds
-      5. Integrate with payment systems
-      
-  - expand_details: |
-      For each requirement from the previous step, provide detailed implementation notes,
-      technical considerations, and potential challenges. Be very thorough and verbose
-      to help test the context management system.
-      
-  - generate_more_context: |
-      Now describe the database schema needed for this system. Include all tables,
-      relationships, indexes, and data types. Be extremely detailed.
-      
-  - add_api_design: |
-      Design a complete REST API for this system. Include all endpoints, request/response
-      formats, authentication, and error handling. Provide examples for each endpoint.
-      
-  - generate_summary: |
-      Create a concise executive summary of the system design. Focus on the key decisions
-      and trade-offs made during the design process.

data/examples/direct_coerce_syntax/README.md

@@ -1,32 +0,0 @@
-# Direct Coerce Syntax
-
-This example demonstrates the simplified syntax for specifying `coerce_to` and other configuration options directly on iteration steps.
-
-## Direct Syntax
-
-Configuration options are specified directly on the step:
-
-```yaml
-- repeat:
-    until: "condition"
-    coerce_to: boolean
-    print_response: true
-    model: "claude-3-haiku"
-    steps: [...]
-```
-
-## Benefits
-
-1. **Cleaner YAML** - No unnecessary nesting
-2. **More intuitive** - Configuration options are at the same level as other step properties
-3. **Consistent** - Matches how other step properties are specified
-
-## Supported Options
-
-All step configuration options can be specified directly:
-- `coerce_to` - Type coercion (boolean, llm_boolean, iterable)
-- `print_response` - Whether to print LLM responses
-- `loop` - Auto-loop behavior
-- `json` - JSON response mode
-- `params` - Additional parameters
-- `model` - Model override

data/examples/direct_coerce_syntax/workflow.yml

@@ -1,36 +0,0 @@
-name: Direct Coerce Syntax Demo
-description: Demonstrates the simplified coerce_to syntax without config blocks
-
-steps:
-  # Example 1: Direct coerce_to on repeat
-  - repeat:
-      until: "check_api_ready"
-      coerce_to: boolean  # Direct syntax - no config block needed
-      max_iterations: 5
-      steps:
-        - check_api_ready:
-            prompt: "Check if the API endpoint returns a 200 status"
-        - wait: 2
-  
-  # Example 2: Direct coerce_to on each  
-  - get_data_sources:
-      prompt: "List available data sources, one per line"
-  
-  - each: "get_data_sources"
-    as: "source"
-    coerce_to: iterable  # Direct syntax
-    steps:
-      - validate_source: "Validating {{source}}..."
-      - process_source:
-          prompt: "Process data from {{source}}"
-  
-  # Example 3: Multiple configuration options
-  - repeat:
-      until: "all_tests_pass"
-      coerce_to: llm_boolean  # Override default
-      print_response: true     # Other options work too
-      max_iterations: 10
-      steps:
-        - run_tests: "$(rake test)"
-        - all_tests_pass:
-            prompt: "Did all tests pass successfully?"

data/examples/dot_notation/README.md

@@ -1,37 +0,0 @@
-# Dot Notation Access Example
-
-This example demonstrates the new dot notation access feature for workflow outputs.
-
-## Usage
-
-With the new dot notation feature, you can access output values using Ruby's method syntax instead of hash syntax:
-
-### Before (hash syntax):
-```yaml
-until: "output[:update_fix_count][:fixes_applied] >= 5 || output[:select_next_issue][:no_issues_left] == true"
-```
-
-### After (dot notation):
-```yaml
-until: "output.update_fix_count.fixes_applied >= 5 || output.select_next_issue.no_issues_left?"
-```
-
-### Even cleaner (omitting output prefix):
-```yaml
-until: "update_fix_count.fixes_applied >= 5 || select_next_issue.no_issues_left?"
-```
-
-## Features
-
-1. **Nested access**: `output.step_name.nested.value`
-2. **Boolean predicates**: `output.step_name.is_complete?` returns false for nil/false values
-3. **Direct access**: Omit the `output.` prefix for cleaner syntax
-4. **Backward compatible**: Hash syntax still works (`output[:step_name][:value]`)
-
-## Example Workflow
-
-See `workflow.yml` for a complete example that demonstrates:
-- Setting values in output
-- Using dot notation in conditions
-- Boolean predicate methods
-- Nested value access