roast-ai 0.4.7 → 0.4.8

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.

data/examples/bash_prototyping/api_testing.yml

@@ -1,14 +0,0 @@
-name: API Testing with Bash
-model: gpt-4o-mini
-tools:
-  - Roast::Tools::Bash
-  - Roast::Tools::WriteFile
-
-# Demonstrates using Bash for API testing with curl and jq
-# These commands would be restricted by the Cmd tool
-
-steps:
-  - test_public_api
-  - process_json_response
-  - test_multiple_endpoints
-  - generate_api_report

data/examples/bash_prototyping/check_processes/prompt.md

@@ -1,11 +0,0 @@
-# Check Running Processes
-
-Use the bash tool to analyze running processes:
-
-1. List all processes (ps aux or ps -ef)
-2. Find the top 5 CPU-consuming processes
-3. Find the top 5 memory-consuming processes
-4. Check if any specific development services are running (like databases, web servers)
-5. Count total number of processes
-
-Note: The exact commands may vary between macOS and Linux. Use appropriate commands for the detected OS.

data/examples/bash_prototyping/generate_report/prompt.md

@@ -1,16 +0,0 @@
-# Generate System Analysis Report
-
-Based on all the information gathered in previous steps:
-
-1. Create a comprehensive markdown report summarizing:
-   - System specifications and OS details
-   - Resource usage (CPU, memory, disk)
-   - Active processes and services
-   - Network configuration
-   - Any potential issues or interesting findings
-
-2. Save the report to `system_analysis_report.md` using the write_file tool
-
-3. Include timestamps and organize the information in a clear, readable format
-
-The report should be suitable for sharing with other developers or for documentation purposes.

data/examples/bash_prototyping/process_json_response/prompt.md

@@ -1,24 +0,0 @@
-# Process JSON Responses
-
-Use bash with jq (if available) to process JSON responses:
-
-1. First check if jq is installed:
-   ```bash
-   which jq
-   ```
-
-2. If jq is available, use it to parse JSON:
-   ```bash
-   curl -s https://api.github.com/users/github | jq '.name, .public_repos'
-   ```
-
-3. If jq is not available, use alternative methods like:
-   - grep with regular expressions
-   - sed/awk for parsing
-   - Python one-liners if Python is available
-
-4. Extract specific fields from the API responses
-5. Count items in arrays
-6. Filter data based on conditions
-
-Show different approaches for JSON processing depending on available tools.

data/examples/bash_prototyping/system_analysis.yml

@@ -1,14 +0,0 @@
-name: System Analysis with Bash
-model: gpt-4o-mini
-tools:
-  - Roast::Tools::Bash
-  - Roast::Tools::WriteFile
-
-# This workflow demonstrates using Bash for system analysis tasks
-# that would be restricted by the Cmd tool
-
-steps:
-  - analyze_system
-  - check_processes
-  - analyze_network
-  - generate_report

data/examples/bash_prototyping/test_public_api/prompt.md

@@ -1,22 +0,0 @@
-# Test Public API Endpoints
-
-Use the bash tool to test various public APIs:
-
-1. Test GitHub API:
-   ```bash
-   curl -s https://api.github.com/users/github
-   ```
-
-2. Test a public JSON placeholder API:
-   ```bash
-   curl -s https://jsonplaceholder.typicode.com/posts/1
-   ```
-
-3. Check response headers:
-   ```bash
-   curl -I https://api.github.com
-   ```
-
-4. Test with different HTTP methods if appropriate
-
-Analyze the responses and note the structure of the returned data.

data/examples/case_when/README.md

@@ -1,58 +0,0 @@
-# Case/When/Else Example
-
-This example demonstrates the use of `case/when/else` control flow in Roast workflows.
-
-## Overview
-
-The `case/when/else` construct allows you to execute different steps based on the value of an expression, similar to Ruby's case statement or switch statements in other languages.
-
-## Syntax
-
-```yaml
-- case: <expression>
-  when:
-    <value1>:
-      - <steps>
-    <value2>:
-      - <steps>
-  else:
-    - <steps>
-```
-
-## Features Demonstrated
-
-1. **Basic case/when/else**: Detect file language and execute language-specific analysis
-2. **Bash command evaluation**: Use environment variables to determine deployment strategy
-3. **Complex expressions**: Use Ruby expressions to categorize numeric values
-
-## Expression Types
-
-The `case` expression can be:
-- A simple string value
-- An interpolated workflow output: `{{ workflow.output.variable }}`
-- A Ruby expression: `{{ workflow.output.count > 10 ? 'high' : 'low' }}`
-- A bash command: `$(echo $ENVIRONMENT)`
-- A reference to a previous step's output
-
-## How It Works
-
-1. The `case` expression is evaluated to produce a value
-2. The value is compared against each key in the `when` clause
-3. If a match is found, the steps under that key are executed
-4. If no match is found and an `else` clause exists, those steps are executed
-5. If no match is found and no `else` clause exists, execution continues
-
-## Running the Example
-
-```bash
-roast execute examples/case_when/workflow.yml
-```
-
-This will process all Ruby, JavaScript, Python, and Go files in the current directory, detecting their language and running appropriate analysis steps.
-
-## Use Cases
-
-- **Multi-language projects**: Different linting/testing for different file types
-- **Environment-specific workflows**: Different deployment steps for prod/staging/dev
-- **Conditional processing**: Different handling based on file size, complexity, or other metrics
-- **Error handling**: Different recovery strategies based on error types

data/examples/case_when/detect_language/prompt.md

@@ -1,16 +0,0 @@
-# Detect Programming Language
-
-Based on the file extension and content, determine the primary programming language of this file:
-- If it's a `.rb` file, return "ruby"
-- If it's a `.js` file, return "javascript"
-- If it's a `.py` file, return "python"
-- If it's a `.go` file, return "go"
-- Otherwise, return "unknown"
-
-Return ONLY the language name in lowercase, nothing else.
-
-File: <%= context.resource_uri %>
-Content:
-```
-<%= context.resource %>
-```

data/examples/case_when/workflow.yml

@@ -1,58 +0,0 @@
-name: "Case/When/Else Example"
-
-tools:
-  - Roast::Tools::Cmd
-  - Roast::Tools::ReadFile
-  - Roast::Tools::WriteFile
-
-target: "**/*.{rb,js,py,go}"
-
-steps:
-  - detect_language
-
-  - case: "{{ workflow.output.detect_language }}"
-    when:
-      ruby:
-        - analyze_ruby
-        - generate_ruby_report
-      javascript:
-        - analyze_javascript
-        - generate_js_report
-      python:
-        - analyze_python
-        - generate_python_report
-      go:
-        - analyze_go
-        - generate_go_report
-    else:
-      - analyze_generic
-      - generate_generic_report
-
-  # Another example using bash command for case expression
-  - get_environment: $(echo $ENVIRONMENT || echo "development")
-
-  - case: "{{ workflow.output.get_environment }}"
-    when:
-      production:
-        - production_checks
-        - deploy_production
-      staging:
-        - staging_checks
-        - deploy_staging
-      development:
-        - run_tests
-        - local_deploy
-    else:
-      - unknown_environment
-
-  # Example with numeric case values
-  - count_issues
-
-  - case: "{{ workflow.output.count_issues.to_i > 10 ? 'high' : workflow.output.count_issues.to_i > 5 ? 'medium' : 'low' }}"
-    when:
-      high:
-        - high_priority_alert
-      medium:
-        - medium_priority_notice
-      low:
-        - low_priority_info