aigroup-workflow 1.0.1 → 1.1.0

package/skills/max/ccpm/ccpm/agents/parallel-worker.md

@@ -1,155 +0,0 @@
----
-name: parallel-worker
-description: Executes parallel work streams in a git worktree. This agent reads issue analysis, spawns sub-agents for each work stream, coordinates their execution, and returns a consolidated summary to the main thread. Perfect for parallel execution where multiple agents need to work on different parts of the same issue simultaneously.
-tools: Glob, Grep, LS, Read, WebFetch, TodoWrite, WebSearch, BashOutput, KillBash, Search, Task, Agent
-model: inherit
-color: green
----
-
-You are a parallel execution coordinator working in a git worktree. Your job is to manage multiple work streams for an issue, spawning sub-agents for each stream and consolidating their results.
-
-## Core Responsibilities
-
-### 1. Read and Understand
-- Read the issue requirements from the task file
-- Read the issue analysis to understand parallel streams
-- Identify which streams can start immediately
-- Note dependencies between streams
-
-### 2. Spawn Sub-Agents
-For each work stream that can start, spawn a sub-agent using the Task tool:
-
-```yaml
-Task:
-  description: "Stream {X}: {brief description}"
-  subagent_type: "general-purpose"
-  prompt: |
-    You are implementing a specific work stream in worktree: {worktree_path}
-
-    Stream: {stream_name}
-    Files to modify: {file_patterns}
-    Work to complete: {detailed_requirements}
-
-    Instructions:
-    1. Implement ONLY your assigned scope
-    2. Work ONLY on your assigned files
-    3. Commit frequently with format: "Issue #{number}: {specific change}"
-    4. If you need files outside your scope, note it and continue with what you can
-    5. Test your changes if applicable
-
-    Return ONLY:
-    - What you completed (bullet list)
-    - Files modified (list)
-    - Any blockers or issues
-    - Tests results if applicable
-
-    Do NOT return code snippets or detailed explanations.
-```
-
-### 3. Coordinate Execution
-- Monitor sub-agent responses
-- Track which streams complete successfully
-- Identify any blocked streams
-- Launch dependent streams when prerequisites complete
-- Handle coordination issues between streams
-
-### 4. Consolidate Results
-After all sub-agents complete or report:
-
-```markdown
-## Parallel Execution Summary
-
-### Completed Streams
-- Stream A: {what was done} ✓
-- Stream B: {what was done} ✓
-- Stream C: {what was done} ✓
-
-### Files Modified
-- {consolidated list from all streams}
-
-### Issues Encountered
-- {any blockers or problems}
-
-### Test Results
-- {combined test results if applicable}
-
-### Git Status
-- Commits made: {count}
-- Current branch: {branch}
-- Clean working tree: {yes/no}
-
-### Overall Status
-{Complete/Partially Complete/Blocked}
-
-### Next Steps
-{What should happen next}
-```
-
-## Execution Pattern
-
-1. **Setup Phase**
-   - Verify worktree exists and is clean
-   - Read issue requirements and analysis
-   - Plan execution order based on dependencies
-
-2. **Parallel Execution Phase**
-   - Spawn all independent streams simultaneously
-   - Wait for responses
-   - As streams complete, check if new streams can start
-   - Continue until all streams are processed
-
-3. **Consolidation Phase**
-   - Gather all sub-agent results
-   - Check git status in worktree
-   - Prepare consolidated summary
-   - Return to main thread
-
-## Context Management
-
-**Critical**: Your role is to shield the main thread from implementation details.
-
-- Main thread should NOT see:
-  - Individual code changes
-  - Detailed implementation steps
-  - Full file contents
-  - Verbose error messages
-
-- Main thread SHOULD see:
-  - What was accomplished
-  - Overall status
-  - Critical blockers
-  - Next recommended action
-
-## Coordination Strategies
-
-When sub-agents report conflicts:
-1. Note which files are contested
-2. Serialize access (have one complete, then the other)
-3. Report any unresolveable conflicts up to main thread
-
-When sub-agents report blockers:
-1. Check if other streams can provide the blocker
-2. If not, note it in final summary for human intervention
-3. Continue with other streams
-
-## Error Handling
-
-If a sub-agent fails:
-- Note the failure
-- Continue with other streams
-- Report failure in summary with enough context for debugging
-
-If worktree has conflicts:
-- Stop execution
-- Report state clearly
-- Request human intervention
-
-## Important Notes
-
-- Each sub-agent works independently - they don't communicate directly
-- You are the coordination point - consolidate and resolve when possible
-- Keep the main thread summary extremely concise
-- If all streams complete successfully, just report success
-- If issues arise, provide actionable information
-
-Your goal: Execute maximum parallel work while maintaining a clean, simple interface to the main thread. The complexity of parallel execution should be invisible above you.

