roast-ai 0.4.6 → 0.4.8

data/examples/rspec_to_minitest/create_minitest/prompt.md

@@ -1,33 +0,0 @@
-You are a Ruby testing expert assisting with migrating RSpec tests to Minitest.
-
-In this step, you'll create a new Minitest file that replicates the functionality of the analyzed RSpec test.
-
-## Your tasks:
-
-1. Convert the RSpec test to an equivalent Minitest test, following these guidelines:
-   - Replace RSpec's `describe`/`context` blocks with Minitest test classes
-   - Convert `it` blocks to Minitest test methods (prefixed with `test_`)
-   - Transform `before`/`after` hooks to `setup`/`teardown` methods
-   - Replace `let`/`let!` declarations with instance variables or helper methods
-   - Convert `expect(...).to` assertions to Minitest assertions
-   - Replace RSpec matchers with equivalent Minitest assertions
-   - Handle mocks and stubs using Minitest's mocking capabilities and Mocha
-
-2. Follow Minitest conventions:
-   - Name the file with `_test.rb` suffix instead of `_spec.rb`
-   - Create a class that inherits from `ActiveSupport::TestCase`
-   - Use that class's `test "description of the test` method to declare tests kind of like RSpec does
-   - Use Minitest's assertion methods (`assert`, `assert_equal`, etc.)
-   - Implement proper setup and teardown methods as needed
-
-3. Pay attention to:
-   - Maintaining test coverage with equivalent assertions
-   - Preserving the original test's intent and behavior
-   - Handling RSpec-specific features appropriately
-   - Adding necessary require statements for Minitest and dependencies
-
-4. Write the complete Minitest file and save it to the appropriate location, replacing `_spec.rb` with `_test.rb` in the filename.
-
-Your converted Minitest file should maintain at least the same test coverage and intent as the original RSpec test while following Minitest's conventions and patterns.
-
-IMPORTANT: If you see opportunities to improve the test coverage in the newly written tests, you have my permission to do so. However, note that we should focus on testing behavior, not implementation. Do not test private methods, and never use Ruby tricks to make private methods public. Try to avoid mocking or stubbing anything on the SUT class.

data/examples/rspec_to_minitest/run_and_improve/prompt.md

@@ -1,35 +0,0 @@
-You are a Ruby testing expert assisting with migrating RSpec tests to Minitest.
-
-In this final step, you'll use the `cmd` and `coding_agent` tool functions to run the newly created Minitest file and iteratively improve it until all tests pass correctly.
-
-## Your tasks:
-
-1. Run the converted Minitest file to see if it passes all tests. Use the `cmd` tool function to execute the test using the following syntax:
-   ```ruby
-   ruby -Ilib:test path/to/minitest_file.rb
-   ```
-
-2. Analyze any failures or errors that occur during test execution:
-   - Syntax errors
-   - Missing dependencies
-   - Assertion failures
-   - Test setup/teardown issues
-   - Unexpected behavior
-
-3. For each issue identified, prompt the `coding_agent` tool to make necessary improvements:
-   - Fix syntax errors
-   - Correct assertion formats
-   - Add missing dependencies
-   - Adjust test setup or teardown
-   - Modify assertions to match expected behavior
-
-4. Run the test again after each set of improvements.
-
-5. Continue this iterative process until all tests pass successfully.
-
-6. Once all tests pass, provide a summary of:
-   - Changes made to fix issues
-   - Any remaining considerations or edge cases
-   - Confirmation of test coverage compared to original RSpec tests
-
-Again, your goal is to ensure the Minitest version provides at least the same test coverage and reliability as the original RSpec tests, while following Minitest best practices and conventions.

data/examples/rspec_to_minitest/workflow.md

@@ -1,10 +0,0 @@
-You are a Ruby testing expert assisting with migrating RSpec tests to Minitest. Note that all of your responses should be in nicely formatted markdown.
-
-Here is the spec we're going to be migrating today:
-
-```
-# <%= file %>
-<%= File.read(file) %>
-```
-
-I have given you powerful tool functions to do this work. The coding_agent is especially powerful and you should delegate complex tasks to it whenever possible.

