roast-ai 0.1.0 → 0.1.1

data/docs/INSTRUMENTATION.md

@@ -0,0 +1,202 @@
+# Instrumentation Hooks in Roast
+
+Roast provides built-in instrumentation hooks using ActiveSupport::Notifications, allowing you to track workflow execution, monitor performance, and integrate with your own monitoring systems.
+
+## Overview
+
+The instrumentation system emits events at key points during workflow execution:
+
+- Workflow lifecycle (start, complete)
+- Step execution (start, complete, error)
+- Chat completion/AI calls (start, complete, error)
+- Tool function execution
+
+## Configuration
+
+To add custom instrumentation, create Ruby files in your project's `.roast/initializers/` directory. These files will be automatically loaded during workflow startup.
+
+Example structure:
+```
+your-project/
+  ├── .roast/
+  │   └── initializers/
+  │       ├── logging.rb
+  │       ├── metrics.rb
+  │       └── monitoring.rb
+  └── ...
+```
+
+## Available Events
+
+### Workflow Events
+
+- `roast.workflow.start` - Emitted when a workflow begins
+  - Payload: `{ workflow_path:, options:, name: }`
+  
+- `roast.workflow.complete` - Emitted when a workflow completes
+  - Payload: `{ workflow_path:, success:, execution_time: }`
+
+### Step Events
+
+- `roast.step.start` - Emitted when a step begins execution
+  - Payload: `{ step_name: }`
+  
+- `roast.step.complete` - Emitted when a step completes successfully
+  - Payload: `{ step_name:, success: true, execution_time:, result_size: }`
+  
+- `roast.step.error` - Emitted when a step encounters an error
+  - Payload: `{ step_name:, error:, message:, execution_time: }`
+
+### AI/Chat Completion Events
+
+- `roast.chat_completion.start` - Emitted before an AI API call
+  - Payload: `{ model:, parameters: }`
+  
+- `roast.chat_completion.complete` - Emitted after successful AI API call
+  - Payload: `{ success: true, model:, parameters:, execution_time:, response_size: }`
+  
+- `roast.chat_completion.error` - Emitted when AI API call fails
+  - Payload: `{ error:, message:, model:, parameters:, execution_time: }`
+
+### Tool Execution Events
+
+- `roast.tool.execute` - Emitted when a tool function is called
+  - Payload: `{ function_name:, params: }`
+
+- `roast.tool.complete` - Emitted when a tool function completes
+  - Payload: `{ function_name:, execution_time:, cache_enabled: }`
+  
+- `roast.tool.error` - Emitted when a tool execution fails
+  - Payload: `{ function_name:, error:, message:, execution_time: }`
+
+## Example Usage
+
+### Basic Logging
+
+```ruby
+# .roast/initializers/logging.rb
+ActiveSupport::Notifications.subscribe(/roast\./) do |name, start, finish, id, payload|
+  duration = finish - start
+  puts "[#{name}] completed in #{duration.round(3)}s"
+end
+```
+
+### Performance Monitoring
+
+```ruby
+# .roast/initializers/performance.rb
+ActiveSupport::Notifications.subscribe("roast.step.complete") do |name, start, finish, id, payload|
+  duration = finish - start
+  if duration > 10.0
+    puts "WARNING: Step '#{payload[:step_name]}' took #{duration.round(1)}s"
+  end
+end
+```
+
+### Integration with External Services
+
+```ruby
+# .roast/initializers/metrics.rb
+ActiveSupport::Notifications.subscribe("roast.workflow.complete") do |name, start, finish, id, payload|
+  duration = finish - start
+  
+  # Send to your metrics service
+  MyMetricsService.track_event("workflow_execution", {
+    workflow_path: payload[:workflow_path],
+    duration: duration,
+    success: payload[:success]
+  })
+end
+```
+
+### Internal Shopify Example
+
+For the internal Shopify version, you can use these instrumentation hooks to track metrics with Monorail:
+
+```ruby
+# .roast/initializers/monorail.rb
+
+# Track workflow execution
+ActiveSupport::Notifications.subscribe("roast.workflow.start") do |name, start, finish, id, payload|
+  Roast::Support::Monorail.track_command("run", {
+    "workflow_path" => payload[:workflow_path],
+    "options" => payload[:options],
+    "name" => payload[:name]
+  })
+end
+
+ActiveSupport::Notifications.subscribe("roast.workflow.complete") do |name, start, finish, id, payload|
+  Roast::Support::Monorail.track_command("run_complete", {
+    "workflow_path" => payload[:workflow_path],
+    "success" => payload[:success],
+    "execution_time" => payload[:execution_time]
+  })
+end
+
+# Track AI model usage and performance
+ActiveSupport::Notifications.subscribe("roast.chat_completion.complete") do |name, start, finish, id, payload|
+  Roast::Support::Monorail.track_command("ai_usage", {
+    "model" => payload[:model],
+    "execution_time" => payload[:execution_time],
+    "response_size" => payload[:response_size],
+    "has_json" => payload[:parameters][:json] || false,
+    "has_loop" => payload[:parameters][:loop] || false
+  })
+end
+
+# Track tool execution and caching
+ActiveSupport::Notifications.subscribe("roast.tool.complete") do |name, start, finish, id, payload|
+  Roast::Support::Monorail.track_command("tool_usage", {
+    "function_name" => payload[:function_name],
+    "execution_time" => payload[:execution_time],
+    "cache_enabled" => payload[:cache_enabled]
+  })
+end
+```
+
+See `examples/monorail_initializer.rb` for a complete example of Monorail integration.
+
+## Best Practices
+
+1. **Keep initializers focused**: Each initializer should handle a specific concern (logging, metrics, error reporting, etc.)
+
+2. **Handle errors gracefully**: Wrap your subscriber code in error handling to prevent crashes:
+   ```ruby
+   ActiveSupport::Notifications.subscribe("roast.workflow.start") do |name, start, finish, id, payload|
+     begin
+       # Your instrumentation code here
+     rescue => e
+       $stderr.puts "Instrumentation error: #{e.message}"
+     end
+   end
+   ```
+
+3. **Avoid blocking operations**: Instrumentation should be fast and non-blocking. For heavy operations, consider using async processing.
+
+4. **Use pattern matching**: Subscribe to specific event patterns to reduce overhead:
+   ```ruby
+   # Subscribe only to workflow events
+   ActiveSupport::Notifications.subscribe(/roast\.workflow\./) do |name, start, finish, id, payload|
+     # Handle only workflow events
+   end
+   ```
+
+5. **Consider performance impact**: While instrumentation is valuable, too many subscribers can impact performance. Be selective about what you instrument.
+
+## Testing Your Instrumentation
+
+You can test your instrumentation by creating a simple workflow and observing the events:
+
+```yaml
+# test_instrumentation.yml
+name: instrumentation_test
+steps:
+  - test_step
+```
+
+Then run:
+```bash
+roast execute test_instrumentation.yml some_file.rb
+```
+
+Your instrumentation should capture the workflow start, step execution, and workflow completion events.

