roast-ai 0.4.7 → 0.4.8

data/examples/pre_post_processing/optimize_test_performance/prompt.md

@@ -1,25 +0,0 @@
-# Optimize Test Performance
-
-Optimize the performance of <%= file %> by:
-
-1. **Reduce Setup Overhead**:
-   - Move expensive operations out of individual test setup
-   - Use shared fixtures where appropriate
-   - Lazy-load test data only when needed
-
-2. **Optimize Database Operations**:
-   - Use transactions for test isolation instead of truncation
-   - Minimize database queries in tests
-   - Use in-memory databases where possible
-
-3. **Improve Test Isolation**:
-   - Remove unnecessary dependencies between tests
-   - Clean up resources properly to avoid test pollution
-   - Use proper test doubles instead of hitting external services
-
-4. **Parallelize When Possible**:
-   - Identify tests that can run in parallel
-   - Remove shared state that prevents parallelization
-   - Group related tests for better cache utilization
-
-Generate the optimized test code and provide before/after performance metrics estimates.

data/examples/pre_post_processing/post_processing/aggregate_metrics/prompt.md

@@ -1,31 +0,0 @@
-# Aggregate Metrics
-
-Aggregate all the metrics collected during the workflow execution:
-
-Available data:
-- Pre-processing baseline metrics: <%= pre_processing.gather_baseline_metrics %>
-- Results from all processed test files: <%= output.targets %>
-
-Please calculate and provide:
-
-1. **Overall Coverage Improvement**:
-   - Total coverage before and after
-   - Percentage improvement
-   - Files with biggest improvements
-
-2. **Performance Gains**:
-   - Total execution time saved
-   - Average performance improvement per file
-   - Files with best optimization results
-
-3. **Test Quality Metrics**:
-   - Number of new tests added
-   - Number of tests optimized
-   - Reduction in flaky/brittle tests
-
-4. **Summary Statistics**:
-   - Total files processed
-   - Success rate
-   - Any files that had issues
-
-Output a comprehensive metrics summary that can be used in the final report.

data/examples/pre_post_processing/post_processing/cleanup_environment/prompt.md

@@ -1,28 +0,0 @@
-# Cleanup Environment
-
-Perform post-optimization cleanup tasks:
-
-1. **Commit Changes**: Create a commit with all the test improvements
-   - Use a descriptive commit message summarizing the optimization results
-   - Include key metrics in the commit description
-
-2. **Update Documentation**:
-   - Update test documentation if structure changed significantly
-   - Add notes about any new test helpers or patterns introduced
-
-3. **Clean Temporary Files**:
-   - Remove any temporary files created during optimization
-   - Clear test caches that were used for benchmarking
-
-4. **Final Verification**:
-   - Run the full test suite one more time to ensure everything works
-   - Verify CI/CD pipelines will work with the changes
-
-5. **Create PR Description**:
-   - Generate a pull request description template with:
-     - Summary of changes
-     - Key metrics improvements
-     - Any breaking changes or considerations
-     - Review checklist
-
-Output a summary of cleanup actions performed and any final notes for the team.

data/examples/pre_post_processing/post_processing/generate_summary_report/prompt.md

@@ -1,32 +0,0 @@
-# Generate Summary Report
-
-Generate a comprehensive test optimization report based on all the collected data:
-
-## Test Suite Optimization Report
-
-### Executive Summary
-Provide a high-level overview of the optimization results, key achievements, and any issues encountered.
-
-### Metrics Summary
-Include the aggregated metrics from the previous step:
-<%= aggregate_metrics %>
-
-### Detailed Results by File
-For each processed test file, include:
-- File name and path
-- Coverage improvement
-- Performance improvement
-- Number of tests added/modified
-- Key changes made
-
-### Recommendations
-Based on the optimization results, provide:
-1. Further optimization opportunities
-2. Best practices observed that should be adopted project-wide
-3. Common patterns that could be extracted into shared utilities
-4. Testing strategy improvements
-
-### Next Steps
-Suggest follow-up actions to maintain and build upon these improvements.
-
-Format the report in Markdown for easy sharing and include visual indicators (✅ ❌ ⚠️) for quick scanning.

data/examples/pre_post_processing/post_processing/output.txt