data/examples/rspec_to_minitest/workflow.yml

@@ -1,40 +0,0 @@
-# RSpec to Minitest Migration Workflow
-
-# This workflow demonstrates how to convert RSpec test files to Minitest:
-# 1. Analyzes the RSpec test to understand its purpose and dependencies
-# 2. Creates a new Minitest file with equivalent assertions and test structure
-# 3. Runs the tests and makes improvements until they pass
-
-name: RSpec to Minitest Migration
-model: gpt-4.1
-
-# Target expects a glob pattern matching RSpec files to be converted
-# target: "**/*_spec.rb"
-
-tools:
-  - Roast::Tools::ReadFile
-  - Roast::Tools::WriteFile
-  - Roast::Tools::Grep
-  - Roast::Tools::Cmd
-  - Roast::Tools::CodingAgent
-
-steps:
-  - analyze_spec
-  - create_minitest
-  - run_and_improve
-  - rubocop: $(bundle exec rubocop -A)
-  - Summarize the changes made to the codebase.
-
-# Configure the steps
-analyze_spec:
-  print_response: false
-
-create_minitest:
-  print_response: true
-
-run_and_improve:
-  print_response: true 
-
-functions:
-  grep:
-    cache: true

data/examples/shared_config/README.md

@@ -1,52 +0,0 @@
-# Shared Configuration Example
-
-This example demonstrates how to use `shared.yml` to define common configuration anchors that can be referenced across multiple workflow files.
-
-## Structure
-
-```
-├── shared.yml                      # Common configuration anchors
-└── example_with_shared_config/
-    └── workflow.yml               # Workflow using shared anchors
-```
-
-## How it works
-
-1. When loading a workflow file, Roast checks if `shared.yml` exists one level above the workflow directory
-2. If found, it loads `shared.yml` first, then the workflow file
-3. This allows YAML anchors defined in `shared.yml` to be referenced in workflow files
-
-## Example Usage
-
-In `shared.yml`:
-```yaml
-standard_tools: &standard_tools
-  - Roast::Tools::Grep
-  - Roast::Tools::ReadFile
-  - Roast::Tools::WriteFile
-  - Roast::Tools::SearchFile
-
-mirage: &mirage '$(echo "Oh my god. Its a mirage")'
-```
-
-In your workflow:
-```yaml
-name: Example with shared config
-tools: *standard_tools  # Reference the standard tools from shared.yml
-
-steps:
-  - *mirage  # Reference a shared step definition
-  - sabotage: '$(echo "Im tellin yall, its sabotage")'
-```
-
-## Running the Example
-
-```bash
-# Run the workflow that uses shared configuration
-roast execute examples/shared_config/example_with_shared_config/workflow.yml
-```
-
-The workflow will:
-1. Load the shared configuration from `shared.yml`
-2. Apply the referenced tools and steps
-3. Execute the workflow with the merged configuration

data/examples/shared_config/example_with_shared_config/workflow.yml

@@ -1,6 +0,0 @@
-name: Example with shared config
-tools: *standard_tools
-
-steps:
-  - *mirage
-  - sabotage: '$(echo "Im tellin yall, its sabotage")'

data/examples/shared_config/shared.yml

@@ -1,7 +0,0 @@
-standard_tools: &standard_tools
-  - Roast::Tools::Grep
-  - Roast::Tools::ReadFile
-  - Roast::Tools::WriteFile
-  - Roast::Tools::SearchFile
-
-mirage: &mirage '$(echo "Oh my god. Its a mirage")'

data/examples/single_target_prepost/README.md

