roast-ai 0.4.6 → 0.4.8

data/examples/agent_continue/add_documentation/prompt.md

@@ -1,5 +0,0 @@
-Add documentation to the refactored code.
-Include:
-- Method documentation
-- Class-level documentation
-- Usage examples where appropriate

data/examples/agent_continue/add_error_handling/prompt.md

@@ -1,5 +0,0 @@
-Enhance the GitHub client with comprehensive error handling:
-- Network errors
-- Authentication failures
-- Rate limit exceeded
-- API validation errors

data/examples/agent_continue/analyze_codebase/prompt.md

@@ -1,7 +0,0 @@
-Analyze this Ruby codebase and identify areas that could benefit from refactoring.
-Focus on:
-- Code duplication
-- Complex methods that could be simplified
-- Missing abstractions
-
-Create a list of suggested improvements.

data/examples/agent_continue/combined_workflow.yml

@@ -1,24 +0,0 @@
-description: Example combining both continue and context summary features
-
-# This example shows how both parameters can work together for complex workflows
-
-steps:
-  # Initial exploration
-  - explore_api
-  
-  # First coding agent task
-  - ^implement_client
-  
-  # Continue with context awareness
-  - ^add_error_handling
-  
-  # Final implementation with full context
-  - ^create_integration_tests
-
-add_error_handling:
-  continue: true  # Continue working on the same client
-  include_context_summary: true  # Include context about what was explored and built
-
-create_integration_tests:
-  continue: true  # Continue in the same session
-  include_context_summary: true  # Full context of implementation

data/examples/agent_continue/continue_adding_features/prompt.md

@@ -1,4 +0,0 @@
-Now add these additional features to the todo list class:
-- Mark items as complete
-- Filter by status (complete/incomplete)
-- Save to and load from a JSON file

data/examples/agent_continue/create_integration_tests/prompt.md

@@ -1,3 +0,0 @@
-Create integration tests for the GitHub client.
-Test all the functionality including error scenarios.
-Use VCR for recording API interactions.

data/examples/agent_continue/document_with_context/prompt.md

@@ -1,5 +0,0 @@
-Based on what has been implemented so far, create a comprehensive README.md file that includes:
-- Overview of the TodoList class
-- All available methods and their usage
-- Code examples
-- Installation instructions

data/examples/agent_continue/explore_api/prompt.md

@@ -1,6 +0,0 @@
-Explore the GitHub API and document:
-- Key endpoints for repository management
-- Authentication requirements
-- Rate limiting considerations
-
-Format as a structured summary.

data/examples/agent_continue/implement_client/prompt.md

@@ -1,6 +0,0 @@
-Create a Ruby client for the GitHub API that includes:
-- Basic authentication
-- Repository listing
-- Repository creation
-
-Use the information from the API exploration.

data/examples/agent_continue/inline_workflow.yml

@@ -1,20 +0,0 @@
-description: Example workflow using inline agent prompts with continuation
-
-# This example demonstrates using inline agent prompts (direct text after ^)
-# combined with the new parameters
-
-steps:
-  # Start with a fresh context
-  - ^Create a simple Ruby class for managing a todo list with add, remove, and list methods
-  
-  # Continue from previous session to add more features
-  - ^continue_adding_features
-  
-  # Use context summary to understand what was built
-  - ^document_with_context
-
-continue_adding_features:
-  continue: true  # This continues from the previous agent session
-
-document_with_context:
-  include_context_summary: true  # This will include context about previous steps

data/examples/agent_continue/refactor_code/prompt.md

@@ -1,2 +0,0 @@
-Now implement the refactoring suggestions you identified.
-Start with the highest priority items.

data/examples/agent_continue/verify_changes/prompt.md

@@ -1,6 +0,0 @@
-Review all the changes made by the coding agent steps.
-Provide a summary of:
-- What was analyzed
-- What refactorings were applied
-- What documentation was added
-- Any potential issues or concerns

data/examples/agent_continue/workflow.yml

@@ -1,27 +0,0 @@
-description: Example workflow demonstrating agent continuation and context summary features
-
-# This example shows how to use the new coding agent parameters:
-# - continue: true - continues from previous agent session
-# - include_context_summary: true - includes workflow context in the prompt
-
-target: "**/*.rb"
-
-steps:
-  # First agent step - starts fresh
-  - ^analyze_codebase
-  
-  # Second agent step - continues from previous session
-  - ^refactor_code
-  
-  # Third agent step - includes context summary from previous steps
-  - ^add_documentation
-  
-  # Final verification step
-  - verify_changes
-
-# Step configurations
-refactor_code:
-  continue: true  # Continue from the previous agent session
-
-add_documentation:
-  include_context_summary: true  # Include workflow context in the prompt

