creating-workflows

Use this skill when creating automated multi-phase workflows for development tasks using claude-flow orchestration. Implements patterns for implementation kickoff, verification, retry loops, and failure recovery.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "creating-workflows" with this command: npx skills add delorenj/skills/delorenj-skills-creating-workflows

Creating Workflows Skill

Comprehensive guidance for building automated development workflows using claude-flow orchestration, multi-agent coordination, and intelligent verification systems.

When to Use This Skill

This skill should be triggered when:

  • Creating multi-phase development workflows (implementation + verification)
  • Building automated CI/CD pipelines with intelligent agents
  • Implementing retry loops with context injection
  • Setting up verification steps with failure detection
  • Orchestrating multiple agents for parallel/sequential task execution
  • Creating workflows that need checkpoint recovery
  • Implementing silent failure detection (processes that pretend to succeed)
  • Building developer experience tooling with dry-run capabilities
  • Documenting complex automated workflows
  • Migrating manual processes to automated orchestration

Key Concepts

Shell Context Independence & jelmore Execution

Critical Requirement: Workflow scripts must not depend on interactive shell configuration.

Why: Shell aliases and functions don't propagate to subprocess environments (n8n workflows, cron jobs, systemd services).

jelmore: Convention-Based LLM Execution Primitive

jelmore provides a unified CLI for LLM invocations with shell context independence built-in. Use jelmore instead of calling LLM clients directly when building workflows.

Why Use jelmore in Workflows:

  • ✅ Shell-context-free (no alias dependencies)
  • ✅ Convention over configuration (auto-infer client/MCP servers)
  • ✅ Detached Zellij sessions with immediate return
  • ✅ Built-in iMi worktree integration
  • ✅ Native Bloodbank event publishing
  • ✅ Unified interface across all LLM clients

Location: /home/delorenj/code/jelmore

Basic Usage in Workflows:

# Instead of: npx claude-flow@alpha swarm "$objective" --claude
# Use jelmore with auto-inference:
uv run jelmore execute -p "$objective" --auto

# Instead of: gptme --model $KK "$task"
# Use jelmore with explicit client:
uv run jelmore execute -f task.md --client gptme --model-tier balanced

# For PR review workflows:
uv run jelmore execute --config pr-review.json --var PR_NUMBER=$pr_num --json

Implementation Patterns:

  • Place scripts in ~/.local/bin/ with explicit PATH exports
  • Replace aliases with direct command invocations or jelmore CLI
  • Use jelmore for LLM invocations (inherits detached Zellij pattern)
  • Return session identifiers immediately for observability

See:

  • ecosystem-patterns skill - jelmore architecture and patterns
  • bloodbank-n8n-event-driven-workflows skill - Event-driven integration
  • /home/delorenj/code/jelmore/CLI.md - Complete CLI reference

Multi-Phase Workflows

Workflows split into distinct phases with different execution strategies:

  • Phase 1 (Kickoff): Implementation via multi-agent orchestration (parallel execution)
  • Phase 2 (Verification): System state validation (sequential execution)
  • Phase N: Additional phases as needed (testing, deployment, etc.)

Retry Loops with Context Injection

When Phase 2 fails, retry Phase 1 with failure context:

  • Append failure details to context string
  • Increment attempt counter
  • Enforce max retry limit
  • Provide comprehensive failure summary on exhaustion

Silent Failure Detection

Processes that don't properly report errors require explicit monitoring:

  • Log pattern matching (success indicators)
  • Error pattern matching (failure indicators)
  • Timeout enforcement
  • Background process monitoring

Claude-Flow Integration

Critical: claude-flow@alpha v2.7.26+ does NOT support workflow execute command.

Available Commands:

  • swarm <objective> - Multi-agent coordination with parallel execution
  • sparc <mode> - SPARC methodology (spec, architect, tdd, integration)
  • stream-chain - Chain multiple Claude instances with context preservation
  • agent <action> - Agent management (spawn, list, terminate)

