Skip to content

Instantly share code, notes, and snippets.

@jschuller
Forked from ruvnet/*claude.md
Created June 8, 2025 18:45
Show Gist options
  • Save jschuller/2b9f8d07133ce8a86db67a6708713866 to your computer and use it in GitHub Desktop.
Save jschuller/2b9f8d07133ce8a86db67a6708713866 to your computer and use it in GitHub Desktop.

Revisions

  1. @ruvnet ruvnet revised this gist Jun 8, 2025. 1 changed file with 51 additions and 41 deletions.
    92 changes: 51 additions & 41 deletions optional-coordination-system.md
    Original file line number Diff line number Diff line change
    @@ -1,69 +1,79 @@
    # Multi-Agent Development Coordination Guide

    ## Overview
    This coordination system enables multiple AI agents to collaborate effectively on the steganography framework improvements.

    This guide outlines how to coordinate autonomous or semi-autonomous agents working collaboratively on a shared project.

    ## Directory Structure

    ```
    coordination/
    ├── COORDINATION_GUIDE.md # This file - main coordination guide
    ├── memory_bank/ # Shared knowledge and discoveries
    │ ├── calibration_values.md # Discovered optimal signal parameters
    │ ├── test_failures.md # Analysis of failing tests
    │ └── dependencies.md # Environment setup knowledge
    ├── subtasks/ # Individual task breakdowns
    │ ├── task_001_calibration.md # Signal calibration subtasks
    │ ├── task_002_ffmpeg.md # FFmpeg installation subtasks
    │ └── task_003_optimization.md # Algorithm optimization subtasks
    └── orchestration/ # Agent coordination
    ├── agent_assignments.md # Who's working on what
    ├── progress_tracker.md # Real-time progress updates
    └── integration_plan.md # How pieces fit together
    ├── COORDINATION_GUIDE.md # This file main coordination reference
    ├── memory_bank/ # Shared context, insights, and findings
    │ ├── calibration_values.md # Tuned parameters or heuristics
    │ ├── test_failures.md # Known issues and failed experiments
    │ └── dependencies.md # Environment setup notes
    ├── subtasks/ # Decomposed work items
    │ ├── task_001_component.md # Component-specific task
    │ ├── task_002_setup.md # Setup or installation task
    │ └── task_003_optimization.md # Performance or logic improvements
    └── orchestration/ # Collaboration management
    ├── agent_assignments.md # Active task ownership
    ├── progress_tracker.md # Timeline and completion status
    └── integration_plan.md # System-wide connection strategy
    ```

    ## Coordination Protocol

    ### 1. Task Assignment
    - Check `orchestration/agent_assignments.md` before starting work
    - Update with your agent ID and current task
    - Avoid duplicate efforts by coordinating through this file

    * Check `orchestration/agent_assignments.md` before starting
    * Claim your task by logging your agent ID
    * Avoid overlap through transparent ownership

    ### 2. Knowledge Sharing
    - Document all discoveries in `memory_bank/`
    - Include failed attempts to prevent repetition
    - Share optimal parameters immediately upon discovery

    * Log all useful discoveries in `memory_bank/`
    * Include failed attempts to reduce redundancy
    * Share tuning parameters and workarounds promptly

    ### 3. Progress Updates
    - Update `orchestration/progress_tracker.md` every significant step
    - Mark subtasks complete in respective `subtasks/` files
    - Alert other agents of blockers or dependencies

    * Record progress in `orchestration/progress_tracker.md`
    * Mark completed subtasks inside `subtasks/` files
    * Note blockers or required inputs from other agents

    ### 4. Integration Points
    - Follow the plan in `orchestration/integration_plan.md`
    - Test integrations incrementally
    - Document any API or interface changes

    * Follow `orchestration/integration_plan.md` for assembly
    * Test partial integrations regularly
    * Log interface contracts and assumptions

    ## Communication Standards

    ### Status Markers
    - 🟢 COMPLETE - Task finished and tested
    - 🟡 IN_PROGRESS - Currently being worked on
    - 🔴 BLOCKED - Waiting on dependency or issue
    - ⚪ TODO - Not yet started
    - 🔵 REVIEW - Needs peer review

    * 🟢 COMPLETE – Task finished and verified
    * 🟡 IN\_PROGRESS – Actively being worked on
    * 🔴 BLOCKED – Dependent or paused
    * ⚪ TODO – Unclaimed or unstarted
    * 🔵 REVIEW – Awaiting validation

    ### Update Format

    ```markdown
    ## [Timestamp] Agent: [Agent_ID]
    **Task**: [Brief description]
    **Status**: [Status marker]
    **Details**: [What was done/discovered]
    **Next**: [What needs to happen next]
    ## [Timestamp] Agent: [Agent_ID]
    **Task**: [Brief summary]
    **Status**: [Status marker]
    **Details**: [Progress, issues, discoveries]
    **Next**: [Planned follow-up action]
    ```

    ## Critical Rules
    1. **No Parallel Work** on same file without coordination
    2. **Test Before Commit** - Run relevant tests before marking complete
    3. **Document Failures** - Failed approaches are valuable knowledge
    4. **Share Parameters** - Any calibration values found must be shared immediately
    5. **Atomic Changes** - Make small, focused changes that can be tested independently

    1. **No Uncoordinated Edits** – Avoid editing shared files without claiming
    2. **Always Test Before Completion** – Validate outputs before status updates
    3. **Log All Failures** – Negative results are part of the process
    4. **Share Tunings and Fixes** – Parameters, configs, and tricks belong in memory\_bank
    5. **Commit in Small Units** – Make atomic, reversible changes

  2. @ruvnet ruvnet revised this gist Jun 8, 2025. 1 changed file with 69 additions and 0 deletions.
    69 changes: 69 additions & 0 deletions optional-coordination-system.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,69 @@
    # Multi-Agent Development Coordination Guide

    ## Overview
    This coordination system enables multiple AI agents to collaborate effectively on the steganography framework improvements.

    ## Directory Structure
    ```
    coordination/
    ├── COORDINATION_GUIDE.md # This file - main coordination guide
    ├── memory_bank/ # Shared knowledge and discoveries
    │ ├── calibration_values.md # Discovered optimal signal parameters
    │ ├── test_failures.md # Analysis of failing tests
    │ └── dependencies.md # Environment setup knowledge
    ├── subtasks/ # Individual task breakdowns
    │ ├── task_001_calibration.md # Signal calibration subtasks
    │ ├── task_002_ffmpeg.md # FFmpeg installation subtasks
    │ └── task_003_optimization.md # Algorithm optimization subtasks
    └── orchestration/ # Agent coordination
    ├── agent_assignments.md # Who's working on what
    ├── progress_tracker.md # Real-time progress updates
    └── integration_plan.md # How pieces fit together
    ```

    ## Coordination Protocol

    ### 1. Task Assignment
    - Check `orchestration/agent_assignments.md` before starting work
    - Update with your agent ID and current task
    - Avoid duplicate efforts by coordinating through this file

    ### 2. Knowledge Sharing
    - Document all discoveries in `memory_bank/`
    - Include failed attempts to prevent repetition
    - Share optimal parameters immediately upon discovery

    ### 3. Progress Updates
    - Update `orchestration/progress_tracker.md` every significant step
    - Mark subtasks complete in respective `subtasks/` files
    - Alert other agents of blockers or dependencies

    ### 4. Integration Points
    - Follow the plan in `orchestration/integration_plan.md`
    - Test integrations incrementally
    - Document any API or interface changes

    ## Communication Standards

    ### Status Markers
    - 🟢 COMPLETE - Task finished and tested
    - 🟡 IN_PROGRESS - Currently being worked on
    - 🔴 BLOCKED - Waiting on dependency or issue
    - ⚪ TODO - Not yet started
    - 🔵 REVIEW - Needs peer review

    ### Update Format
    ```markdown
    ## [Timestamp] Agent: [Agent_ID]
    **Task**: [Brief description]
    **Status**: [Status marker]
    **Details**: [What was done/discovered]
    **Next**: [What needs to happen next]
    ```

    ## Critical Rules
    1. **No Parallel Work** on same file without coordination
    2. **Test Before Commit** - Run relevant tests before marking complete
    3. **Document Failures** - Failed approaches are valuable knowledge
    4. **Share Parameters** - Any calibration values found must be shared immediately
    5. **Atomic Changes** - Make small, focused changes that can be tested independently
  3. @ruvnet ruvnet revised this gist Jun 8, 2025. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion claude-sparc.md
    Original file line number Diff line number Diff line change
    @@ -1,4 +1,4 @@
    # SPARC Automated Development System For Claude Code
    # Claude-SPARC Automated Development System For Claude Code

    ## Overview

  4. @ruvnet ruvnet revised this gist Jun 8, 2025. No changes.
  5. @ruvnet ruvnet created this gist Jun 8, 2025.
    289 changes: 289 additions & 0 deletions claude-sparc.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,289 @@
    # SPARC Automated Development System For Claude Code

    ## Overview

    The SPARC Automated Development System (`claude-sparc.sh`) is a comprehensive, agentic workflow for automated software development using the SPARC methodology (Specification, Pseudocode, Architecture, Refinement, Completion). This system leverages Claude Code's built-in tools for parallel task orchestration, comprehensive research, and Test-Driven Development.

    ## Features

    - **Comprehensive Research Phase**: Automated web research using parallel batch operations
    - **Full SPARC Methodology**: Complete implementation of all 5 SPARC phases
    - **TDD London School**: Test-driven development with mocks and behavior testing
    - **Parallel Orchestration**: Concurrent development tracks and batch operations
    - **Quality Assurance**: Automated linting, testing, and security validation
    - **Detailed Commit History**: Structured commit messages for each development phase

    ## Usage

    ### Basic Usage
    ```bash
    ./claude-sparc.sh
    ```

    ### With Arguments
    ```bash
    ./claude-sparc.sh [OPTIONS] [PROJECT_NAME] [README_PATH]
    ```

    ### Help
    ```bash
    ./claude-sparc.sh --help
    ```

    ## Command Line Options

    ### Core Options
    - `-h, --help` - Show help message and exit
    - `-v, --verbose` - Enable verbose output for detailed logging
    - `-d, --dry-run` - Show what would be executed without running
    - `-c, --config FILE` - Specify MCP configuration file (default: .roo/mcp.json)

    ### Research Options
    - `--skip-research` - Skip the web research phase entirely
    - `--research-depth LEVEL` - Set research depth: basic, standard, comprehensive (default: standard)

    ### Development Options
    - `--mode MODE` - Development mode: full, backend-only, frontend-only, api-only (default: full)
    - `--skip-tests` - Skip test development (not recommended)
    - `--coverage TARGET` - Test coverage target percentage (default: 100)
    - `--no-parallel` - Disable parallel execution

    ### Commit Options
    - `--commit-freq FREQ` - Commit frequency: phase, feature, manual (default: phase)
    - `--no-commits` - Disable automatic commits

    ### Output Options
    - `--output FORMAT` - Output format: text, json, markdown (default: text)
    - `--quiet` - Suppress non-essential output

    ## Examples

    ### Basic Development
    ```bash
    # Full-stack development with default settings
    ./claude-sparc.sh my-app docs/requirements.md

    # Backend API development with verbose output
    ./claude-sparc.sh --mode api-only --verbose user-service api-spec.md

    # Frontend-only development with custom coverage
    ./claude-sparc.sh --mode frontend-only --coverage 90 web-app ui-spec.md
    ```

    ### Research Configuration
    ```bash
    # Skip research for rapid prototyping
    ./claude-sparc.sh --skip-research --coverage 80 prototype-app readme.md

    # Comprehensive research for complex projects
    ./claude-sparc.sh --research-depth comprehensive enterprise-app requirements.md

    # Basic research for simple projects
    ./claude-sparc.sh --research-depth basic simple-tool spec.md
    ```

    ### Development Modes
    ```bash
    # API-only development
    ./claude-sparc.sh --mode api-only --commit-freq feature api-service spec.md

    # Backend services only
    ./claude-sparc.sh --mode backend-only --no-parallel backend-service requirements.md

    # Frontend application only
    ./claude-sparc.sh --mode frontend-only --output json frontend-app ui-spec.md
    ```

    ### Testing and Quality
    ```bash
    # Skip tests for rapid prototyping (not recommended)
    ./claude-sparc.sh --skip-tests --commit-freq manual prototype readme.md

    # Custom coverage target
    ./claude-sparc.sh --coverage 95 --verbose production-app requirements.md

    # Manual commit control
    ./claude-sparc.sh --no-commits --dry-run complex-app spec.md
    ```

    ### Advanced Usage
    ```bash
    # Dry run to preview execution
    ./claude-sparc.sh --dry-run --verbose my-project requirements.md

    # Custom MCP configuration
    ./claude-sparc.sh --config custom-mcp.json --mode full my-app spec.md

    # Quiet mode with JSON output
    ./claude-sparc.sh --quiet --output json --mode api-only service spec.md
    ```

    ## SPARC Phases Explained

    ### Phase 0: Research & Discovery
    - **Parallel Web Research**: Uses `BatchTool` and `WebFetchTool` for comprehensive domain research
    - **Technology Stack Analysis**: Researches best practices and framework comparisons
    - **Implementation Patterns**: Gathers code examples and architectural patterns
    - **Competitive Analysis**: Studies existing solutions and industry trends

    ### Phase 1: Specification
    - **Requirements Analysis**: Extracts functional and non-functional requirements
    - **User Stories**: Defines acceptance criteria and system boundaries
    - **Technical Constraints**: Identifies technology stack and deployment requirements
    - **Performance Targets**: Establishes SLAs and scalability goals

    ### Phase 2: Pseudocode
    - **High-Level Architecture**: Defines major components and data flow
    - **Algorithm Design**: Core business logic and optimization strategies
    - **Test Strategy**: TDD approach with comprehensive test planning
    - **Error Handling**: Recovery strategies and validation algorithms

    ### Phase 3: Architecture
    - **Component Architecture**: Detailed specifications and interface definitions
    - **Data Architecture**: Database design and access patterns
    - **Infrastructure Architecture**: Deployment and CI/CD pipeline design
    - **Security Architecture**: Access controls and compliance requirements

    ### Phase 4: Refinement (TDD Implementation)
    - **Parallel Development Tracks**: Backend, frontend, and integration tracks
    - **TDD London School**: Red-Green-Refactor cycles with behavior testing
    - **Quality Gates**: Automated linting, analysis, and security scans
    - **Performance Optimization**: Benchmarking and critical path optimization

    ### Phase 5: Completion
    - **System Integration**: End-to-end testing and requirement validation
    - **Documentation**: API docs, deployment guides, and runbooks
    - **Production Readiness**: Monitoring, alerting, and security review
    - **Deployment**: Automated deployment with validation

    ## Tool Utilization

    ### Core Tools
    - **`BatchTool`**: Parallel execution of independent operations
    - **`WebFetchTool`**: Comprehensive research and documentation gathering
    - **`Bash`**: Git operations, CI/CD, testing, and deployment
    - **`Edit/Replace`**: Code implementation and refactoring
    - **`GlobTool/GrepTool`**: Code analysis and pattern detection
    - **`dispatch_agent`**: Complex subtask delegation

    ### Quality Assurance Tools
    - **Linting**: ESLint, Prettier, markdownlint
    - **Testing**: Jest, Vitest, Cypress for comprehensive coverage
    - **Security**: Security scans and vulnerability assessments
    - **Performance**: Benchmarking and profiling tools
    - **Documentation**: Automated API documentation generation

    ## Development Standards

    ### Code Quality
    - **Modularity**: Files ≤ 500 lines, functions ≤ 50 lines
    - **Security**: No hardcoded secrets, comprehensive input validation
    - **Testing**: 100% test coverage with TDD London School approach
    - **Documentation**: Self-documenting code with strategic comments
    - **Performance**: Optimized critical paths with benchmarking

    ### Commit Standards
    - **`feat:`** New features and major functionality
    - **`test:`** Test implementation and coverage improvements
    - **`fix:`** Bug fixes and issue resolution
    - **`docs:`** Documentation updates and improvements
    - **`arch:`** Architectural changes and design updates
    - **`quality:`** Code quality improvements and refactoring
    - **`deploy:`** Deployment and infrastructure changes

    ## Parallel Execution Strategy

    ### Research Phase
    ```bash
    BatchTool(
    WebFetchTool("domain research"),
    WebFetchTool("technology analysis"),
    WebFetchTool("competitive landscape"),
    WebFetchTool("implementation patterns")
    )
    ```

    ### Development Phase
    ```bash
    # Concurrent tracks
    Track 1: Backend Development (TDD)
    Track 2: Frontend Development (TDD)
    Track 3: Integration & QA
    ```

    ### Quality Assurance
    ```bash
    BatchTool(
    Bash("npm run lint"),
    Bash("npm run test"),
    Bash("npm run security-scan"),
    Bash("npm run performance-test")
    )
    ```

    ## Success Criteria

    -**100% Test Coverage**: All code covered by comprehensive tests
    -**Quality Gates Passed**: Linting, security, and performance validation
    -**Production Deployment**: Successful deployment with monitoring
    -**Documentation Complete**: Comprehensive docs and runbooks
    -**Security Validated**: Security scans and compliance checks
    -**Performance Optimized**: Benchmarks meet or exceed targets

    ## Configuration

    ### MCP Configuration
    The system uses `.roo/mcp.json` for MCP server configuration. Ensure your MCP setup includes:
    - File system access
    - Web search capabilities
    - Git integration
    - Testing frameworks

    ### Allowed Tools
    The script automatically configures the following tools:
    ```bash
    --allowedTools "WebFetchTool,BatchTool,Bash,Edit,Replace,GlobTool,GrepTool,View,LS,dispatch_agent"
    ```

    ## Examples

    ### Web Application Development
    ```bash
    ./claude-sparc.sh "ecommerce-platform" "requirements/ecommerce-spec.md"
    ```

    ### API Service Development
    ```bash
    ./claude-sparc.sh "user-service-api" "docs/api-requirements.md"
    ```

    ### Data Processing Pipeline
    ```bash
    ./claude-sparc.sh "data-pipeline" "specs/data-processing-requirements.md"
    ```

    ## Troubleshooting

    ### Common Issues
    1. **MCP Configuration**: Ensure `.roo/mcp.json` is properly configured
    2. **Tool Permissions**: Use `--dangerously-skip-permissions` for development
    3. **Network Access**: Ensure internet connectivity for web research
    4. **Git Configuration**: Ensure git is configured for commits

    ### Debug Mode
    Add `--verbose` flag for detailed execution logs:
    ```bash
    ./claude-sparc.sh "project" "readme.md" --verbose
    ```

    ## Contributing

    To extend the SPARC system:
    1. Fork the repository
    2. Create feature branch
    3. Follow SPARC methodology for changes
    4. Submit pull request with comprehensive tests

    ## License

    This SPARC Automated Development System is part of the claude-code-flow project and follows the same licensing terms.
    563 changes: 563 additions & 0 deletions claude-sparc.sh
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,563 @@
    #!/bin/bash

    # SPARC Automated Development System
    # Generic workflow for comprehensive software development using SPARC methodology

    set -e # Exit on any error

    # Default configuration
    PROJECT_NAME="sparc-project"
    README_PATH="README.md"
    MCP_CONFIG=".roo/mcp.json"
    VERBOSE=false
    DRY_RUN=false
    SKIP_RESEARCH=false
    SKIP_TESTS=false
    TEST_COVERAGE_TARGET=100
    PARALLEL_EXECUTION=true
    COMMIT_FREQUENCY="phase" # phase, feature, or manual
    OUTPUT_FORMAT="text"
    DEVELOPMENT_MODE="full" # full, backend-only, frontend-only, api-only

    # Help function
    show_help() {
    cat << EOF
    SPARC Automated Development System
    ==================================
    A comprehensive, automated software development workflow using SPARC methodology
    (Specification, Pseudocode, Architecture, Refinement, Completion)
    USAGE:
    ./claude-sparc.sh [OPTIONS] [PROJECT_NAME] [README_PATH]
    ARGUMENTS:
    PROJECT_NAME Name of the project to develop (default: sparc-project)
    README_PATH Path to initial requirements/readme file (default: readme.md)
    OPTIONS:
    -h, --help Show this help message
    -v, --verbose Enable verbose output
    -d, --dry-run Show what would be done without executing
    -c, --config FILE MCP configuration file (default: .roo/mcp.json)
    # Research Options
    --skip-research Skip the web research phase
    --research-depth LEVEL Research depth: basic, standard, comprehensive (default: standard)
    # Development Options
    --mode MODE Development mode: full, backend-only, frontend-only, api-only (default: full)
    --skip-tests Skip test development (not recommended)
    --coverage TARGET Test coverage target percentage (default: 100)
    --no-parallel Disable parallel execution
    # Commit Options
    --commit-freq FREQ Commit frequency: phase, feature, manual (default: phase)
    --no-commits Disable automatic commits
    # Output Options
    --output FORMAT Output format: text, json, markdown (default: text)
    --quiet Suppress non-essential output
    EXAMPLES:
    # Basic usage
    ./claude-sparc.sh my-app docs/requirements.md
    # Backend API development with verbose output
    ./claude-sparc.sh --mode api-only --verbose user-service api-spec.md
    # Quick prototype without research
    ./claude-sparc.sh --skip-research --coverage 80 prototype-app readme.md
    # Dry run to see what would be executed
    ./claude-sparc.sh --dry-run --verbose my-project requirements.md
    DEVELOPMENT MODES:
    full Complete full-stack development (default)
    backend-only Backend services and APIs only
    frontend-only Frontend application only
    api-only REST/GraphQL API development only
    RESEARCH DEPTHS:
    basic Quick domain overview and technology stack research
    standard Comprehensive research including competitive analysis (default)
    comprehensive Extensive research with academic papers and detailed analysis
    COMMIT FREQUENCIES:
    phase Commit after each SPARC phase completion (default)
    feature Commit after each feature implementation
    manual No automatic commits (manual git operations only)
    For more information, see SPARC-DEVELOPMENT-GUIDE.md
    EOF
    }

    # Parse command line arguments
    parse_args() {
    while [[ $# -gt 0 ]]; do
    case $1 in
    -h|--help)
    show_help
    exit 0
    ;;
    -v|--verbose)
    VERBOSE=true
    shift
    ;;
    -d|--dry-run)
    DRY_RUN=true
    shift
    ;;
    -c|--config)
    MCP_CONFIG="$2"
    shift 2
    ;;
    --skip-research)
    SKIP_RESEARCH=true
    shift
    ;;
    --research-depth)
    RESEARCH_DEPTH="$2"
    shift 2
    ;;
    --mode)
    DEVELOPMENT_MODE="$2"
    shift 2
    ;;
    --skip-tests)
    SKIP_TESTS=true
    shift
    ;;
    --coverage)
    TEST_COVERAGE_TARGET="$2"
    shift 2
    ;;
    --no-parallel)
    PARALLEL_EXECUTION=false
    shift
    ;;
    --commit-freq)
    COMMIT_FREQUENCY="$2"
    shift 2
    ;;
    --no-commits)
    COMMIT_FREQUENCY="manual"
    shift
    ;;
    --output)
    OUTPUT_FORMAT="$2"
    shift 2
    ;;
    --quiet)
    VERBOSE=false
    shift
    ;;
    -*)
    echo "Unknown option: $1" >&2
    echo "Use --help for usage information" >&2
    exit 1
    ;;
    *)
    if [[ "$PROJECT_NAME" == "sparc-project" ]]; then
    PROJECT_NAME="$1"
    elif [[ "$README_PATH" == "README.md" ]]; then
    README_PATH="$1"
    else
    echo "Too many arguments: $1" >&2
    echo "Use --help for usage information" >&2
    exit 1
    fi
    shift
    ;;
    esac
    done
    }

    # Validate configuration
    validate_config() {
    # Check if MCP config exists
    if [[ ! -f "$MCP_CONFIG" ]]; then
    echo "Warning: MCP config file not found: $MCP_CONFIG" >&2
    echo "Using default MCP configuration" >&2
    fi

    # Check if README exists, try to find alternatives if default doesn't exist
    if [[ ! -f "$README_PATH" ]]; then
    # Try common README file variations
    local readme_alternatives=("README.md" "readme.md" "Readme.md" "README.txt" "readme.txt")
    local found_readme=""

    for alt in "${readme_alternatives[@]}"; do
    if [[ -f "$alt" ]]; then
    found_readme="$alt"
    break
    fi
    done

    if [[ -n "$found_readme" ]]; then
    echo "README file '$README_PATH' not found, using '$found_readme' instead" >&2
    README_PATH="$found_readme"
    else
    echo "Error: No README file found. Tried: ${readme_alternatives[*]}" >&2
    echo "Please specify a valid README file path or create one of the above files." >&2
    exit 1
    fi
    fi

    # Validate development mode
    case $DEVELOPMENT_MODE in
    full|backend-only|frontend-only|api-only) ;;
    *) echo "Error: Invalid development mode: $DEVELOPMENT_MODE" >&2; exit 1 ;;
    esac

    # Validate commit frequency
    case $COMMIT_FREQUENCY in
    phase|feature|manual) ;;
    *) echo "Error: Invalid commit frequency: $COMMIT_FREQUENCY" >&2; exit 1 ;;
    esac

    # Validate output format
    case $OUTPUT_FORMAT in
    text|json|markdown) ;;
    *) echo "Error: Invalid output format: $OUTPUT_FORMAT" >&2; exit 1 ;;
    esac

    # Validate coverage target
    if [[ ! "$TEST_COVERAGE_TARGET" =~ ^[0-9]+$ ]] || [[ "$TEST_COVERAGE_TARGET" -lt 0 ]] || [[ "$TEST_COVERAGE_TARGET" -gt 100 ]]; then
    echo "Error: Invalid coverage target: $TEST_COVERAGE_TARGET (must be 0-100)" >&2
    exit 1
    fi
    }

    # Show configuration
    show_config() {
    if [[ "$VERBOSE" == true ]]; then
    cat << EOF
    SPARC Configuration:
    ===================
    Project Name: $PROJECT_NAME
    README Path: $README_PATH
    MCP Config: $MCP_CONFIG
    Development Mode: $DEVELOPMENT_MODE
    Research Depth: ${RESEARCH_DEPTH:-standard}
    Test Coverage Target: $TEST_COVERAGE_TARGET%
    Parallel Execution: $PARALLEL_EXECUTION
    Commit Frequency: $COMMIT_FREQUENCY
    Output Format: $OUTPUT_FORMAT
    Skip Research: $SKIP_RESEARCH
    Skip Tests: $SKIP_TESTS
    Dry Run: $DRY_RUN
    ===================
    EOF
    fi
    }

    # Build allowed tools based on configuration
    build_allowed_tools() {
    local tools="View,Edit,Replace,GlobTool,GrepTool,LS,Bash"

    if [[ "$SKIP_RESEARCH" != true ]]; then
    tools="$tools,WebFetchTool"
    fi

    if [[ "$PARALLEL_EXECUTION" == true ]]; then
    tools="$tools,BatchTool,dispatch_agent"
    fi

    echo "$tools"
    }

    # Build Claude command flags
    build_claude_flags() {
    local flags="--mcp-config $MCP_CONFIG --dangerously-skip-permissions"

    if [[ "$VERBOSE" == true ]]; then
    flags="$flags --verbose"
    fi

    if [[ "$OUTPUT_FORMAT" != "text" ]]; then
    flags="$flags --output-format $OUTPUT_FORMAT"
    fi

    echo "$flags"
    }

    # Main execution
    main() {
    parse_args "$@"
    validate_config
    show_config

    if [[ "$DRY_RUN" == true ]]; then
    echo "DRY RUN - Would execute the following:"
    echo "Project: $PROJECT_NAME"
    echo "README: $README_PATH"
    echo "Allowed Tools: $(build_allowed_tools)"
    echo "Claude Flags: $(build_claude_flags)"
    exit 0
    fi

    # Execute the SPARC development process
    execute_sparc_development
    }

    # Execute SPARC development process
    execute_sparc_development() {
    local allowed_tools=$(build_allowed_tools)
    local claude_flags=$(build_claude_flags)

    claude "
    # SPARC Automated Development System
    # Project: ${PROJECT_NAME}
    # Initial Research Document: ${README_PATH}
    # Configuration: Mode=${DEVELOPMENT_MODE}, Coverage=${TEST_COVERAGE_TARGET}%, Parallel=${PARALLEL_EXECUTION}
    $(if [[ "$SKIP_RESEARCH" != true ]]; then cat << 'RESEARCH_BLOCK'
    ## PHASE 0: COMPREHENSIVE RESEARCH & DISCOVERY
    ### Research Depth: ${RESEARCH_DEPTH:-standard}
    ### Parallel Web Research Phase ($(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo "BatchTool execution"; else echo "Sequential execution"; fi)):
    1. **Domain Research**:
    - WebFetchTool: Extract key concepts from ${README_PATH}
    - WebFetchTool: Search for latest industry trends and technologies
    - WebFetchTool: Research competitive landscape and existing solutions
    $(if [[ "${RESEARCH_DEPTH:-standard}" == "comprehensive" ]]; then echo " - WebFetchTool: Gather academic papers and technical documentation"; fi)
    2. **Technology Stack Research**:
    - WebFetchTool: Research best practices for identified technology domains
    - WebFetchTool: Search for framework comparisons and recommendations
    - WebFetchTool: Investigate security considerations and compliance requirements
    $(if [[ "${RESEARCH_DEPTH:-standard}" != "basic" ]]; then echo " - WebFetchTool: Research scalability patterns and architecture approaches"; fi)
    3. **Implementation Research**:
    - WebFetchTool: Search for code examples and implementation patterns
    $(if [[ "$SKIP_TESTS" != true ]]; then echo " - WebFetchTool: Research testing frameworks and methodologies"; fi)
    - WebFetchTool: Investigate deployment and DevOps best practices
    $(if [[ "${RESEARCH_DEPTH:-standard}" == "comprehensive" ]]; then echo " - WebFetchTool: Research monitoring and observability solutions"; fi)
    ### Research Processing:
    $(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo "Use BatchTool to execute all research queries in parallel for maximum efficiency."; else echo "Execute research queries sequentially for thorough analysis."; fi)
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo "**Commit**: 'feat: complete comprehensive research phase - gathered domain knowledge, technology insights, and implementation patterns'"; fi)
    RESEARCH_BLOCK
    fi)
    ## SPECIFICATION PHASE
    ### Requirements Analysis for ${DEVELOPMENT_MODE} development:
    1. **Functional Requirements**:
    - Analyze ${README_PATH} to extract core functionality
    - Define user stories and acceptance criteria
    - Identify system boundaries and interfaces
    $(if [[ "$DEVELOPMENT_MODE" == "full" || "$DEVELOPMENT_MODE" == "backend-only" || "$DEVELOPMENT_MODE" == "api-only" ]]; then echo " - Specify API endpoints and data models"; fi)
    $(if [[ "$DEVELOPMENT_MODE" == "full" || "$DEVELOPMENT_MODE" == "frontend-only" ]]; then echo " - Define user interface requirements and user experience flows"; fi)
    2. **Non-Functional Requirements**:
    - Security and compliance requirements
    - Performance benchmarks and SLAs
    - Scalability and availability targets
    - Maintainability and extensibility goals
    3. **Technical Constraints**:
    - Technology stack decisions based on research
    - Integration requirements and dependencies
    - Deployment and infrastructure constraints
    - Budget and timeline considerations
    $(if [[ "$COMMIT_FREQUENCY" == "phase" ]]; then echo "**Commit**: 'docs: complete specification phase - defined functional/non-functional requirements and technical constraints for ${DEVELOPMENT_MODE} development'"; fi)
    ## PSEUDOCODE PHASE
    ### High-Level Architecture Design for ${DEVELOPMENT_MODE}:
    1. **System Architecture**:
    $(if [[ "$DEVELOPMENT_MODE" == "full" || "$DEVELOPMENT_MODE" == "backend-only" ]]; then echo " - Define backend components and their responsibilities"; fi)
    $(if [[ "$DEVELOPMENT_MODE" == "full" || "$DEVELOPMENT_MODE" == "frontend-only" ]]; then echo " - Design frontend architecture and component hierarchy"; fi)
    $(if [[ "$DEVELOPMENT_MODE" == "api-only" ]]; then echo " - Define API architecture and endpoint structure"; fi)
    - Design data flow and communication patterns
    - Specify APIs and integration points
    - Plan error handling and recovery strategies
    2. **Algorithm Design**:
    - Core business logic algorithms
    - Data processing and transformation logic
    - Optimization strategies and performance considerations
    - Security and validation algorithms
    $(if [[ "$SKIP_TESTS" != true ]]; then cat << 'TEST_BLOCK'
    3. **Test Strategy**:
    - Unit testing approach (TDD London School)
    - Integration testing strategy
    - End-to-end testing scenarios
    - Target: ${TEST_COVERAGE_TARGET}% test coverage
    $(if [[ "$DEVELOPMENT_MODE" == "full" ]]; then echo " - Frontend and backend testing coordination"; fi)
    TEST_BLOCK
    fi)
    $(if [[ "$COMMIT_FREQUENCY" == "phase" ]]; then echo "**Commit**: 'design: complete pseudocode phase - defined system architecture, algorithms, and test strategy for ${DEVELOPMENT_MODE}'"; fi)
    ## ARCHITECTURE PHASE
    ### Detailed System Design for ${DEVELOPMENT_MODE}:
    1. **Component Architecture**:
    - Detailed component specifications
    - Interface definitions and contracts
    - Dependency injection and inversion of control
    - Configuration management strategy
    $(if [[ "$DEVELOPMENT_MODE" == "full" || "$DEVELOPMENT_MODE" == "backend-only" || "$DEVELOPMENT_MODE" == "api-only" ]]; then cat << 'DATA_BLOCK'
    2. **Data Architecture**:
    - Database schema design
    - Data access patterns and repositories
    - Caching strategies and data flow
    - Backup and recovery procedures
    DATA_BLOCK
    fi)
    3. **Infrastructure Architecture**:
    - Deployment architecture and environments
    - CI/CD pipeline design
    - Monitoring and logging architecture
    - Security architecture and access controls
    $(if [[ "$COMMIT_FREQUENCY" == "phase" ]]; then echo "**Commit**: 'arch: complete architecture phase - detailed component, data, and infrastructure design for ${DEVELOPMENT_MODE}'"; fi)
    ## REFINEMENT PHASE (TDD Implementation)
    ### $(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo "Parallel"; else echo "Sequential"; fi) Development Tracks for ${DEVELOPMENT_MODE}:
    $(if [[ "$DEVELOPMENT_MODE" == "full" || "$DEVELOPMENT_MODE" == "backend-only" || "$DEVELOPMENT_MODE" == "api-only" ]]; then cat << 'BACKEND_BLOCK'
    #### Track 1: Backend Development
    1. **Setup & Infrastructure**:
    - Bash: Initialize project structure
    - Bash: Setup development environment
    - Bash: Configure CI/CD pipeline
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo " - **Commit**: 'feat: initialize backend infrastructure and development environment'"; fi)
    $(if [[ "$SKIP_TESTS" != true ]]; then cat << 'BACKEND_TDD_BLOCK'
    2. **TDD Core Components** (London School):
    - Red: Write failing tests for core business logic
    - Green: Implement minimal code to pass tests
    - Refactor: Optimize while maintaining green tests
    - Target: ${TEST_COVERAGE_TARGET}% coverage
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo " - **Commit**: 'feat: implement core business logic with TDD - ${TEST_COVERAGE_TARGET}% test coverage'"; fi)
    BACKEND_TDD_BLOCK
    fi)
    3. **API Layer Development**:
    - $(if [[ "$SKIP_TESTS" != true ]]; then echo "Red: Write API contract tests"; else echo "Implement API endpoints"; fi)
    - $(if [[ "$SKIP_TESTS" != true ]]; then echo "Green: Implement API endpoints"; else echo "Add input validation and error handling"; fi)
    - $(if [[ "$SKIP_TESTS" != true ]]; then echo "Refactor: Optimize API performance"; else echo "Optimize API performance"; fi)
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo " - **Commit**: 'feat: complete API layer with $(if [[ "$SKIP_TESTS" != true ]]; then echo "comprehensive test coverage"; else echo "validation and error handling"; fi)'"; fi)
    BACKEND_BLOCK
    fi)
    $(if [[ "$DEVELOPMENT_MODE" == "full" || "$DEVELOPMENT_MODE" == "frontend-only" ]]; then cat << 'FRONTEND_BLOCK'
    #### Track 2: Frontend Development
    1. **UI Component Library**:
    - $(if [[ "$SKIP_TESTS" != true ]]; then echo "Red: Write component tests"; else echo "Implement UI components"; fi)
    - $(if [[ "$SKIP_TESTS" != true ]]; then echo "Green: Implement UI components"; else echo "Add component styling and interactions"; fi)
    - $(if [[ "$SKIP_TESTS" != true ]]; then echo "Refactor: Optimize for reusability"; else echo "Optimize for reusability and performance"; fi)
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo " - **Commit**: 'feat: complete UI component library with $(if [[ "$SKIP_TESTS" != true ]]; then echo "full test coverage"; else echo "optimized components"; fi)'"; fi)
    2. **Application Logic**:
    - $(if [[ "$SKIP_TESTS" != true ]]; then echo "Red: Write application flow tests"; else echo "Implement user interactions"; fi)
    - $(if [[ "$SKIP_TESTS" != true ]]; then echo "Green: Implement user interactions"; else echo "Add state management and routing"; fi)
    - $(if [[ "$SKIP_TESTS" != true ]]; then echo "Refactor: Optimize user experience"; else echo "Optimize user experience and performance"; fi)
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo " - **Commit**: 'feat: complete frontend application logic with $(if [[ "$SKIP_TESTS" != true ]]; then echo "end-to-end tests"; else echo "optimized user experience"; fi)'"; fi)
    FRONTEND_BLOCK
    fi)
    #### Track 3: Integration & Quality Assurance
    1. **Integration Testing**:
    $(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo " - BatchTool: Run parallel integration test suites"; else echo " - Bash: Run integration test suites"; fi)
    - Bash: Execute performance benchmarks
    - Bash: Run security scans and audits
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo " - **Commit**: 'test: complete integration testing with performance and security validation'"; fi)
    2. **Quality Gates**:
    $(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo " - BatchTool: Run parallel quality checks (linting, analysis, documentation)"; else echo " - Bash: Run comprehensive linting and code quality analysis"; fi)
    - Bash: Validate documentation completeness
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo " - **Commit**: 'quality: pass all quality gates - linting, analysis, and documentation'"; fi)
    ### $(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo "Parallel"; else echo "Sequential"; fi) Subtask Orchestration:
    $(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo "Use BatchTool to execute independent development tracks in parallel where possible."; else echo "Execute development tracks sequentially for thorough validation."; fi)
    ## COMPLETION PHASE
    ### Final Integration & Deployment for ${DEVELOPMENT_MODE}:
    1. **System Integration**:
    - Integrate all development tracks
    $(if [[ "$SKIP_TESTS" != true ]]; then echo " - Run comprehensive end-to-end tests"; fi)
    - Validate against original requirements
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo " - **Commit**: 'feat: complete system integration with full validation'"; fi)
    2. **Documentation & Deployment**:
    $(if [[ "$DEVELOPMENT_MODE" == "api-only" || "$DEVELOPMENT_MODE" == "backend-only" || "$DEVELOPMENT_MODE" == "full" ]]; then echo " - Generate comprehensive API documentation"; fi)
    - Create deployment guides and runbooks
    - Setup monitoring and alerting
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo " - **Commit**: 'docs: complete documentation and deployment preparation'"; fi)
    3. **Production Readiness**:
    - Execute production deployment checklist
    - Validate monitoring and observability
    - Conduct final security review
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo " - **Commit**: 'deploy: production-ready release with full monitoring and security validation'"; fi)
    ## SPARC METHODOLOGY ENFORCEMENT
    ### Quality Standards:
    - **Modularity**: All files ≤ 500 lines, functions ≤ 50 lines
    - **Security**: No hardcoded secrets, comprehensive input validation
    $(if [[ "$SKIP_TESTS" != true ]]; then echo "- **Testing**: ${TEST_COVERAGE_TARGET}% test coverage with TDD London School approach"; fi)
    - **Documentation**: Self-documenting code with strategic comments
    - **Performance**: Optimized critical paths with benchmarking
    ### Tool Utilization Strategy:
    $(if [[ "$SKIP_RESEARCH" != true ]]; then echo "- **WebFetchTool**: Comprehensive research and documentation gathering"; fi)
    $(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo "- **BatchTool**: Parallel research, testing, and quality checks"; fi)
    - **Bash**: Git operations, CI/CD, testing, and deployment
    - **Edit/Replace**: Code implementation and refactoring
    - **GlobTool/GrepTool**: Code analysis and pattern detection
    $(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo "- **dispatch_agent**: Complex subtask delegation"; fi)
    ### Commit Standards (Frequency: ${COMMIT_FREQUENCY}):
    - **feat**: New features and major functionality
    $(if [[ "$SKIP_TESTS" != true ]]; then echo "- **test**: Test implementation and coverage improvements"; fi)
    - **fix**: Bug fixes and issue resolution
    - **docs**: Documentation updates and improvements
    - **arch**: Architectural changes and design updates
    - **quality**: Code quality improvements and refactoring
    - **deploy**: Deployment and infrastructure changes
    ### $(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo "Parallel"; else echo "Sequential"; fi) Execution Strategy:
    $(if [[ "$PARALLEL_EXECUTION" == true ]]; then cat << 'PARALLEL_BLOCK'
    1. Use BatchTool for independent operations
    2. Leverage dispatch_agent for complex subtasks
    3. Implement concurrent development tracks
    4. Optimize for maximum development velocity
    PARALLEL_BLOCK
    else cat << 'SEQUENTIAL_BLOCK'
    1. Execute operations sequentially for thorough validation
    2. Focus on quality over speed
    3. Ensure each step is fully validated before proceeding
    4. Maintain clear development progression
    SEQUENTIAL_BLOCK
    fi)
    ### Continuous Integration:
    $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo "- Commit after each $(if [[ "$COMMIT_FREQUENCY" == "phase" ]]; then echo "major phase"; else echo "feature"; fi) completion"; fi)
    $(if [[ "$SKIP_TESTS" != true ]]; then echo "- Run automated tests on every commit"; fi)
    - Validate quality gates continuously
    - Monitor performance and security metrics
    ## SUCCESS CRITERIA:
    $(if [[ "$SKIP_TESTS" != true ]]; then echo "- ✅ ${TEST_COVERAGE_TARGET}% test coverage achieved"; fi)
    - ✅ All quality gates passed
    - ✅ Production deployment successful
    - ✅ Comprehensive documentation complete
    - ✅ Security and performance validated
    - ✅ Monitoring and observability operational
    Continue development until all success criteria are met. $(if [[ "$PARALLEL_EXECUTION" == true ]]; then echo "Use parallel execution and subtask orchestration for maximum efficiency."; fi) $(if [[ "$COMMIT_FREQUENCY" != "manual" ]]; then echo "Commit after each $(if [[ "$COMMIT_FREQUENCY" == "phase" ]]; then echo "phase"; else echo "feature"; fi) with detailed messages."; fi) Display '<SPARC-COMPLETE>' when the entire development lifecycle is finished.
    " \
    --allowedTools "$allowed_tools" \
    $claude_flags
    }

    # Execute main function with all arguments
    main "$@"