data/examples/agent_workflow/README.md

@@ -1,75 +0,0 @@
-# Agent Workflow Example
-
-This example demonstrates the practical differences between regular steps and agent steps in Roast workflows.
-
-## What are Agent Steps?
-
-Agent steps are a special type of step that sends prompts directly to the CodingAgent tool (e.g., Claude Code) without going through the normal LLM translation layer. They're denoted by prefixing the step name with `^`.
-
-## When to Use Each Type
-
-### Regular Steps
-Best for tasks that benefit from LLM interpretation:
-- Analysis and judgment tasks
-- Natural language understanding
-- Flexible responses based on context
-- Summary and explanation generation
-
-### Agent Steps
-Best for tasks requiring precise tool control:
-- Exact code refactoring operations
-- Multi-file coordinated changes
-- Specific tool usage requirements
-- Performance-critical operations
-
-## Workflow Structure
-
-This example demonstrates a code refactoring workflow:
-
-1. **identify_code_smells** (Regular Step)
-   - Analyzes code to identify issues
-   - Uses LLM judgment to prioritize problems
-   - Provides contextual explanations
-
-2. **^apply_refactorings** (Agent Step)
-   - Executes precise refactoring operations
-   - Uses specific tools (Read, MultiEdit) directly
-   - Follows exact formatting requirements
-   - No interpretation needed - just execution
-
-3. **summarize_improvements** (Regular Step)
-   - Reviews all changes made
-   - Generates human-friendly summary
-   - Provides recommendations
-
-## Running the Workflow
-
-```bash
-# Run on all Ruby files in current directory
-roast execute examples/agent_workflow/workflow.yml
-
-# Run on specific files
-roast execute examples/agent_workflow/workflow.yml app/models/*.rb
-```
-
-## Key Differences in Practice
-
-### Regular Step Example
-The `identify_code_smells` step benefits from LLM interpretation because:
-- It needs to understand "code smells" in context
-- It makes subjective judgments about code quality
-- It prioritizes issues based on impact
-
-### Agent Step Example
-The `^apply_refactorings` step works better as an agent step because:
-- It requires specific tool usage (MultiEdit, not Write)
-- It needs exact preservation of formatting
-- It follows precise refactoring patterns
-- No interpretation is needed - just execution
-
-## Benefits Demonstrated
-
-1. **Complementary Strengths**: Regular steps handle analysis and planning, agent steps handle precise execution
-2. **Better Performance**: Agent steps skip the LLM layer for well-defined tasks
-3. **Predictable Results**: Agent steps execute exactly as specified
-4. **Tool Control**: Agent steps can enforce specific tool usage patterns

data/examples/agent_workflow/apply_refactorings/prompt.md

@@ -1,22 +0,0 @@
-Based on the code smells identified in the previous step, apply the following refactorings:
-
-For each file that needs changes:
-
-1. Use the Read tool to examine the current implementation
-2. Use MultiEdit to apply all refactorings in a single operation per file
-3. Ensure all changes maintain exact formatting and indentation
-4. Focus on these specific refactorings:
-   - Extract long methods (>15 lines) into smaller, focused methods
-   - Replace magic numbers with named constants
-   - Rename variables/methods that don't clearly express intent
-   - Extract duplicate code into shared methods
-   - Add proper error handling where missing
-
-Important constraints:
-- DO NOT change the public API of any class
-- DO NOT modify test files
-- DO NOT add comments unless replacing unclear code
-- Preserve all existing functionality
-- Use Ruby idioms and conventions
-
-After each file modification, verify the changes maintain the original behavior.

data/examples/agent_workflow/identify_code_smells/prompt.md

@@ -1,15 +0,0 @@
-Analyze the provided Ruby code and identify potential code smells or areas for improvement. Consider:
-
-1. Method complexity and length
-2. Duplicated code patterns
-3. Poor naming conventions
-4. Tight coupling between classes
-5. Missing abstractions or violated SOLID principles
-6. Performance anti-patterns
-
-For each issue found, explain:
-- What the problem is
-- Why it's problematic
-- A general approach to fix it
-
-Focus on the most impactful improvements that would enhance code maintainability and readability.