@@ -1,36 +0,0 @@
-# Single Target with Pre/Post Processing Example
-
-This example demonstrates how pre/post processing works with single-target workflows. Even when analyzing just one file, you can use pre-processing to gather context and post-processing to format results.
-
-## Features Demonstrated
-
-1. **Pre-processing for context gathering** - Analyze dependencies before the main workflow
-2. **Single-target analysis** - Focus on one specific file
-3. **Post-processing with output template** - Custom formatting of the final report
-
-## Running the Example
-
-```bash
-roast workflow.yml
-```
-
-This will:
-1. Run pre-processing to gather dependencies and context
-2. Analyze the single target file (src/main.rb)
-3. Apply the post-processing template to format the output
-
-## Output Template
-
-The `post_processing/output.txt` template demonstrates how to:
-- Access pre-processing results with `<%= pre_processing[:step_name] %>`
-- Iterate over target results (even for single targets)
-- Include post-processing step outputs
-- Format everything into a professional report
-
-## Use Cases
-
-This pattern is ideal for:
-- Deep analysis of critical files
-- Security audits of specific components
-- Performance profiling of key modules
-- Generating documentation for important classes

data/examples/single_target_prepost/post_processing/output.txt

@@ -1,27 +0,0 @@
-=== Code Analysis Report ===
-Generated: <%= Time.now.strftime("%Y-%m-%d %H:%M:%S") %>
-
-## Dependencies & Context
-<%= pre_processing.gather_dependencies %>
-
-## Target File Analysis
-<% targets.each do |file, target| %>
-File: <%= file %>
-
-### Code Quality
-<%= target.output.analyze_code_quality %>
-
-### Identified Improvements
-<%= target.output.identify_improvements %>
-
-### Recommendations
-<%= target.output.generate_recommendations %>
-<% end %>
-
-## Summary
-<%= output.summarize_findings %>
-
-## Action Items
-<%= output.create_action_items %>
-
-=== End of Report ===

data/examples/single_target_prepost/pre_processing/gather_dependencies/prompt.md

@@ -1,11 +0,0 @@
-# Gather Dependencies
-
-Analyze the project structure to understand the dependencies and context for <%= file %>.
-
-Tasks:
-1. List all files that import or depend on the target file
-2. Identify the key modules and classes used
-3. Note any external dependencies or libraries
-4. Summarize the architectural context
-
-Provide a structured summary that will help with the main analysis.

data/examples/single_target_prepost/workflow.yml

@@ -1,20 +0,0 @@
-name: analyze_codebase
-description: Analyze a single codebase with pre/post processing support
-model: gpt-4o
-target: "src/main.rb"
-
-# Pre-processing: Gather context before analyzing the main file
-pre_processing:
-  - gather_dependencies
-  - setup_analysis_tools
-
-# Main workflow: Analyze the target file
-steps:
-  - analyze_code_quality
-  - identify_improvements
-  - generate_recommendations
-
-# Post-processing: Generate final report
-post_processing:
-  - summarize_findings
-  - create_action_items

data/examples/smart_coercion_defaults/README.md

@@ -1,65 +0,0 @@
-# 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

@@ -1,44 +0,0 @@
-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

@@ -1,84 +0,0 @@
-# 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")
-- `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
-  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
-  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

@@ -1,57 +0,0 @@
-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
-
-# Configuration for specific steps
-summarize the code:
-  model: claude-3-opus  # Override global model
-  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
-  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/swarm_example.yml

@@ -1,25 +0,0 @@
-name: Swarm Example Workflow
-
-# Example workflow demonstrating Roast's integration with Claude Swarm
-# The Swarm tool is available to the LLM, which can choose to use it when appropriate
-
-tools:
-  - Roast::Tools::Swarm:
-      path: ".swarm.yml"  # Optional - will use default locations if not specified
-
-steps:
-  - orchestrate_refactoring: |
-      Help me refactor this codebase for better performance. Coordinate multiple 
-      Claude agents using the swarm configuration to:
-      1. Analyze the current code structure
-      2. Identify performance bottlenecks
-      3. Implement optimizations
-      4. Ensure backward compatibility
-      
-  - specialized_analysis: |
-      Now use the specialized swarm configuration at ./specialized-swarm.yml to run 
-      a comprehensive code analysis that includes:
-      - Architecture review
-      - Security audit  
-      - Documentation generation
-      - Test coverage analysis