Quick Reference

1. Basic Workflow Script Structure

#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
PROJECT_ROOT="$(cd "${SCRIPT_DIR}/../.." && pwd)"

# Colors for output
GREEN='\033[0;32m'
RED='\033[0;31m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'

# Parse CLI arguments
TASK_FILE="${PROJECT_ROOT}/TASK.md"
PHASE="all"
MAX_RETRIES=2
RETRY_ENABLED=true
DRY_RUN=false

# Parse flags (--task, --phase, --max-retries, --no-retry, --dry-run, --help)
# Implement usage() function
# Validate inputs

2. Phase 1: Implementation with jelmore (Recommended)

run_phase1() {
  local attempt=$1
  local context_override="${2:-$CONTEXT}"

  echo -e "${GREEN}Running Phase 1: Implementation${NC}"

  if [[ $attempt -gt 1 ]]; then
    echo -e "${BLUE}Retry attempt $((attempt - 1))/${MAX_RETRIES}${NC}"
  fi

  # jelmore execution with JSON output
  local jelmore_output
  jelmore_output=$(uv run jelmore execute \
    --file "$TASK_FILE" \
    --auto \
    --json 2>&1)

  local exit_code=$?

  # Parse jelmore response
  if [[ $exit_code -eq 0 ]]; then
    local session_name=$(echo "$jelmore_output" | jq -r '.session_name')
    local execution_id=$(echo "$jelmore_output" | jq -r '.execution_id')
    local log_path=$(echo "$jelmore_output" | jq -r '.log_path')

    echo -e "${GREEN}✓ Execution started${NC}"
    echo "  Session: $session_name"
    echo "  Execution ID: $execution_id"
    echo "  Logs: $log_path"
    echo ""
    echo "  Attach: zellij attach $session_name"

    # Store for later reference
    export JELMORE_SESSION="$session_name"
    export JELMORE_EXECUTION_ID="$execution_id"
    export JELMORE_LOG_PATH="$log_path"
  else
    echo -e "${RED}Error: jelmore execution failed${NC}"
    echo "$jelmore_output"
    return 1
  fi

  return 0
}

Alternative: Phase 1 with Claude-Flow Swarm (Legacy Pattern)

run_phase1_legacy() {
  local attempt=$1
  local context_override="${2:-$CONTEXT}"

  echo -e "${GREEN}Running Phase 1: Implementation${NC}"

  if [[ $attempt -gt 1 ]]; then
    echo -e "${BLUE}Retry attempt $((attempt - 1))/${MAX_RETRIES}${NC}"
  fi

  # Read task content
  local task_content
  if [[ -f "$TASK_FILE" ]]; then
    task_content=$(cat "$TASK_FILE")
  else
    echo -e "${RED}Error: Task file not found: $TASK_FILE${NC}"
    return 1
  fi

  # Build objective with context
  local objective="$task_content"
  if [[ -n "$context_override" ]]; then
    objective="$objective\n\nAdditional Context: $context_override"
  fi

  # Execute swarm (opens Claude Code CLI)
  npx claude-flow@alpha swarm "$objective" \
    --strategy development \
    --parallel \
    --max-agents 5 \
    --claude

  return $?
}

3. Phase 2: Verification with Silent Failure Detection