data/examples/agent_workflow/summarize_improvements/prompt.md

@@ -1,18 +0,0 @@
-Review the refactorings that were applied and provide a comprehensive summary that includes:
-
-1. **Overview of Changes**
-   - Number of files modified
-   - Types of refactorings applied
-   - Overall impact on code quality
-
-2. **Key Improvements**
-   - Most significant refactorings and their benefits
-   - Complexity reductions achieved
-   - Readability enhancements
-
-3. **Recommendations for Future**
-   - Any remaining code smells that require larger architectural changes
-   - Suggested next steps for continued improvement
-   - Areas that would benefit from additional test coverage
-
-Format the summary in a way that would be useful for a code review or team discussion.

data/examples/agent_workflow/workflow.yml

@@ -1,16 +0,0 @@
-description: Example workflow demonstrating agent steps
-
-# Agent steps send prompts directly to CodingAgent (e.g., Claude Code)
-# without the intermediate LLM translation layer
-
-target: "**/*.rb"
-
-steps:
-  # Regular step - goes through LLM first for analysis and judgment
-  - identify_code_smells
-  
-  # Agent step - direct to CodingAgent for precise refactoring
-  - ^apply_refactorings
-  
-  # Regular step - verify changes and provide summary
-  - summarize_improvements

data/examples/api_workflow/README.md

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

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

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

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

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

@@ -1,30 +0,0 @@
-# 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/apply_diff_demo/README.md

@@ -1,58 +0,0 @@
-# Apply Diff Demo
-
-This example demonstrates the `apply_diff` tool, which shows users a colored diff of proposed changes and applies them only after user confirmation.
-
-## What this workflow does
-
-1. **Creates a sample file** - Generates `hello.txt` with simple text content
-2. **Applies a simple change** - Uses `apply_diff` to modify the greeting and ask for user confirmation
-
-## Key features demonstrated
-
-- **Interactive approval** - The `apply_diff` tool shows a clear, colored diff and waits for user confirmation
-- **Safe modifications** - Changes are only applied when the user explicitly approves them
-- **Colored visualization** - Diff format shows exactly what will be changed with:
-  - **Red** lines starting with `-` for removed content
-  - **Green** lines starting with `+` for added content  
-  - **Cyan** line numbers and context (`@@` lines)
-  - **Bold** diff headers
-- **Optional descriptions** - You can provide context about why a change is being made
-
-## Running the workflow
-
-```bash
-bin/roast examples/apply_diff_demo/workflow.yml
-```
-
-## Expected interaction
-
-When you run this workflow, you'll see:
-
-1. The workflow creates a simple `hello.txt` file
-2. It proposes changing "Hello World!" to "Hello, Apply Diff Demo!"
-3. It shows you a colored diff of the proposed change:
-   ```
-   📝 Proposed change for hello.txt:
-   Description: Update greeting to be more specific to the demo
-   
-   diff --git a/hello.txt b/hello.txt
-   index 1234567..abcdefg 100644
-   --- a/hello.txt
-   +++ b/hello.txt
-   @@ -1,3 +1,3 @@
-   -Hello World!
-   +Hello, Apply Diff Demo!
-    This is a demo file.
-    We will modify this file in the next step.
-   ```
-4. It asks for your confirmation: `Apply this change? (y/n)`
-5. If you say "y", it applies the change; if "n", it cancels
-6. Finally, it reads the file again to show the result
-
-## Tools used
-
-- `Roast::Tools::WriteFile` - Creates the initial sample file
-- `Roast::Tools::ReadFile` - Reads files to show results
-- `Roast::Tools::ApplyDiff` - Shows colored diffs and applies changes with user confirmation
-
-This pattern is useful for any workflow where you want to make targeted changes to files but give users control over what actually gets applied.

data/examples/apply_diff_demo/apply_simple_change/prompt.md

@@ -1,13 +0,0 @@
-# Apply Simple Change
-
-Now use the apply_diff function to modify the `hello.txt` file. Let's change the greeting from "Hello World!" to "Hello, Apply Diff Demo!".
-
-Use the apply_diff function with:
-- `file_path`: "hello.txt"
-- `old_content`: "Hello World!"
-- `new_content`: "Hello, Apply Diff Demo!"
-- `description`: "Update greeting to be more specific to the demo"
-
-This will show the user a colored diff of the proposed change and ask for their confirmation before applying it.
-
-After the change is applied (or declined), read the file again to show the final result.