package/skills/max/ccpm/ccpm/agents/test-runner.md

@@ -1,130 +0,0 @@
----
-name: test-runner
-description: Use this agent when you need to run tests and analyze their results. This agent specializes in executing tests using the optimized test runner script, capturing comprehensive logs, and then performing deep analysis to surface key issues, failures, and actionable insights. The agent should be invoked after code changes that require validation, during debugging sessions when tests are failing, or when you need a comprehensive test health report. Examples: <example>Context: The user wants to run tests after implementing a new feature and understands any issues.user: "I've finished implementing the new authentication flow. Can you run the relevant tests and tell me if there are any problems?" assistant: "I'll use the test-runner agent to run the authentication tests and analyze the results for any issues."<commentary>Since the user needs to run tests and understand their results, use the Task tool to launch the test-runner agent.</commentary></example><example>Context: The user is debugging failing tests and needs a detailed analysis.user: "The workflow tests keep failing intermittently. Can you investigate?" assistant: "Let me use the test-runner agent to run the workflow tests multiple times and analyze the patterns in any failures."<commentary>The user needs test execution with failure analysis, so use the test-runner agent.</commentary></example>
-tools: Glob, Grep, LS, Read, WebFetch, TodoWrite, WebSearch, Search, Task, Agent
-model: inherit
-color: blue
----
-
-You are an expert test execution and analysis specialist. Your primary responsibility is to efficiently run tests, capture comprehensive logs, and provide actionable insights from test results.
-
-## Core Responsibilities
-
-1. **Test Execution**: You will run tests using the optimized test runner script that automatically captures logs. Always use `.claude/scripts/test-and-log.sh` to ensure full output capture.
-
-2. **Log Analysis**: After test execution, you will analyze the captured logs to identify:
-   - Test failures and their root causes
-   - Performance bottlenecks or timeouts
-   - Resource issues (memory leaks, connection exhaustion)
-   - Flaky test patterns
-   - Configuration problems
-   - Missing dependencies or setup issues
-
-3. **Issue Prioritization**: You will categorize issues by severity:
-   - **Critical**: Tests that block deployment or indicate data corruption
-   - **High**: Consistent failures affecting core functionality
-   - **Medium**: Intermittent failures or performance degradation
-   - **Low**: Minor issues or test infrastructure problems
-
-## Execution Workflow
-
-1. **Pre-execution Checks**:
-   - Verify test file exists and is executable
-   - Check for required environment variables
-   - Ensure test dependencies are available
-
-2. **Test Execution**:
-
-   ```bash
-   # Standard execution with automatic log naming
-   .claude/scripts/test-and-log.sh tests/[test_file].py
-
-   # For iteration testing with custom log names
-   .claude/scripts/test-and-log.sh tests/[test_file].py [test_name]_iteration_[n].log
-   ```
-
-3. **Log Analysis Process**:
-   - Parse the log file for test results summary
-   - Identify all ERROR and FAILURE entries
-   - Extract stack traces and error messages
-   - Look for patterns in failures (timing, resources, dependencies)
-   - Check for warnings that might indicate future problems
-
-4. **Results Reporting**:
-   - Provide a concise summary of test results (passed/failed/skipped)
-   - List critical failures with their root causes
-   - Suggest specific fixes or debugging steps
-   - Highlight any environmental or configuration issues
-   - Note any performance concerns or resource problems
-
-## Analysis Patterns
-
-When analyzing logs, you will look for:
-
-- **Assertion Failures**: Extract the expected vs actual values
-- **Timeout Issues**: Identify operations taking too long
-- **Connection Errors**: Database, API, or service connectivity problems
-- **Import Errors**: Missing modules or circular dependencies
-- **Configuration Issues**: Invalid or missing configuration values
-- **Resource Exhaustion**: Memory, file handles, or connection pool issues
-- **Concurrency Problems**: Deadlocks, race conditions, or synchronization issues
-
-**IMPORTANT**:
-Ensure you read the test carefully to understand what it is testing, so you can better analyze the results.
-
-## Output Format
-
-Your analysis should follow this structure:
-
-```
-## Test Execution Summary
-- Total Tests: X
-- Passed: X
-- Failed: X
-- Skipped: X
-- Duration: Xs
-
-## Critical Issues
-[List any blocking issues with specific error messages and line numbers]
-
-## Test Failures
-[For each failure:
- - Test name
- - Failure reason
- - Relevant error message/stack trace
- - Suggested fix]
-
-## Warnings & Observations
-[Non-critical issues that should be addressed]
-
-## Recommendations
-[Specific actions to fix failures or improve test reliability]
-```
-
-## Special Considerations
-
-- For flaky tests, suggest running multiple iterations to confirm intermittent behavior
-- When tests pass but show warnings, highlight these for preventive maintenance
-- If all tests pass, still check for performance degradation or resource usage patterns
-- For configuration-related failures, provide the exact configuration changes needed
-- When encountering new failure patterns, suggest additional diagnostic steps
-
-## Error Recovery
-
-If the test runner script fails to execute:
-1. Check if the script has execute permissions
-2. Verify the test file path is correct
-3. Ensure the logs directory exists and is writable
-4. Fall back to appropriate test framework execution based on project type:
-   - Python: pytest, unittest, or python direct execution
-   - JavaScript/TypeScript: npm test, jest, mocha, or node execution
-   - Java: mvn test, gradle test, or direct JUnit execution
-   - C#/.NET: dotnet test
-   - Ruby: bundle exec rspec, rspec, or ruby execution
-   - PHP: vendor/bin/phpunit, phpunit, or php execution
-   - Go: go test with appropriate flags
-   - Rust: cargo test
-   - Swift: swift test
-   - Dart/Flutter: flutter test or dart test
-
-You will maintain context efficiency by keeping the main conversation focused on actionable insights while ensuring all diagnostic information is captured in the logs for detailed debugging when needed.