run_phase2() {
  echo -e "${GREEN}Running Phase 2: Verification${NC}"
  local phase2_failed=false

  # Step 1: Backend startup with log monitoring
  echo -e "${BLUE}[Step 1/N] Starting backend...${NC}"

  # Start process in background
  your_start_command > /tmp/backend.log 2>&1 &
  local backend_pid=$!

  # Watch logs for success indicator (30s timeout)
  local timeout=30
  local elapsed=0
  local backend_started=false

  while [[ $elapsed -lt $timeout ]]; do
    # Check for success pattern
    if grep -q "SUCCESS_PATTERN" /tmp/backend.log 2>/dev/null; then
      backend_started=true
      echo -e "${GREEN}✓ Backend started${NC}"
      break
    fi

    # Check for error patterns
    if grep -qi "error\|failed" /tmp/backend.log 2>/dev/null; then
      echo -e "${RED}✗ Backend errors detected${NC}"
      cat /tmp/backend.log
      phase2_failed=true
      break
    fi

    sleep 1
    elapsed=$((elapsed + 1))
  done

  if [[ "$backend_started" == "false" && "$phase2_failed" == "false" ]]; then
    echo -e "${RED}✗ Backend startup timed out${NC}"
    cat /tmp/backend.log
    phase2_failed=true
  fi

  if [[ "$phase2_failed" == "true" ]]; then
    return 1
  fi

  # Step 2: Additional verification steps
  # ...

  echo -e "${GREEN}✓ Phase 2 complete${NC}"
  return 0
}

4. Retry Loop Implementation

case "$PHASE" in
  all|*)
    ATTEMPT=1
    PHASE1_SUCCESS=false
    PHASE2_SUCCESS=false

    while [[ $ATTEMPT -le $((MAX_RETRIES + 1)) ]]; do
      echo -e "${YELLOW}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"
      echo -e "${YELLOW}Workflow Attempt ${ATTEMPT}/$((MAX_RETRIES + 1))${NC}"
      echo -e "${YELLOW}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"

      # Phase 1 with retry context
      RETRY_CONTEXT="$CONTEXT"
      if [[ $ATTEMPT -gt 1 ]]; then
        RETRY_CONTEXT="$CONTEXT | RETRY: Previous Phase 2 verification failed. Review logs and address failures."
      fi

      run_phase1 $ATTEMPT "$RETRY_CONTEXT"
      PHASE1_EXIT=$?

      if [[ $PHASE1_EXIT -ne 0 ]]; then
        echo -e "${RED}Phase 1 failed with exit code $PHASE1_EXIT${NC}"

        if [[ "$RETRY_ENABLED" == "false" || $ATTEMPT -gt $MAX_RETRIES ]]; then
          echo -e "${RED}No more retries. Exiting.${NC}"
          exit $PHASE1_EXIT
        fi

        ATTEMPT=$((ATTEMPT + 1))
        continue
      fi

      PHASE1_SUCCESS=true
      echo -e "${GREEN}✓ Phase 1 completed${NC}"

      # Phase 2
      run_phase2
      PHASE2_EXIT=$?

      if [[ $PHASE2_EXIT -ne 0 ]]; then
        if [[ $ATTEMPT -ge $((MAX_RETRIES + 1)) ]]; then
          # Exhausted retries - provide guidance
          echo -e "${YELLOW}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"
          echo -e "${YELLOW}Retry Summary:${NC}"
          echo "  Total attempts: $ATTEMPT"
          echo "  Phase 1: ${GREEN}✓ Success${NC}"
          echo "  Phase 2: ${RED}✗ Failed${NC}"
          echo -e "${BLUE}Next steps:${NC}"
          echo "  1. Review Phase 2 logs"
          echo "  2. Manually investigate failures"
          echo "  3. Run Phase 2 only: $0 --phase 2"
          echo "  4. Increase retries: $0 --max-retries 5"
          exit $PHASE2_EXIT
        fi

        echo -e "${BLUE}Phase 2 Failed - Triggering Retry${NC}"
        echo -e "${YELLOW}Looping back to Phase 1 with failure context...${NC}"
        ATTEMPT=$((ATTEMPT + 1))
        sleep 2
        continue
      fi

      # Success
      PHASE2_SUCCESS=true
      break
    done

    # Final status
    if [[ "$PHASE1_SUCCESS" == "true" && "$PHASE2_SUCCESS" == "true" ]]; then
      echo -e "${GREEN}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"
      echo -e "${GREEN}✅ Workflow completed successfully${NC}"
      echo -e "${GREEN}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"

      if [[ $ATTEMPT -gt 1 ]]; then
        echo -e "${BLUE}Success after $((ATTEMPT - 1)) retry attempt(s)${NC}"
      fi

      exit 0
    fi
    ;;
