detailobsessed · lautalom · Aug 26, 2025 · Aug 26, 2025 · Aug 26, 2025 · Aug 26, 2025
@@ -17,7 +17,10 @@
     "RAII",
     "mcpservers",
     "kinopeee",
-    "kamusis"
+    "kamusis",
+    "elif",
+    "llombardi",
+    "unshallow"
   ],
   "ignorePaths": ["node_modules/**", "package.json", "package-lock.json"],
   "allowCompoundWords": true,

@@ -0,0 +1,85 @@
+# PR Workflows for Windsurf
+
+This contribution provides comprehensive PR (Pull Request) **workflows** for Windsurf that help with code review and PR summary generation.
+
+## What's Included
+
+### PR Review Workflow ([`pr-review.md`](./Workspace-AI-rules/pr-workflows/pr-review.md))
+
+A comprehensive workflow that:
+
+- Generates diffs against the detected base branch (main/master or origin/\*) automatically
+- Collects PR context from users
+- Performs multi-dimensional code analysis including:
+  - Algorithmic complexity analysis
+  - Testing coverage review
+  - Code consistency checks
+  - Security analysis
+  - Error handling evaluation
+  - Architecture pattern validation
+  - Performance considerations
+  - Documentation assessment
+- Provides structured review summaries with actionable feedback
+
+### PR Summary Workflow ([`pr-summary.md`](./Workspace-AI-rules/pr-workflows/pr-summary.md))
+
+A technical summary generator that:
+
+- Analyzes changes from conversation context
+- Extracts file modifications and code metrics
+- Identifies architecture impacts and dependencies
+- Generates structured PR summaries for developers and DevOps (or any technical) teams
+
+## Why I Created This
+
+These workflows solve common pain points in code review processes:
+
+- **Consistency**: Ensures all PRs are reviewed against the same comprehensive criteria
+- **Efficiency**: Automates diff generation and context collection
+- **Quality**: Covers security, performance, testing, and architectural concerns
+- **Documentation**: Generates professional PR summaries from conversation context
+
+## Usage
+
+Use the slash commands in Windsurf:
+
+- `/pr-review` - Comprehensive PR analysis and review
+- `/pr-summary` - Generate technical PR summary from conversation context
+
+## Setup
+
+Create the workflows directory and copy the workflow files to your project:
+
+```bash
+# Create the workflows directory if it doesn't exist
+mkdir -p .windsurf/workflows/
+
+# Copy the workflow files (files are copied, not moved or renamed)
+cp memories/llombardi/Workspace-AI-rules/pr-workflows/pr-review.md .windsurf/workflows/
+cp memories/llombardi/Workspace-AI-rules/pr-workflows/pr-summary.md .windsurf/workflows/
+```
+
+**Note**: These commands copy the files safely without modifying the originals.
+
+## Tips and Tricks
+
+1. **Context Matters**: The more context you provide about the PR (business requirements, testing strategy), the better the review quality
+2. **Iterative Reviews**: Use the workflow multiple times as you address feedback
+3. **Learning Tool**: The workflow occasionally leaves open questions to help you learn to spot issues independently
+4. **Complementary**: Use `/pr-review` for detailed analysis, then `/pr-summary` for documentation
+
+## Real-World Examples
+
+Perfect for:
+
+- **Enterprise development**: Consistent review standards across teams
+- **Open-source projects**: Thorough review process for contributors
+- **DevOps teams**: Technical summaries for deployment planning
+- **Code-quality gates**: Automated quality checks before merge
+
+## Current Limitations
+
+- Requires Git repository with main/master branch. Indicate the base branch as context in the command if it's different from main/master.
+- Git must be installed and reachable (commands assume `git` in PATH)
+- Repository refs must be fetchable (CI or shallow clones may need `git fetch --unshallow` or full fetch of refs)
+- Manual context collection step in PR review. You may provide context in the command if you want to skip this step.
@@ -0,0 +1,155 @@
+---
+description: This workflow helps review Pull Requests by generating a diff against the main/master branch and collecting context from the user.
+auto_execution_mode: 3
+---
+
+# PR Review Workflow
+
+This workflow provides a comprehensive review of Pull Requests by analyzing code changes, collecting context, and evaluating multiple aspects of the implementation. Prefer concise, actionable findings; use clarifying questions only when essential to resolve ambiguity.
+
+## Step 1: Generate Diff Against Base Branch
+
+First, we'll generate a diff against the repository's default branch (with fallbacks) to understand what changes are being proposed.
+
+```bash
+# Enable safe shell options
+set -euo pipefail
+
+# Fetch origin refs quietly to handle shallow/remote-only cases
+git fetch origin --quiet 2>/dev/null || echo "Warning: Could not fetch from origin"
+
+# Detect repository default remote branch via refs/remotes/origin/HEAD with fallbacks
+if git symbolic-ref refs/remotes/origin/HEAD >/dev/null 2>&1; then
+    BASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/@@')
+elif git show-ref --verify --quiet refs/remotes/origin/main; then
+    BASE_BRANCH="origin/main"
+elif git show-ref --verify --quiet refs/remotes/origin/master; then
+    BASE_BRANCH="origin/master"
+elif git show-ref --verify --quiet refs/heads/main; then
+    BASE_BRANCH="main"
+elif git show-ref --verify --quiet refs/heads/master; then
+    BASE_BRANCH="master"
+else
+    echo "Error: No suitable default base branch found"
+    exit 1
+fi
+
+# Determine current branch robustly (handles detached HEAD)
+CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
+if [[ "${CURRENT_BRANCH}" == "HEAD" ]]; then
+    CURRENT_BRANCH=$(git rev-parse HEAD)
+fi
+
+# Optionally compute and log merge-base if available
+if MERGE_BASE=$(git merge-base "${BASE_BRANCH}" "${CURRENT_BRANCH}" 2>/dev/null); then
+    echo "Merge base commit: ${MERGE_BASE}"
+else
+    echo "Warning: Could not determine merge base"
+fi
+
+# Disable git pager to prevent interactive mode
+export GIT_PAGER=cat
+
+# Generate diff using triple-dot syntax with rename detection (git picks correct merge-base implicitly)
+git --no-pager diff --no-color -M "${BASE_BRANCH}...${CURRENT_BRANCH}"
+```
+
+## Step 2: Collect PR Context (skip if already provided)
+
+You may provide any of the following context inline when invoking the slash command, or provide it now if not already given:
+
+1. **PR Summary**: Brief description of what this PR accomplishes
+2. **Ticket/Issue Description**: Link to or description of the related ticket/issue
+3. **Business Context**: Why is this change needed?
+4. **Breaking Changes**: Are there any breaking changes in this PR?
+5. **Testing Strategy**: How was this change tested?
+
+## Step 3: Analyze Code Changes
+
+Based on the diff and context provided, analyze the PR across multiple dimensions:
+
+### 3.1 Algorithmic Complexity Analysis
+
+- Review time and space complexity of new algorithms
+- Identify potential performance bottlenecks
+- Check for inefficient loops, nested operations, or recursive calls
+- Evaluate database query efficiency and N+1 problems
+
+### 3.2 Testing Coverage Analysis
+
+- Verify adequate unit test coverage for new code
+- Check for integration tests where appropriate
+- Evaluate test quality and edge case coverage
+- Ensure mocks and fixtures are properly implemented
+- Validate table-driven tests for comprehensive scenarios
+
+### 3.3 Code Consistency Review
+
+- Check adherence to existing code patterns and conventions
+- Verify consistent error handling patterns
+- Evaluate logging consistency and appropriate log levels
+- Review naming conventions and code organization
+- Ensure proper dependency injection patterns
+
+### 3.4 Security Analysis
+
+- Identify potential security vulnerabilities
+- Check for proper input validation and sanitization
+- Review authentication and authorization implementations
+- Evaluate data exposure risks
+- Check for hardcoded secrets or credentials
+- Assess SQL injection and other injection attack vectors
+
+### 3.5 Error Handling & Reliability
+
+- Verify comprehensive error handling
+- Check for proper context propagation
+- Evaluate graceful degradation scenarios
+- Review timeout and retry mechanisms
+- Assess potential race conditions or concurrency issues
+
+### 3.6 Architecture & Design Patterns
+
+- Evaluate adherence to established architectural patterns
+- Check for proper separation of concerns
+- Review interface design and abstraction levels
+- Assess maintainability and extensibility
+- Validate dependency management and coupling
+
+### 3.7 Performance Considerations
+
+- Review memory usage patterns
+- Check for potential memory leaks
+- Evaluate concurrency management and lifecycle
+- Assess database connection pooling
+- Review caching strategies where applicable
+
+### 3.8 Documentation & Maintainability
+
+- Check for adequate code comments (without over-commenting)
+- Verify API documentation updates
+- Evaluate code readability and self-documentation
+- Review configuration changes and documentation
+
+## Step 4: Generate Review Summary
+
+Based on the analysis, I'll provide:
+
+1. **Overall Assessment**: High-level evaluation of the PR quality
+2. **Critical Issues**: Must-fix issues that block merge
+3. **Recommendations**: Suggested improvements for code quality
+4. **Positive Highlights**: Well-implemented aspects worth noting
+5. **Risk Assessment**: Potential risks and mitigation strategies
+
+## Step 5: Action Items
+
+I'll categorize findings into:
+
+- **Blocking Issues**: Must be addressed before merge
+- **High Priority**: Should be addressed before merge
+- **Medium Priority**: Consider addressing in this PR or follow-up
+- **Low Priority**: Nice-to-have improvements for future consideration
+
+---
+
+**Note**: This workflow focuses on code review and suggestions only. No changes will be applied to the codebase during the review process.
@@ -0,0 +1,69 @@
+---
+description: Generate technical PR summary using conversation context
+---
+
+# PR Summary Generation Workflow
+
+This workflow generates a technical PR summary by analyzing changes from the current conversation context for developers and DevOps teams.
+
+## Step 1: Analyze Changes from Context
+
+Extract technical information from conversation history:
+
+- **Files Modified**: Source code, tests, config, documentation changes
+- **Code Metrics**: Lines added/removed, functions/methods modified
+- **Architecture Impact**: New modules, interface changes, breaking changes
+- **Dependencies**: Package manager updates, new libraries
+
+## Step 2: Generate Technical PR Summary
+
+## PR Summary: [Title]
+
+### What Changed
+
+**One-line technical summary**: [Brief description of the core change]
+
+**Concrete deltas** (2-4 bullets):
+
+- Added: [specific functionality/files added]
+- Modified: [specific components changed]
+- Removed: [specific items deleted]
+- Fixed: [specific issues resolved]
+
+**Rationale**: [One sentence explaining why this change was made and any scope/rollout considerations]
+
+### Files Modified
+
+- **Core Changes**: X files (+Y, -Z lines)
+- **Tests**: Unit/integration tests added/modified
+- **Config**: Configuration or deployment changes
+- **Dependencies**: Package updates or additions
+
+<!-- Optional machine-friendly tokens:
+files_changed: {{files_changed}}
+lines_added: {{lines_added}}
+lines_deleted: {{lines_deleted}}
+test_files_modified: {{test_files_modified}}
+config_files_modified: {{config_files_modified}}
+dependency_files_modified: {{dependency_files_modified}}
+-->
+
+### Technical Impact
+
+- **Breaking Changes**: API/interface modifications
+- **Performance**: Expected impact on system performance
+- **Security**: Security considerations or improvements
+- **Architecture**: Design pattern or structural changes
+
+### Testing
+
+- **Coverage**: New tests added, existing tests modified
+- **Manual Testing**: Key scenarios verified
+- **Edge Cases**: Boundary conditions tested
+
+### Notes
+
+- **Migration**: Database or config migrations required
+- **Environment**: New environment variables or settings
+
+**Note**: Use `/pr-review` for detailed code analysis and feedback.