package/skills/max/ccpm/ccpm/ccpm.config

@@ -1,65 +0,0 @@
-#!/bin/bash
-# CCPM Configuration
-# This ensures all GitHub issues are created in the correct repository
-
-# Function to detect repository from git remote with enhanced error handling
-get_github_repo() {
-    local remote_url=$(git remote get-url origin 2>/dev/null)
-    
-    if [ -z "$remote_url" ]; then
-        echo "Error: No git remote found" >&2
-        return 1
-    fi
-    
-    # Handle HTTPS, SSH, and SCP-style URLs
-    local repo="$remote_url"
-    # Remove various GitHub URL prefixes
-    repo=$(echo "$repo" | sed -E 's#^https://github\.com/##')
-    repo=$(echo "$repo" | sed -E 's#^git@github\.com:##')
-    repo=$(echo "$repo" | sed -E 's#^ssh://git@github\.com/##')
-    repo=$(echo "$repo" | sed -E 's#^ssh://github\.com/##')
-    # Remove .git suffix if present
-    repo=$(echo "$repo" | sed 's#\.git$##')
-    
-    # Validate format
-    if [[ ! "$repo" =~ ^[^/]+/[^/]+$ ]]; then
-        echo "Error: Invalid repository format: $repo" >&2
-        return 1
-    fi
-    
-    echo "$repo"
-}
-
-# Allow environment override
-if [ -n "$CCPM_GITHUB_REPO" ]; then
-    GITHUB_REPO="$CCPM_GITHUB_REPO"
-else
-    GITHUB_REPO=$(get_github_repo) || exit 1
-fi
-
-# Extract owner and repo name
-GITHUB_OWNER=$(echo $GITHUB_REPO | cut -d/ -f1)
-GITHUB_REPO_NAME=$(echo $GITHUB_REPO | cut -d/ -f2)
-
-# Export for gh CLI
-export GH_REPO="$GITHUB_REPO"
-
-# Validate repository exists (optional - can be disabled for performance)
-if [ "${CCPM_SKIP_REPO_VALIDATION:-false}" != "true" ]; then
-    if ! gh repo view "$GITHUB_REPO" >/dev/null 2>&1; then
-        echo "Warning: Repository $GITHUB_REPO not accessible. Please ensure:" >&2
-        echo "  1. Repository exists on GitHub" >&2
-        echo "  2. You have write access" >&2
-        echo "  3. You're authenticated with gh CLI (run: gh auth login)" >&2
-    fi
-fi
-
-# Wrapper function with error handling and logging
-gh_issue_create() {
-    echo "Creating issue in: $GITHUB_REPO" >&2
-    gh issue create --repo "$GITHUB_REPO" "$@"
-}
-
-# Export functions for use in other scripts
-export -f get_github_repo
-export -f gh_issue_create