esac

5. Dry-Run Mode

if [[ "$DRY_RUN" == "true" ]]; then
  echo -e "${YELLOW}DRY RUN MODE${NC}"
  echo "Would execute Phase 1:"
  echo "  npx claude-flow@alpha swarm \"\$(cat $TASK_FILE)\" \\"
  echo "    --strategy development \\"
  echo "    --parallel \\"
  echo "    --max-agents 5 \\"
  echo "    --claude"
  echo ""
  echo "Would execute Phase 2:"
  echo "  1. Start backend (with log monitoring)"
  echo "  2. Build artifacts"
  echo "  3. Run verification checks"

  if [[ "$RETRY_ENABLED" == "true" ]]; then
    echo ""
    echo "Retry loop: Phase 2 failures retry Phase 1 (max $MAX_RETRIES attempts)"
  fi

  exit 0
fi

Common Patterns

Pattern 1: Backend/Service Startup Monitoring

Problem: Process managers (mise, pm2, etc.) often return success even when compilation fails.

Solution: Monitor logs for explicit success indicators.

# Start process
mise start > /tmp/service.log 2>&1 &

# Monitor for success pattern
while [[ $elapsed -lt $timeout ]]; do
  if grep -q "Accepted new IPC connection" /tmp/service.log; then
    echo "✓ Service started"
    break
  fi

  if grep -qi "error|compilation failed" /tmp/service.log; then
    echo "✗ Service failed"
    cat /tmp/service.log
    exit 1
  fi

  sleep 1
  elapsed=$((elapsed + 1))
done

Pattern 2: File Validation After Build

Problem: Builds may appear successful but produce incomplete artifacts.

Solution: Explicitly verify required files exist.

required_files=(
  "dist/manifest.json"
  "dist/bundle.js"
  "dist/styles.css"
)

for file in "${required_files[@]}"; do
  if [[ ! -f "$file" ]]; then
    echo "✗ Required file missing: $file"
    exit 1
  fi
done

echo "✓ All artifacts present"

Pattern 3: Manual Verification Prompts

Problem: Some verification steps can't be automated (UI testing, Chrome extension reload).

Solution: Provide clear instructions and wait for confirmation.

echo -e "${BLUE}[Step N/N] Manual Verification Required${NC}"
echo -e "${YELLOW}Please complete these steps:${NC}"
echo "  1. Open chrome://extensions"
echo "  2. Enable 'Developer mode'"
echo "  3. Find extension and click 'Reload'"
echo "  4. Test on target page"
echo ""
echo -e "${YELLOW}Press Enter when complete, or Ctrl+C to abort...${NC}"
read -r

echo -e "${GREEN}✓ Manual verification complete${NC}"

Pattern 4: Context Injection on Retry

Problem: Retries without context repeat the same mistakes.

Solution: Append failure information to task context.

RETRY_CONTEXT="$CONTEXT"
if [[ $ATTEMPT -gt 1 ]]; then
  RETRY_CONTEXT="$CONTEXT | RETRY: Previous Phase 2 verification failed. Specific failure: $FAILURE_REASON. Review verification logs at $LOG_PATH and address these issues."
fi

run_phase1 $ATTEMPT "$RETRY_CONTEXT"

Pattern 5: Comprehensive Error Reporting

Problem: Failures without guidance leave users stuck.

Solution: Provide actionable next steps on failure.