@@ -1,24 +0,0 @@
-=== Test Optimization Summary Report ===
-Generated at: <%= Time.now.strftime("%Y-%m-%d %H:%M:%S") %>
-
-## Baseline Metrics
-<%= pre_processing.gather_baseline_metrics %>
-
-## Files Processed
-Total files: <%= targets.size %>
-
-<% targets.each do |file, target| %>
-### <%= file %>
-Analysis: <%= target.output.analyze_test_file %>
-Coverage improvements: <%= target.output.improve_test_coverage %>
-Performance optimizations: <%= target.output.optimize_test_performance %>
-<% end %>
-
-## Post-Processing Results
-### Aggregated Metrics
-<%= output.aggregate_metrics %>
-
-### Summary Report
-<%= output.generate_summary_report %>
-
-=== End of Report ===

data/examples/pre_post_processing/pre_processing/gather_baseline_metrics/prompt.md

@@ -1,26 +0,0 @@
-# Gather Baseline Metrics
-
-Analyze the current test suite and gather baseline metrics for comparison. Please provide:
-
-1. Total number of test files to be processed
-2. Current overall test coverage percentage
-3. Average test execution time across all files
-4. Number of tests by type (unit, integration, system)
-5. Any test files that are particularly slow (> 5 seconds)
-
-Store these metrics in the workflow state for later comparison in post-processing.
-
-Output format:
-```json
-{
-  "total_test_files": 0,
-  "overall_coverage": 0.0,
-  "average_execution_time": 0.0,
-  "test_counts": {
-    "unit": 0,
-    "integration": 0,
-    "system": 0
-  },
-  "slow_tests": []
-}
-```

data/examples/pre_post_processing/pre_processing/setup_test_environment/prompt.md

@@ -1,11 +0,0 @@
-# Setup Test Environment
-
-Prepare the test environment for optimization. Please:
-
-1. Ensure all test dependencies are installed
-2. Create a backup branch for safety: `test-optimization-backup-<%= timestamp %>`
-3. Set up any necessary test databases or fixtures
-4. Configure test parallelization settings if available
-5. Clear any test caches that might affect benchmarking
-
-Return a summary of the setup steps completed and any warnings or issues encountered.

data/examples/pre_post_processing/validate_changes/prompt.md

@@ -1,24 +0,0 @@
-# Validate Changes
-
-Validate the changes made to <%= file %>:
-
-1. **Run the updated tests** and ensure they all pass
-2. **Check coverage metrics** to verify improvements
-3. **Measure execution time** to confirm performance gains
-4. **Verify no regressions** were introduced
-5. **Ensure code style** follows project conventions
-
-Store the validation results in the workflow state:
-```json
-{
-  "file": "<%= file %>",
-  "tests_passed": true,
-  "coverage_before": 0.0,
-  "coverage_after": 0.0,
-  "execution_time_before": 0.0,
-  "execution_time_after": 0.0,
-  "issues_found": []
-}
-```
-
-If any issues are found, provide recommendations for fixing them.

data/examples/pre_post_processing/workflow.yml

@@ -1,21 +0,0 @@
-name: test_optimization
-model: gpt-4o
-target: "test/**/*_test.rb"
-
-# Pre-processing steps run once before any test files are processed
-pre_processing:
-  - gather_baseline_metrics
-  - setup_test_environment
-
-# Main workflow steps run for each test file
-steps:
-  - analyze_test_file
-  - improve_test_coverage
-  - optimize_test_performance
-  - validate_changes
-
-# Post-processing steps run once after all test files have been processed
-post_processing:
-  - aggregate_metrics
-  - generate_summary_report
-  - cleanup_environment

data/examples/retry/workflow.yml

@@ -1,23 +0,0 @@
-description: Demonstrate retry functionality for steps
-
-# This example shows how to configure steps to automatically retry on failure
-# The 'retries' parameter specifies how many times to retry a failing step
-
-steps:
-  - check_network: "$(curl -f -s -o /dev/null -w '%{http_code}' https://httpstat.us/500)"
-  - process_data: "Process important data that might fail transiently"
-  - flaky_command: "$(./flaky_script.sh)"
-
-# Configuration for each step
-check_network:
-  retries: 3  # Will retry up to 3 times if it fails
-  exit_on_error: true  # Will exit workflow if all retries fail
-
-process_data:
-  model: gpt-4o-mini
-  retries: 2  # Will retry up to 2 times
-
-# Command with retries but won't exit on error after all retries fail
-flaky_command:
-  retries: 5
-  exit_on_error: false  # Continue workflow even after all retries fail