data/examples/api_workflow/README.md

@@ -0,0 +1,85 @@
+# API Workflow Example
+
+This example demonstrates a targetless workflow that interacts with APIs rather than operating on specific files.
+
+## Structure
+
+The workflow consists of three steps that work together to create a complete API integration process:
+
+1. `fetch_api_data` - Simulates fetching data from a weather API and returns a structured JSON response
+2. `transform_data` - Processes the JSON data into a human-readable markdown format 
+3. `generate_report` - Creates a polished report with recommendations based on the weather data
+
+## Running the Example
+
+To run this example, you need to have a valid API token. The example is configured to fetch a token using a shell command:
+
+```yaml
+# Dynamic API token using shell command
+api_token: $(print-token --key)
+```
+
+You can modify this to use your own token source, such as:
+
+```yaml
+# Using an environment variable
+api_token: $(echo $OPENAI_API_KEY)
+
+# Or a direct value (not recommended for production)
+api_token: $(echo "sk-your-actual-token")
+```
+
+Then run the workflow:
+
+```bash
+# Run the targetless workflow
+roast execute examples/api_workflow/workflow.yml
+
+# Save the output to a file
+roast execute examples/api_workflow/workflow.yml -o weather_report.md
+```
+
+## How Targetless Workflows Work
+
+Targetless workflows operate without a specific target file. This is useful for:
+
+- API integrations
+- Content generation
+- Data analysis
+- Report creation
+- Interactive tools
+
+Unlike file-based workflows that process each target separately, targetless workflows run once and can retrieve their own data sources (like API calls) or generate content from scratch.
+
+## Workflow Definition
+
+```yaml
+name: API Integration Workflow
+# Default model for all steps
+model: gpt-4o-mini
+
+tools:
+  - Roast::Tools::ReadFile
+  - Roast::Tools::Grep
+  - Roast::Tools::WriteFile
+
+steps:
+  - fetch_api_data
+  - transform_data
+  - generate_report
+
+# Tool configurations for API calls (no need to specify model here since it uses global model)
+fetch_api_data:
+  print_response: true
+```
+
+## Creating Your Own Targetless Workflows
+
+To create your own targetless workflow:
+
+1. Create a workflow YAML file without a `target` parameter
+2. Define the steps your workflow will execute
+3. Create prompt files for each step
+4. Run the workflow with `roast execute your_workflow.yml`
+
+Your steps can use the workflow's `output` hash to pass data between them, just like in file-based workflows.