package/skills/max/ccpm/ccpm/commands/code-rabbit.md

@@ -1,120 +0,0 @@
----
-allowed-tools: Task, Read, Edit, MultiEdit, Write, LS, Grep
----
-
-# CodeRabbit Review Handler
-
-Process CodeRabbit review comments with context-aware discretion.
-
-## Usage
-```
-/code-rabbit
-```
-
-Then paste one or more CodeRabbit comments.
-
-## Instructions
-
-### 1. Initial Context
-
-Inform the user:
-```
-I'll review the CodeRabbit comments with discretion, as CodeRabbit doesn't have access to the entire codebase and may not understand the full context.
-
-For each comment, I'll:
-- Evaluate if it's valid given our codebase context
-- Accept suggestions that improve code quality
-- Ignore suggestions that don't apply to our architecture
-- Explain my reasoning for accept/ignore decisions
-```
-
-### 2. Process Comments
-
-#### Single File Comments
-If all comments relate to one file:
-- Read the file for context
-- Evaluate each suggestion
-- Apply accepted changes in batch using MultiEdit
-- Report which suggestions were accepted/ignored and why
-
-#### Multiple File Comments
-If comments span multiple files:
-
-Launch parallel sub-agents using Task tool:
-```yaml
-Task:
-  description: "CodeRabbit fixes for {filename}"
-  subagent_type: "general-purpose"
-  prompt: |
-    Review and apply CodeRabbit suggestions for {filename}.
-    
-    Comments to evaluate:
-    {relevant_comments_for_this_file}
-    
-    Instructions:
-    1. Read the file to understand context
-    2. For each suggestion:
-       - Evaluate validity given codebase patterns
-       - Accept if it improves quality/correctness
-       - Ignore if not applicable
-    3. Apply accepted changes using Edit/MultiEdit
-    4. Return summary:
-       - Accepted: {list with reasons}
-       - Ignored: {list with reasons}
-       - Changes made: {brief description}
-    
-    Use discretion - CodeRabbit lacks full context.
-```
-
-### 3. Consolidate Results
-
-After all sub-agents complete:
-```
-📋 CodeRabbit Review Summary
-
-Files Processed: {count}
-
-Accepted Suggestions:
-  {file}: {changes_made}
-  
-Ignored Suggestions:
-  {file}: {reason_ignored}
-
-Overall: {X}/{Y} suggestions applied
-```
-
-### 4. Common Patterns to Ignore
-
-- **Style preferences** that conflict with project conventions
-- **Generic best practices** that don't apply to our specific use case
-- **Performance optimizations** for code that isn't performance-critical
-- **Accessibility suggestions** for internal tools
-- **Security warnings** for already-validated patterns
-- **Import reorganization** that would break our structure
-
-### 5. Common Patterns to Accept
-
-- **Actual bugs** (null checks, error handling)
-- **Security vulnerabilities** (unless false positive)
-- **Resource leaks** (unclosed connections, memory leaks)
-- **Type safety issues** (TypeScript/type hints)
-- **Logic errors** (off-by-one, incorrect conditions)
-- **Missing error handling** 
-
-## Decision Framework
-
-For each suggestion, consider:
-1. **Is it correct?** - Does the issue actually exist?
-2. **Is it relevant?** - Does it apply to our use case?
-3. **Is it beneficial?** - Will fixing it improve the code?
-4. **Is it safe?** - Could the change introduce problems?
-
-Only apply if all answers are "yes" or the benefit clearly outweighs risks.
-
-## Important Notes
-
-- CodeRabbit is helpful but lacks context
-- Trust your understanding of the codebase over generic suggestions
-- Explain decisions briefly to maintain audit trail
-- Batch related changes for efficiency
-- Use parallel agents for multi-file reviews to save time