data/examples/rspec_to_minitest/README.md

@@ -1,68 +0,0 @@
-# RSpec to Minitest Migration Workflow
-
-This workflow demonstrates how to automate the migration of RSpec tests to their Minitest equivalents, following a structured approach to ensure proper test coverage and functionality.
-
-## Workflow Overview
-
-The workflow consists of three main steps:
-
-1. **Analyze Spec**: Understand the purpose and structure of the RSpec test, including its dependencies and testing patterns.
-2. **Create Minitest**: Generate a new Minitest file with equivalent test coverage and assertions.
-3. **Run and Improve**: Execute the Minitest file and iteratively improve it until all tests pass.
-
-## Prerequisites
-
-- Ruby environment with both RSpec and Minitest gems installed
-- Access to the original codebase being tested
-- Ability to run tests in the target environment
-
-## Usage
-
-To use this workflow:
-
-1. Configure the target pattern in `workflow.yml` to match the RSpec files you want to convert (or pass in via CLI --target option):
-   ```yaml
-   target: "path/to/specs/**/*_spec.rb"
-   ```
-
-2. Run the workflow with:
-   ```
-   roast execute examples/rspec_to_minitest/workflow.yml
-   ```
-
-3. Review the generated Minitest files and ensure they're correctly placed in your test directory.
-
-## Implementation Details
-
-The workflow leverages the following tools:
-
-- Standard file operations (read/write)
-- Code search capabilities to find related files
-- Command execution to run tests
-- CodingAgent for iterative improvements using AI-powered coding assistance
-
-## Required Tool: CodingAgent
-
-This workflow introduces a new tool called `CodingAgent` which leverages Claude Code to perform code-related tasks:
-
-1. Running tests
-2. Analyzing errors and failures
-3. Making iterative improvements to code
-
-The CodingAgent tool is implemented in `lib/roast/tools/coding_agent.rb`.
-
-## Conversion Mappings
-
-The workflow handles these common RSpec to Minitest conversions:
-
-| RSpec Feature | Minitest Equivalent |
-|---------------|---------------------|
-| `describe/context` | Test class |
-| `it` blocks | `test_*` methods |
-| `before/after` | `setup/teardown` methods |
-| `let/let!` | Instance variables or helper methods |
-| `expect(x).to eq(y)` | `assert_equal y, x` |
-| `expect(x).to be_truthy` | `assert x` |
-| `expect(x).to be_falsey` | `refute x` |
-| `expect { ... }.to raise_error` | `assert_raises { ... }` |
-| Mocks/doubles | Minitest mocking or Mocha |

data/examples/rspec_to_minitest/analyze_spec/prompt.md

@@ -1,30 +0,0 @@
-In this first step, try to understand the purpose and dependencies of the spec we will be migrating.
-
-1. Read the provided RSpec file carefully to understand:
-   - The purpose of the test suite
-   - The subject under test (SUT)
-   - Test structure and organization 
-   - Dependencies and fixtures used
-   - Mocks, stubs, and doubles
-
-2. Use your tools to search for the SUT implementation and any other important dependent files so that they will be in the context for future steps in this process.
-   - Dependencies include fixtures
-   - Note that test/fixtures already has quite a bit of fixture files present
-   - If any fixtures are missing, copy them over when you write the new test file later
-
-3. Identify RSpec-specific features being used, such as:
-   - describe/context blocks
-   - before/after hooks
-   - let and let! declarations
-   - expect(...).to syntax and matchers
-   - shared examples/contexts
-   - metadata and tags
-
-4. Provide a summary of your analysis, including:
-   - Purpose of the test suite
-   - Main subject under test
-   - Key dependencies
-   - Testing patterns used
-   - Any potentially challenging aspects for Minitest conversion
-
-This analysis will guide the next steps of creating an equivalent Minitest implementation. 

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