data/examples/api_workflow/fetch_api_data/prompt.md

@@ -0,0 +1,10 @@
+You are an assistant helping with retrieving data from an API source.
+
+Your task is to simulate fetching data from a weather API using mock data. 
+
+1. Imagine you are retrieving current weather conditions for various cities
+2. Create a structured JSON response that represents typical weather API data
+3. The response should include temperature, conditions, wind, and other relevant weather metrics
+4. Format the response as valid JSON that could be parsed programmatically
+
+Return only the JSON data without any additional explanation.

data/examples/api_workflow/generate_report/prompt.md

@@ -0,0 +1,10 @@
+You are an assistant helping to generate a final weather report.
+
+Based on the transformed data from the previous step, create a polished report that could be sent to stakeholders.
+
+1. Take the transformed weather data and enhance it with recommendations and insights
+2. Add relevant suggestions based on the weather conditions (like what to wear, activities that would be appropriate, etc.)
+3. Include a "forecast overview" section that summarizes the key points
+4. Format the output as a professional-looking report with proper headings and structure
+
+The report should be comprehensive yet concise, easy to scan, and provide actionable insights based on the weather data.

data/examples/api_workflow/prompt.md

@@ -0,0 +1,10 @@
+# API Integration Workflow
+
+This workflow demonstrates how to create an API integration that:
+1. Fetches data from an external source
+2. Transforms the data into a usable format
+3. Generates a report based on the processed data
+
+The workflow doesn't require a target file because it's designed to work with external APIs and data sources rather than processing specific files.
+
+You'll be working through a weather data processing example. This is a simulation to demonstrate the workflow pattern - no actual API calls are made.

data/examples/api_workflow/transform_data/prompt.md

@@ -0,0 +1,10 @@
+You are an assistant helping to transform API data.
+
+Your task is to process weather data from a JSON format into a more readable summary.
+
+1. Review the weather data provided in the previous step
+2. Transform the technical JSON data into a human-readable summary
+3. Format the output as markdown with appropriate sections and highlights
+4. Focus on the most relevant information that would be useful to a typical user
+
+Return a well-formatted markdown summary of the weather data.

data/examples/api_workflow/workflow.yml

@@ -0,0 +1,30 @@
+# API Integration Workflow
+
+# This workflow demonstrates how to create an API integration that:
+# 1. Fetches data from an external source
+# 2. Transforms the data into a usable format
+# 3. Generates a report based on the processed data
+
+# The workflow doesn't require a target file because it's designed to work with external APIs and data sources rather than processing specific files.
+
+# You'll be working through a weather data processing example. This is a simulation to demonstrate the workflow pattern - no actual API calls are made.
+
+name: API Integration Workflow
+model: gpt-4o-mini
+
+tools:
+  - Roast::Tools::ReadFile
+  - Roast::Tools::Grep
+  - Roast::Tools::WriteFile
+
+# For demonstration purposes only - in production you would use a real token command
+# api_token: $(echo "demo_token_123456")
+
+steps:
+  - fetch_api_data
+  - transform_data
+  - generate_report
+
+# Tool configurations for API calls
+fetch_api_data:
+  print_response: true