if [[ $MAX_RETRIES_EXHAUSTED == true ]]; then
  echo -e "${YELLOW}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"
  echo -e "${YELLOW}Retry Summary:${NC}"
  echo "  Total attempts: $ATTEMPT"
  echo "  Phase 1 status: ${GREEN}✓ Success${NC}"
  echo "  Phase 2 status: ${RED}✗ Failed${NC}"
  echo ""
  echo -e "${BLUE}Next steps:${NC}"
  echo "  1. Review Phase 2 logs in $LOG_DIR"
  echo "  2. Check backend/service status: ps aux | grep service"
  echo "  3. Run Phase 2 only: $0 --phase 2"
  echo "  4. Increase retries: $0 --max-retries 5"
  echo "  5. Contact team if issue persists: #dev-support"
fi

Documentation Patterns

1. Workflow Overview Document

Create a comprehensive markdown document (e.g., workflow-name.md) with:

  • Purpose: What the workflow does
  • Phases: Detailed breakdown of each phase
  • Trigger: How to invoke the workflow
  • Inputs: Required parameters and files
  • Outputs: Generated artifacts and reports
  • Success Criteria: How to verify completion
  • Failure Recovery: Common issues and solutions
  • Manual Steps: Any non-automated requirements

2. Quick Reference Cheat Sheet

Create a concise one-page reference (e.g., QUICK-REFERENCE.md) with:

  • Common commands (full workflow, individual phases, dry-run)
  • CLI flags and options
  • Output file locations
  • Troubleshooting commands
  • Emergency procedures

3. README for Workflows Directory

Create README.md in workflows directory with:

  • List of all available workflows
  • When to use each workflow
  • Quick start examples
  • Common configuration options
  • Links to detailed documentation

4. Implementation Report Template

After execution, generate report with:

  • Workflow name and version
  • Execution timestamp
  • All phases executed with status
  • Retry attempts (if any)
  • Generated artifacts with paths
  • Performance metrics (execution time, agent utilization)
  • Next steps or recommendations

CLI Argument Patterns

Standard Flags

-t, --task FILE         Task specification file (default: TASK.md)
-c, --context STRING    Additional context for requirements
-p, --phase PHASE       Run specific phase only (1, 2, etc.)
-s, --skip-verification Skip Phase N verification
-r, --max-retries N     Max retry attempts on failure (default: 2)
--no-retry              Disable retry loop (fail immediately)
-d, --dry-run          Show what would be executed
-h, --help             Show help message

Usage Function Template

usage() {
  cat <<EOF
Usage: $0 [options]

Execute the ${WORKFLOW_NAME} workflow

Phases:
  Phase 1: ${PHASE1_DESCRIPTION}
  Phase 2: ${PHASE2_DESCRIPTION}

Options:
  -t, --task FILE         Task specification file (default: TASK.md)
  -c, --context STRING    Additional context
  -p, --phase PHASE       Run specific phase (1 or 2)
  -r, --max-retries N     Max retries (default: 2)
  --no-retry              Disable retry loop
  -d, --dry-run          Preview without execution
  -h, --help             Show this message

Examples:
  # Full workflow with retry
  $0 --task TASK.md

  # Phase 1 only
  $0 --task TASK.md --phase 1

  # Disable retry
  $0 --task TASK.md --no-retry

  # Preview execution
  $0 --task TASK.md --dry-run

EOF
  exit 1
}

Testing Strategies

1. Dry-Run Testing

Always implement and test dry-run mode:

./workflow-script.sh --dry-run
# Should show commands without executing
# Verify output matches expected execution plan

2. Individual Phase Testing

Test each phase independently:

# Test Phase 1 in isolation
./workflow-script.sh --task TASK.md --phase 1

# Test Phase 2 in isolation (requires Phase 1 artifacts)
./workflow-script.sh --phase 2

3. Retry Loop Testing

Test retry behavior with intentional failures:

# Modify Phase 2 to fail temporarily
# Run full workflow
./workflow-script.sh --task TASK.md

# Verify:
# - Phase 1 executes
# - Phase 2 fails
# - Phase 1 re-executes with failure context
# - Loop continues until max retries
# - Comprehensive failure summary appears

