Add npm version badge to README

- Replace "comprehensive" and other marketing terms with plain language
- Shorten overly detailed HTTP request documentation
- Simplify import structure and data resolution sections
- Remove verbose environment variables explanations
- Cut scheduled workflows examples to essential information
- Make language more direct and honest about development status

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

.github/workflows/claude-code-review.yml

@@ -1,78 +0,0 @@
-name: Claude Code Review
-
-on:
-  pull_request:
-    types: [opened, synchronize]
-    # Optional: Only run on specific file changes
-    # paths:
-    #   - "src/**/*.ts"
-    #   - "src/**/*.tsx"
-    #   - "src/**/*.js"
-    #   - "src/**/*.jsx"
-
-jobs:
-  claude-review:
-    # Optional: Filter by PR author
-    # if: |
-    #   github.event.pull_request.user.login == 'external-contributor' ||
-    #   github.event.pull_request.user.login == 'new-developer' ||
-    #   github.event.pull_request.author_association == 'FIRST_TIME_CONTRIBUTOR'
-    
-    runs-on: ubuntu-latest
-    permissions:
-      contents: read
-      pull-requests: read
-      issues: read
-      id-token: write
-    
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 1
-
-      - name: Run Claude Code Review
-        id: claude-review
-        uses: anthropics/claude-code-action@beta
-        with:
-          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
-
-          # Optional: Specify model (defaults to Claude Sonnet 4, uncomment for Claude Opus 4.1)
-          # model: "claude-opus-4-1-20250805"
-
-          # Direct prompt for automated review (no @claude mention needed)
-          direct_prompt: |
-            Please review this pull request and provide feedback on:
-            - Code quality and best practices
-            - Potential bugs or issues
-            - Performance considerations
-            - Security concerns
-            - Test coverage
-            
-            Be constructive and helpful in your feedback.
-
-          # Optional: Use sticky comments to make Claude reuse the same comment on subsequent pushes to the same PR
-          # use_sticky_comment: true
-          
-          # Optional: Customize review based on file types
-          # direct_prompt: |
-          #   Review this PR focusing on:
-          #   - For TypeScript files: Type safety and proper interface usage
-          #   - For API endpoints: Security, input validation, and error handling
-          #   - For React components: Performance, accessibility, and best practices
-          #   - For tests: Coverage, edge cases, and test quality
-          
-          # Optional: Different prompts for different authors
-          # direct_prompt: |
-          #   ${{ github.event.pull_request.author_association == 'FIRST_TIME_CONTRIBUTOR' && 
-          #   'Welcome! Please review this PR from a first-time contributor. Be encouraging and provide detailed explanations for any suggestions.' ||
-          #   'Please provide a thorough code review focusing on our coding standards and best practices.' }}
-          
-          # Optional: Add specific tools for running tests or linting
-          # allowed_tools: "Bash(npm run test),Bash(npm run lint),Bash(npm run typecheck)"
-          
-          # Optional: Skip review for certain conditions
-          # if: |
-          #   !contains(github.event.pull_request.title, '[skip-review]') &&
-          #   !contains(github.event.pull_request.title, '[WIP]')
-

.github/workflows/claude.yml