data/examples/grading/workflow.yml

@@ -23,7 +23,7 @@ steps:
 # set non-default attributes for steps below
 analyze_coverage:
   model: gpt-4.1-mini
-  loop: false
+  auto_loop: false
   json: true
   
 generate_grades:
@@ -32,7 +32,7 @@ generate_grades:
 
 generate_recommendations:
   model: o3
-  loop: false
+  auto_loop: false
   json: true
   params:
     max_completion_tokens: 5_000

data/examples/instrumentation.rb

@@ -0,0 +1,76 @@
+# frozen_string_literal: true
+
+# Demonstration of how to use the Roast instrumentation hooks
+# This file would typically be placed in PROJECT_ROOT/.roast/initializers/
+# for automatic loading during workflow execution
+
+# Example: Log all workflow and step events
+ActiveSupport::Notifications.subscribe(/roast\.workflow\./) do |name, start, finish, _id, payload|
+  duration = finish - start
+
+  case name
+  when "roast.workflow.start"
+    puts "\n🚀 Workflow starting: #{payload[:name]}"
+    puts "   Path: #{payload[:workflow_path]}"
+    puts "   Options: #{payload[:options]}"
+  when "roast.workflow.complete"
+    status = payload[:success] ? "✅ Successfully" : "❌ With errors"
+    puts "\n#{status} completed workflow in #{duration.round(2)} seconds"
+  end
+end
+
+# Example: Track step execution times
+ActiveSupport::Notifications.subscribe(/roast\.step\./) do |name, start, finish, _id, payload|
+  duration = finish - start
+
+  case name
+  when "roast.step.start"
+    puts "\n  ▶️ Step starting: #{payload[:step_name]}"
+  when "roast.step.complete"
+    puts "  ✅ Step completed: #{payload[:step_name]} (#{duration.round(3)}s)"
+  when "roast.step.error"
+    puts "  ❌ Step failed: #{payload[:step_name]}"
+    puts "     Error: #{payload[:error]} - #{payload[:message]}"
+  end
+end
+
+# Example: Monitor AI interactions
+ActiveSupport::Notifications.subscribe(/roast\.chat_completion\./) do |name, start, finish, _id, payload|
+  case name
+  when "roast.chat_completion.start"
+    puts "\n  🤖 AI request starting (model: #{payload[:model]})"
+    puts "     Parameters: #{payload[:parameters].inspect}" if payload[:parameters].any?
+  when "roast.chat_completion.complete"
+    duration = finish - start
+    puts "  🤖 AI request completed in #{duration.round(2)}s (execution time: #{payload[:execution_time].round(2)}s)"
+    puts "     Response size: #{payload[:response_size]} characters"
+  when "roast.chat_completion.error"
+    puts "  🤖 AI request failed: #{payload[:error]} - #{payload[:message]}"
+    puts "     Execution time: #{payload[:execution_time].round(2)}s"
+  end
+end
+
+# Example: Track tool executions
+ActiveSupport::Notifications.subscribe(/roast\.tool\./) do |name, _start, _finish, _id, payload|
+  case name
+  when "roast.tool.execute"
+    puts "\n  🔧 Executing tool: #{payload[:function_name]}"
+  when "roast.tool.complete"
+    puts "  🔧 Tool completed: #{payload[:function_name]} (#{payload[:execution_time].round(3)}s)"
+    puts "     Cache enabled: #{payload[:cache_enabled]}"
+  when "roast.tool.error"
+    puts "  🔧 Tool failed: #{payload[:function_name]}"
+    puts "     Error: #{payload[:error]} - #{payload[:message]}"
+    puts "     Execution time: #{payload[:execution_time].round(3)}s"
+  end
+end
+
+# In a Shopify-specific initializer (e.g., .roast/initializers/monorail.rb),
+# you could replace these logging examples with actual Monorail tracking:
+#
+# ActiveSupport::Notifications.subscribe("roast.workflow.start") do |name, start, finish, id, payload|
+#   Roast::Support::Monorail.track_command("run", {
+#     "workflow_path" => payload[:workflow_path],
+#     "name" => payload[:name]
+#   })
+# end

data/examples/rspec_to_minitest/README.md

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

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

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

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

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

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