4. Silent Failure Detection Testing

Test failure detection:

# Modify backend to fail compilation
# Run workflow
./workflow-script.sh --task TASK.md --phase 2

# Verify:
# - Detects compilation errors in logs
# - Fails with clear error message
# - Shows relevant log excerpts

Integration with Claude-Flow

Swarm Command

Best for: Multi-agent implementation workflows

npx claude-flow@alpha swarm "$objective" \
  --strategy development \        # Options: research, development, testing, optimization
  --parallel \                    # Enable parallel execution (2.8-4.4x speedup)
  --max-agents 5 \               # Limit concurrent agents
  --claude                        # Open Claude Code CLI (default: built-in executor)

SPARC Command

Best for: Structured development phases (spec, architect, tdd)

npx claude-flow@alpha sparc spec "$task"     # Requirements analysis
npx claude-flow@alpha sparc architect "$task" # System design
npx claude-flow@alpha sparc tdd "$task"      # Test-driven implementation

Stream-Chain Command

Best for: Sequential workflows with context preservation

npx claude-flow@alpha stream-chain run \
  "analyze requirements" \
  "design architecture" \
  "implement solution"

Reference Files

This skill includes comprehensive documentation in references/:

  • workflow-script-template.sh - Complete bash script template with all patterns
  • phase-patterns.md - Common Phase 1/2/N implementation patterns
  • retry-strategies.md - Retry loop configurations and failure handling
  • verification-patterns.md - Silent failure detection and validation strategies
  • documentation-templates.md - Markdown templates for workflow docs
  • cli-design.md - CLI argument parsing and usage function patterns

Use these references when building new workflows.

Working with This Skill

For Beginners

Start with the template:

  1. Copy workflow-script-template.sh from assets/
  2. Customize Phase 1 (implementation) with your task
  3. Customize Phase 2 (verification) with your checks
  4. Test with --dry-run first
  5. Run individual phases before full workflow

For Intermediate Users

Implement patterns:

  • Add retry loop with context injection
  • Implement silent failure detection for your tools
  • Add manual verification prompts where needed
  • Create comprehensive documentation

For Advanced Users

Optimize and extend:

  • Add additional phases (testing, deployment, rollback)
  • Implement checkpoint recovery between phases
  • Add performance metrics collection
  • Create reusable verification modules
  • Integrate with CI/CD pipelines

Common Pitfalls

Pitfall 1: Using Non-Existent CLI Commands

Problem: Documentation may reference commands that don't exist in your version.

Solution: Always verify with --help:

npx claude-flow@alpha --help
npx claude-flow@alpha swarm --help

Pitfall 2: Missing Failure Detection

Problem: Process returns success but actually failed.

Solution: Never trust exit codes alone. Monitor logs for explicit success patterns.

Pitfall 3: Retrying Without Context

Problem: Retries repeat identical failures.

Solution: Always inject failure context into retry attempts.

Pitfall 4: Poor Error Messages

Problem: Users don't know what to do when workflow fails.

Solution: Provide specific next steps, log locations, and troubleshooting commands.

Pitfall 5: No Dry-Run Mode

Problem: Can't preview workflow without executing.

Solution: Always implement --dry-run mode that shows commands without running them.

Resources

In This Skill

  • references/ - Detailed pattern documentation
  • assets/ - Templates and examples
  • scripts/ - Helper utilities

External

Notes

  • This skill codifies patterns from real workflow implementations
  • Always test dry-run mode before production use
  • Retry loops should have reasonable limits (2-5 attempts max)
  • Silent failure detection is critical for reliable automation
  • Documentation is as important as the workflow itself

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

zellij-plugin-dev

No summary provided by upstream source.

Repository SourceNeeds Review
General

agno

No summary provided by upstream source.

Repository SourceNeeds Review
General

fal-text-to-image

No summary provided by upstream source.

Repository SourceNeeds Review