Improve PR Skill

Performs comprehensive PR analysis combining security review, best practices assessment, and actionable code improvements with auto-apply capability.

Usage

/improve-pr <pr-number>

Workflow

Step 1: Fetch PR and Checkout Branch

# Get PR details
PR_INFO=$(gh pr view $ARGUMENTS --json headRefName,baseRefName,files,title,additions,deletions)
HEAD_BRANCH=$(echo $PR_INFO | jq -r '.headRefName')

# Checkout the PR branch
git fetch origin
git checkout $HEAD_BRANCH
git pull origin $HEAD_BRANCH

# Get the diff
gh pr diff $ARGUMENTS

# Get PR checks status
gh pr checks $ARGUMENTS

Step 2: Comprehensive Analysis

Analyze the code across multiple dimensions:

🔒 Security Analysis:

• •SQL injection vulnerabilities
• •XSS (Cross-Site Scripting) risks
• •Authentication/authorization issues
• •Secrets in code (API keys, passwords)
• •Insecure dependencies
• •CSRF protection
• •Input validation
• •Cryptography weaknesses

🎨 Code Quality:

• •Extract duplicate code into functions
• •Simplify complex conditionals
• •Improve variable/function naming
• •Add error handling
• •Reduce nesting depth
• •Apply SOLID principles

⚡ Performance:

• •Optimize algorithms
• •Reduce database queries (N+1 issues)
• •Add caching where appropriate
• •Lazy load resources
• •Parallel processing opportunities

📖 Readability:

• •Add clarifying comments
• •Break down large functions
• •Improve code organization
• •Use descriptive names

✨ Best Practices:

• •Follow language idioms
• •Use modern syntax
• •Apply design patterns
• •Follow project conventions

🧪 Testing Coverage:

• •Missing unit tests
• •Untested edge cases
• •Error handling tests

Step 3: Generate Report

See references/report-template.md for full template.

Key sections:

• •Overview (files, lines, quality rating)
• •Security analysis (strengths, issues, warnings)
• •Code quality improvements by category
• •File-by-file improvements with before/after
• •Implementation priority (Critical → Low)
• •Testing coverage gaps
• •Impact summary

Step 4: Auto-Apply Options

Present options to user:

• •A) Apply critical fixes + high priority improvements
• •B) Apply high priority only (safer)
• •C) Apply specific improvements (user chooses)
• •D) Show changes first (don't apply)
• •E) Post as PR comment for team review

Step 5: Apply Changes (if selected)

# For each improvement:
# 1. Use Edit tool to apply the change
# 2. Verify syntax is correct
# 3. Track what was changed

# After all changes:
git add .
git commit -m "🚀 improve: apply AI-suggested improvements

Security fixes:
- [list security fixes]

Code quality:
- [list improvements]

Applied [count] improvements across [count] files."

git push origin $HEAD_BRANCH

Step 6: Verification

# Run any available tests
if [ -f "package.json" ]; then npm test; fi
if [ -f "pytest.ini" ]; then pytest; fi
if [ -f "Makefile" ]; then make test; fi

# Verify no regressions
git diff --stat

Safety Rules

Before applying ANY improvement:

1. •✅ Verify syntax is valid
2. •✅ Ensure tests still pass (if available)
3. •✅ Preserve original functionality
4. •✅ Check no breaking changes introduced
5. •✅ Validate code compiles/runs
6. •✅ NEVER auto-apply critical security fixes - flag for manual review

Security Priority

CRITICAL: Security issues require special handling:

• •SQL Injection → FLAG, don't auto-fix (needs validation)
• •Hardcoded secrets → FLAG, don't auto-fix (needs secret rotation)
• •XSS vulnerabilities → FLAG, don't auto-fix (needs testing)
• •Auth issues → FLAG, don't auto-fix (needs security review)

For security fixes, provide the fix but require manual review and application.

Output Guidelines

Be Specific:

• •Include exact line numbers
• •Show before/after code
• •Explain security impact
• •Provide CVE references if applicable

Be Practical:

• •Focus on high-impact changes
• •Consider implementation effort
• •Prioritize security over style

Be Safe:

• •Don't break existing functionality
• •Maintain backward compatibility
• •Preserve test coverage
• •Flag security issues for review

Priority Levels

Remember: Security first, quality second, style third. Critical security issues must be flagged but not auto-applied without review.