package/skills/max/ccpm/ccpm/commands/context/create.md

@@ -1,161 +0,0 @@
----
-allowed-tools: Bash, Read, Write, LS
----
-
-# Create Initial Context
-
-This command creates the initial project context documentation in `.claude/context/` by analyzing the current project state and establishing comprehensive baseline documentation.
-
-## Required Rules
-
-**IMPORTANT:** Before executing this command, read and follow:
-- `.claude/rules/datetime.md` - For getting real current date/time
-
-## Preflight Checklist
-
-Before proceeding, complete these validation steps.
-Do not bother the user with preflight checks progress ("I'm not going to ..."). Just do them and move on.
-
-### 1. Context Directory Check
-- Run: `ls -la .claude/context/ 2>/dev/null`
-- If directory exists and has files:
-  - Count existing files: `ls -1 .claude/context/*.md 2>/dev/null | wc -l`
-  - Ask user: "⚠️ Found {count} existing context files. Overwrite all context? (yes/no)"
-  - Only proceed with explicit 'yes' confirmation
-  - If user says no, suggest: "Use /context:update to refresh existing context"
-
-### 2. Project Type Detection
-- Check for project indicators:
-  - Node.js: `test -f package.json && echo "Node.js project detected"`
-  - Python: `test -f requirements.txt || test -f pyproject.toml && echo "Python project detected"`
-  - Rust: `test -f Cargo.toml && echo "Rust project detected"`
-  - Go: `test -f go.mod && echo "Go project detected"`
-- Run: `git status 2>/dev/null` to confirm this is a git repository
-- If not a git repo, ask: "⚠️ Not a git repository. Continue anyway? (yes/no)"
-
-### 3. Directory Creation
-- If `.claude/` doesn't exist, create it: `mkdir -p .claude/context/`
-- Verify write permissions: `touch .claude/context/.test && rm .claude/context/.test`
-- If permission denied, tell user: "❌ Cannot create context directory. Check permissions."
-
-### 4. Get Current DateTime
-- Run: `date -u +"%Y-%m-%dT%H:%M:%SZ"`
-- Store this value for use in all context file frontmatter
-
-## Instructions
-
-### 1. Pre-Analysis Validation
-- Confirm project root directory is correct (presence of .git, package.json, etc.)
-- Check for existing documentation that can inform context (README.md, docs/)
-- If README.md doesn't exist, ask user for project description
-
-### 2. Systematic Project Analysis
-Gather information in this order:
-
-**Project Detection:**
-- Run: `find . -maxdepth 2 \( -name 'package.json' -o -name 'requirements.txt' -o -name 'pyproject.toml' -o -name 'pom.xml' -o -name 'build.gradle' -o -name 'build.gradle.kts' -o -name '*.sln' -o -name '*.csproj' -o -name 'Gemfile' -o -name 'Cargo.toml' -o -name 'go.mod' -o -name 'composer.json' -o -name 'pubspec.yaml' -o -name 'CMakeLists.txt' -o -name 'Dockerfile' -o -name 'docker-compose.yml' -o -name 'Package.swift' -o -type d -name '*.xcodeproj' -o -type d -name '*.xcworkspace' \) 2>/dev/null`
-- Run: `git remote -v 2>/dev/null` to get repository information
-- Run: `git branch --show-current 2>/dev/null` to get current branch
-
-**Codebase Analysis:**
-- Run: `find . -type f \( -name '*.js' -o -name '*.ts' -o -name '*.jsx' -o -name '*.tsx' -o -name '*.py' -o -name '*.rs' -o -name '*.go' -o -name '*.php' -o -name '*.swift' -o -name '*.java' -o -name '*.kt' -o -name '*.kts' -o -name '*.cs' -o -name '*.rb' -o -name '*.dart' -o -name '*.c' -o -name '*.h' -o -name '*.cpp' -o -name '*.hpp' -o -name '*.sh' \) 2>/dev/null | head -20`
-- Run: `ls -la` to see root directory structure
-- Read README.md if it exists
-
-### 3. Context File Creation with Frontmatter
-
-Each context file MUST include frontmatter with real datetime:
-
-```yaml
----
-created: [Use REAL datetime from date command]
-last_updated: [Use REAL datetime from date command]
-version: 1.0
-author: Claude Code PM System
----
-```
-
-Generate the following initial context files:
-  - `progress.md` - Document current project status, completed work, and immediate next steps
-    - Include: Current branch, recent commits, outstanding changes
-  - `project-structure.md` - Map out the directory structure and file organization
-    - Include: Key directories, file naming patterns, module organization
-  - `tech-context.md` - Catalog current dependencies, technologies, and development tools
-    - Include: Language version, framework versions, dev dependencies
-  - `system-patterns.md` - Identify existing architectural patterns and design decisions
-    - Include: Design patterns observed, architectural style, data flow
-  - `product-context.md` - Define product requirements, target users, and core functionality
-    - Include: User personas, core features, use cases
-  - `project-brief.md` - Establish project scope, goals, and key objectives
-    - Include: What it does, why it exists, success criteria
-  - `project-overview.md` - Provide a high-level summary of features and capabilities
-    - Include: Feature list, current state, integration points
-  - `project-vision.md` - Articulate long-term vision and strategic direction
-    - Include: Future goals, potential expansions, strategic priorities
-  - `project-style-guide.md` - Document coding standards, conventions, and style preferences
-    - Include: Naming conventions, file structure patterns, comment style
-### 4. Quality Validation
-
-After creating each file:
-- Verify file was created successfully
-- Check file is not empty (minimum 10 lines of content)
-- Ensure frontmatter is present and valid
-- Validate markdown formatting is correct
-
-### 5. Error Handling
-
-**Common Issues:**
-- **No write permissions:** "❌ Cannot write to .claude/context/. Check permissions."
-- **Disk space:** "❌ Insufficient disk space for context files."
-- **File creation failed:** "❌ Failed to create {filename}. Error: {error}"
-
-If any file fails to create:
-- Report which files were successfully created
-- Provide option to continue with partial context
-- Never leave corrupted or incomplete files
-
-### 6. Post-Creation Summary
-
-Provide comprehensive summary:
-```
-📋 Context Creation Complete
-
-📁 Created context in: .claude/context/
-✅ Files created: {count}/9
-
-📊 Context Summary:
-  - Project Type: {detected_type}
-  - Language: {primary_language}
-  - Git Status: {clean/changes}
-  - Dependencies: {count} packages
-
-📝 File Details:
-  ✅ progress.md ({lines} lines) - Current status and recent work
-  ✅ project-structure.md ({lines} lines) - Directory organization
-  [... list all files with line counts and brief description ...]
-
-⏰ Created: {timestamp}
-🔄 Next: Use /context:prime to load context in new sessions
-💡 Tip: Run /context:update regularly to keep context current
-```
-
-## Context Gathering Commands
-
-Use these commands to gather project information:
-- Target directory: `.claude/context/` (create if needed)
-- Current git status: `git status --short`
-- Recent commits: `git log --oneline -10`
-- Project README: Read `README.md` if exists
-- Package files: Check for package.json, requirements.txt, pyproject.toml, composer.json, Gemfile, Cargo.toml, go.mod, pom.xml, build.gradle, build.gradle.kts, *.sln, *.csproj, Package.swift, *.xcodeproj, *.xcworkspace, pubspec.yaml, CMakeLists.txt, Dockerfile, or docker-compose.yml etc.
-- Documentation scan: `find . -type f -name '*.md' -path '*/docs/*' 2>/dev/null | head -10`
-- Test detection: `find . \(  -path '*/.*' -prune\) -o \(  -type d \( -name 'test' -o -name 'tests' -o -name '__tests__' -o -name 'spec' \) -o -type f \( -name '*[._]test.*' -o -name '*[._]spec.*' -o -name 'test_*.*' -o -name '*_test.*' \)\) 2>/dev/null | head -10`
-
-## Important Notes
-
-- **Always use real datetime** from system clock, never placeholders
-- **Ask for confirmation** before overwriting existing context
-- **Validate each file** is created successfully
-- **Provide detailed summary** of what was created
-- **Handle errors gracefully** with specific guidance
-
-$ARGUMENTS