data/examples/apply_diff_demo/create_sample_file/prompt.md

@@ -1,11 +0,0 @@
-# Create Sample File
-
-Create a simple text file called `hello.txt` with the following content:
-
-```
-Hello World!
-This is a demo file.
-We will modify this file in the next step.
-```
-
-Use the write_file function to create this file.

data/examples/apply_diff_demo/workflow.yml

@@ -1,24 +0,0 @@
-# Apply Diff Demo
-#
-# This workflow demonstrates the apply_diff tool which shows users a diff
-# and applies changes based on their confirmation. It's useful for making
-# targeted changes to files with user approval.
-
-name: Apply Diff Demo
-model: gpt-4o-mini
-
-tools:
-  - Roast::Tools::WriteFile
-  - Roast::Tools::ReadFile
-  - Roast::Tools::ApplyDiff
-
-steps:
-  - create_sample_file
-  - apply_simple_change
-
-# Step configurations
-create_sample_file:
-  print_response: false
-
-apply_simple_change:
-  print_response: true

data/examples/bash_prototyping/README.md

@@ -1,53 +0,0 @@
-# Bash Tool Examples
-
-This directory contains example workflows demonstrating the Bash tool, which provides unrestricted command execution for prototyping scenarios.
-
-## ⚠️ Security Warning
-
-The Bash tool executes commands without any restrictions. Only use it in:
-- Development environments
-- Trusted contexts
-- Prototyping scenarios where you explicitly want unrestricted access
-
-**Never use the Bash tool in production workflows or with untrusted input!**
-
-## Examples
-
-### 1. System Analysis Workflow (`system_analysis.yml`)
-
-Demonstrates using Bash for system inspection and analysis tasks that would be restricted by the Cmd tool.
-
-### 2. API Testing Workflow (`api_testing.yml`)
-
-Shows how to use Bash for making API calls with curl and processing responses with jq.
-
-### 3. DevOps Automation (`devops_workflow.yml`)
-
-Example of using Bash for DevOps tasks like container management and log analysis.
-
-## Disabling Warnings
-
-By default, the Bash tool logs warnings about unrestricted execution. To disable these warnings:
-
-```bash
-export ROAST_BASH_WARNINGS=false
-roast execute workflow.yml
-```
-
-## Best Practices
-
-1. **Use Cmd tool when possible**: If your commands fit within Cmd's allowed list, use it instead
-2. **Validate inputs**: Always validate any user input before passing to Bash
-3. **Limit scope**: Use the most restrictive tool that meets your needs
-4. **Document risks**: Clearly document when and why Bash tool is necessary
-5. **Environment isolation**: Run Bash workflows in isolated environments when possible
-
-## Comparison with Cmd Tool
-
-| Feature | Cmd Tool | Bash Tool |
-|---------|----------|-----------|
-| Command restrictions | Yes (configurable) | No |
-| Default allowed commands | pwd, find, ls, rake, ruby, dev, mkdir | All commands |
-| Security warnings | No | Yes (can be disabled) |
-| Recommended for production | Yes | No |
-| Use case | General automation | Prototyping & development |

data/examples/bash_prototyping/analyze_network/prompt.md

@@ -1,13 +0,0 @@
-# Analyze Network Configuration
-
-Use the bash tool to gather network information:
-
-1. Check network interfaces (ifconfig or ip addr)
-2. Display routing table (netstat -nr or ip route)
-3. Check listening ports (netstat -an | grep LISTEN or lsof -i -P | grep LISTEN)
-4. Test DNS resolution (nslookup example.com or dig example.com)
-5. Check current network connections
-
-Provide a summary of the network configuration and any interesting findings.
-
-Note: Some commands may require different syntax on macOS vs Linux.

data/examples/bash_prototyping/analyze_system/prompt.md

@@ -1,11 +0,0 @@
-# Analyze System Information
-
-Use the bash tool to gather system information including:
-
-1. Operating system details (uname -a)
-2. Current disk usage (df -h)
-3. Memory information (if available via free -m on Linux or vm_stat on macOS)
-4. Current user and groups (whoami, groups)
-5. Environment variables (env | grep -E "PATH|HOME|USER")
-
-Gather this information and provide a summary of the system's current state.