@@ -1,64 +0,0 @@
-name: Claude Code
-
-on:
-  issue_comment:
-    types: [created]
-  pull_request_review_comment:
-    types: [created]
-  issues:
-    types: [opened, assigned]
-  pull_request_review:
-    types: [submitted]
-
-jobs:
-  claude:
-    if: |
-      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
-      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
-      (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
-      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
-    runs-on: ubuntu-latest
-    permissions:
-      contents: read
-      pull-requests: read
-      issues: read
-      id-token: write
-      actions: read # Required for Claude to read CI results on PRs
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 1
-
-      - name: Run Claude Code
-        id: claude
-        uses: anthropics/claude-code-action@beta
-        with:
-          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
-
-          # This is an optional setting that allows Claude to read CI results on PRs
-          additional_permissions: |
-            actions: read
-          
-          # Optional: Specify model (defaults to Claude Sonnet 4, uncomment for Claude Opus 4.1)
-          # model: "claude-opus-4-1-20250805"
-          
-          # Optional: Customize the trigger phrase (default: @claude)
-          # trigger_phrase: "/claude"
-          
-          # Optional: Trigger when specific user is assigned to an issue
-          # assignee_trigger: "claude-bot"
-          
-          # Optional: Allow Claude to run specific commands
-          # allowed_tools: "Bash(npm install),Bash(npm run build),Bash(npm run test:*),Bash(npm run lint:*)"
-          
-          # Optional: Add custom instructions for Claude to customize its behavior for your project
-          # custom_instructions: |
-          #   Follow our coding standards
-          #   Ensure all new code has tests
-          #   Use TypeScript for new files
-          
-          # Optional: Custom environment variables for Claude
-          # claude_env: |
-          #   NODE_ENV: test
-

README.md

@@ -1,18 +1,19 @@
 # @xtr-dev/payload-automation
 
-A comprehensive workflow automation plugin for PayloadCMS 3.x that enables visual workflow building, execution tracking, and parallel processing.
+[![npm version](https://badge.fury.io/js/@xtr-dev%2Fpayload-automation.svg)](https://www.npmjs.com/package/@xtr-dev/payload-automation)
+
+A workflow automation plugin for PayloadCMS 3.x. Run steps in workflows triggered by document changes or webhooks.
 
 ⚠️ **Pre-release Warning**: This package is currently in active development (v0.0.x). Breaking changes may occur before v1.0.0. Not recommended for production use.
 
 ## Features
 
-- 🔄 **Visual Workflow Builder** - Create complex workflows with drag-and-drop interface
+- 🔄 Visual workflow builder in PayloadCMS admin
-- ⚡ **Parallel Execution** - Smart dependency resolution for optimal performance
+- ⚡ Run workflows when documents are created/updated/deleted
-- 🎯 **Multiple Triggers** - Collection hooks, webhooks, manual execution
+- 🎯 Trigger workflows via webhooks
-- ⏰ **Scheduled Workflows** - Use webhook triggers with external cron services
+- 📊 Track workflow execution history
-- 📊 **Execution Tracking** - Complete history and monitoring of workflow runs
+- 🔧 HTTP requests, document operations, email sending
-- 🔧 **Extensible Steps** - HTTP requests, document CRUD, email notifications
+- 🔗 Use data from previous steps in templates
-- 🔧 **Handlebars Templates** - Dynamic data interpolation with automatic type conversion
 
 ## Installation
 
@@ -47,94 +48,25 @@ export default buildConfig({
 })
 ```
 
-## Import Structure
+## Imports
-
-The plugin uses separate exports to avoid bundling server-side code in client bundles:
 
 ```typescript
-// Server-side plugin and functions
+// Server plugin
 import { workflowsPlugin } from '@xtr-dev/payload-automation/server'
 
-// Client-side components  
+// Client components  
 import { StatusCell, ErrorDisplay } from '@xtr-dev/payload-automation/client'
 
-// Helper utilities
+// Types
-import { /* helpers */ } from '@xtr-dev/payload-automation/helpers'
-
-// Types only (safe for both server and client)
 import type { WorkflowsPluginConfig } from '@xtr-dev/payload-automation'
 ```
 
 ## Step Types
 
 ### HTTP Request
-Make external API calls with comprehensive error handling and retry logic.
+Call external APIs. Supports GET, POST, PUT, DELETE, PATCH. Uses Bearer tokens, API keys, or basic auth.
 
-**Key Features:**
+HTTP steps succeed even with 4xx/5xx status codes. Only network errors (timeouts, DNS failures) cause step failure. Check `{{steps.stepName.output.status}}` for error handling.
-- Support for GET, POST, PUT, DELETE, PATCH methods
-- Authentication: Bearer token, Basic auth, API key headers
-- Configurable timeouts and retry logic
-- Handlebars templates for dynamic URLs and request bodies
-
-**Error Handling:**
-HTTP Request steps use a **response-based success model** rather than status-code-based failures:
-
-- ✅ **Successful completion**: All HTTP requests that receive a response (including 4xx/5xx status codes) are marked as "succeeded"
-- ❌ **Failed execution**: Only network errors, timeouts, DNS failures, and connection issues cause step failure
-- 📊 **Error information preserved**: HTTP error status codes (404, 500, etc.) are captured in the step output for workflow conditional logic
-
-**Example workflow logic:**
-```typescript
-// Step outputs for a 404 response:
-{
-  "status": 404,
-  "statusText": "Not Found", 
-  "body": "Resource not found",
-  "headers": {...},
-  "duration": 1200
-}
-
-// Use in workflow conditions:
-// "{{steps.apiRequest.output.status}} >= 400" to handle errors
-```
-
-This design allows workflows to handle HTTP errors gracefully rather than failing completely, enabling robust error handling and retry logic.
-
-**Enhanced Error Tracking:**
-For network failures (timeouts, DNS errors, connection failures), the plugin provides detailed error information through an independent storage system that bypasses PayloadCMS's output limitations:
-
-```typescript
-// Timeout error details preserved in workflow context:
-{
-  "steps": {
-    "httpStep": {
-      "state": "failed",
-      "error": "Task handler returned a failed state",
-      "errorDetails": {
-        "errorType": "timeout",
-        "duration": 2006,
-        "attempts": 1,
-        "finalError": "Request timeout after 2000ms",
-        "context": {
-          "url": "https://api.example.com/data",
-          "method": "GET",
-          "timeout": 2000
-        }
-      },
-      "executionInfo": {
-        "completed": true,
-        "success": false,
-        "executedAt": "2025-09-04T15:16:10.000Z",
-        "duration": 2006
-      }
-    }
-  }
-}
-
-// Access in workflow conditions:
-// "{{steps.httpStep.errorDetails.errorType}} == 'timeout'"
-// "{{steps.httpStep.errorDetails.duration}} > 5000"
-```
 
 ### Document Operations
 - **Create Document** - Create PayloadCMS documents
@@ -145,38 +77,17 @@ For network failures (timeouts, DNS errors, connection failures), the plugin pro
 ### Communication
 - **Send Email** - Send notifications via PayloadCMS email
 
-## Data Resolution
+## Templates
 
-Use Handlebars templates to access workflow data:
+Use `{{}}` to insert data:
 
-- `{{trigger.doc.id}}` - Access trigger document
+- `{{trigger.doc.id}}` - Data from the document that triggered the workflow  
-- `{{steps.stepName.output}}` - Use previous step outputs
+- `{{steps.stepName.output}}` - Data from previous steps
-- `{{context}}` - Access workflow context
-
-### Template Examples
 
+Example:
 ```json
 {
   "url": "https://api.example.com/posts/{{steps.createPost.output.id}}",
-  "message": "Post {{trigger.doc.title}} was updated by {{trigger.req.user.email}}",
-  "timeout": "{{steps.configStep.output.timeoutMs}}"
-}
-```
-
-### Automatic Type Conversion
-
-Handlebars templates automatically convert string results to appropriate types based on field names:
-
-- **Numbers**: `timeout`, `retries`, `delay`, `port`, `count`, etc. → converted to numbers
-- **Booleans**: `enabled`, `active`, `success`, `complete`, etc. → converted to booleans  
-- **Numeric strings**: `"5000"` → `5000`, `"3.14"` → `3.14`
-
-### Conditions
-
-Conditions support Handlebars templates with comparison operators:
-
-```json
-{
   "condition": "{{trigger.doc.status}} == 'published'"
 }
 ```
@@ -187,71 +98,25 @@ Conditions support Handlebars templates with comparison operators:
 - Node.js ^18.20.2 || >=20.9.0
 - pnpm ^9 || ^10
 
-## Environment Variables
+## Logging
 
-Control plugin logging with these environment variables:
+Set `PAYLOAD_AUTOMATION_LOG_LEVEL` to control logs:
+- `silent`, `error`, `warn` (default), `info`, `debug`, `trace`
 
-### `PAYLOAD_AUTOMATION_LOG_LEVEL`
-Controls both configuration-time and runtime logging. 
-- **Values**: `silent`, `error`, `warn`, `info`, `debug`, `trace`
-- **Default**: `warn`
-- **Example**: `PAYLOAD_AUTOMATION_LOG_LEVEL=debug`
-
-### `PAYLOAD_AUTOMATION_CONFIG_LOG_LEVEL` (optional)
-Override log level specifically for configuration-time logs (plugin setup).
-- **Values**: Same as above
-- **Default**: Falls back to `PAYLOAD_AUTOMATION_LOG_LEVEL` or `warn`
-- **Example**: `PAYLOAD_AUTOMATION_CONFIG_LOG_LEVEL=silent`
-
-### Production Usage
-For production, keep the default (`warn`) or use `error` or `silent`:
-```bash
-PAYLOAD_AUTOMATION_LOG_LEVEL=error npm start
-```
-
-### Development Usage
-For debugging, use `debug` or `info`:
 ```bash
 PAYLOAD_AUTOMATION_LOG_LEVEL=debug npm run dev
 ```
 
 ## Scheduled Workflows
 
-For scheduled workflows, use **webhook triggers** with external cron services instead of built-in cron triggers:
+Use webhook triggers with external cron services:
 
-### GitHub Actions (Free)
+```bash
-```yaml
+# Call workflow webhook from cron
-# .github/workflows/daily-report.yml
+curl -X POST https://your-app.com/api/workflows-webhook/daily-report
-on:
-  schedule:
-    - cron: '0 9 * * *'  # Daily at 9 AM UTC
-jobs:
-  trigger-workflow:
-    runs-on: ubuntu-latest
-    steps:
-      - run: curl -X POST https://your-app.com/api/workflows-webhook/daily-report
 ```
 
-### Vercel Cron (Serverless)
+Built-in cron triggers were removed in v0.0.37+.
-```js
-// api/cron/daily.js
-export default async function handler(req, res) {
-  await fetch('https://your-app.com/api/workflows-webhook/daily-report', {
-    method: 'POST',
-    headers: { 'Content-Type': 'application/json' },
-    body: JSON.stringify({ source: 'vercel-cron' })
-  });
-  res.status(200).json({ success: true });
-}
-```
-
-**Benefits**: Better reliability, proper process isolation, easier debugging, and leverages existing infrastructure.
-
-**Note**: Built-in cron triggers have been removed in v0.0.37+ to focus on webhook-based scheduling which provides better reliability and debugging capabilities.
-
-## Documentation
-
-Full documentation coming soon. For now, explore the development environment in the repository for examples and patterns.
 
 ## License