Setup Claude Code custom commands for code review and PR creation

setup-claude-commands.sh

#!/bin/bash
set -e

# Setup Claude Code custom commands for code review and PR creation
# This script is idempotent - safe to run multiple times

COMMANDS_DIR="$HOME/.claude/commands"
REVIEW_FILE="$COMMANDS_DIR/review.md"
CREATE_PR_FILE="$COMMANDS_DIR/create-pr.md"

echo "Setting up Claude Code custom commands..."
echo ""

# Create commands directory if it doesn't exist
if [ ! -d "$COMMANDS_DIR" ]; then
    mkdir -p "$COMMANDS_DIR"
    echo "✓ Created directory: $COMMANDS_DIR"
else
    echo "✓ Directory already exists: $COMMANDS_DIR"
fi

echo ""

# Create review.md
if [ -f "$REVIEW_FILE" ]; then
    echo "⚠ File already exists (not overwriting): $REVIEW_FILE"
else
    cat > "$REVIEW_FILE" <<'EOF'
You are an expert software engineering code reviewer tasked with conducting a comprehensive and detailed review of a pull request. Your goal is to provide high-quality, constructive feedback that helps improve the code's quality, maintainability, and overall project health.

Review Methodology:
1. Code Quality Assessment
- Analyze code against the repository's conventions
- Check for adherence to coding standards, naming conventions, and architectural principles
- Evaluate code structure, modularity, and readability
- Identify potential refactoring opportunities

2. Technical Evaluation
- Examine the implementation against the project's tech stack
- Verify correct usage of language-specific features and best practices
- Assess algorithmic efficiency and potential optimization points

3. Potential Issues Identification
- Conduct a thorough static code analysis
- Look for:
  * Logical errors
  * Edge case handling
  * Potential runtime exceptions
  * Memory management concerns
  * Concurrency and thread-safety issues

4. Performance Analysis
- Profile code performance implications
- Identify potential bottlenecks
- Suggest performance optimization strategies
- Compare current implementation with alternative approaches

## Identifying Changes to Review

Before reviewing, identify which commits and files are part of this branch:

1. **List commits unique to this branch:**
   ```bash
   git log --oneline <main-branch>..HEAD
   ```

2. **List changed files:**
   ```bash
   git diff --name-only <main-branch>..HEAD
   ```

3. **If both commands return 0 results**, the branch has already been merged. Review recent commits instead:
   ```bash
   git log --oneline -10 --stat
   ```

Replace `<main-branch>` with the repo's main branch (typically `master` or `main`).

Think harder and do a code review for current branch
EOF
    echo "✓ Created: $REVIEW_FILE"
fi

echo ""

# Create create-pr.md
if [ -f "$CREATE_PR_FILE" ]; then
    echo "⚠ File already exists (not overwriting): $CREATE_PR_FILE"
else
    cat > "$CREATE_PR_FILE" <<'EOF'
You are an expert software engineer tasked with creating a comprehensive pull request. Your goal is to generate a clear, informative PR description that helps reviewers understand the changes and their impact.

## Process

1. **Analyze the Changes**
   - Run `git diff main...HEAD` (or appropriate base branch) to see all changes
   - Run `git log main..HEAD` to review all commit messages in this branch
   - Understand what functionality was added/changed/fixed
   - Identify the type of change (feat, fix, refactor, docs, test, chore, etc.)

2. **Generate PR Title**
   - Use conventional commit format: `type(scope): brief description`
   - Examples: `feat(api): add user authentication`, `fix(db): resolve connection leak`

3. **Generate PR Description**

   Create a comprehensive PR description with the following sections in this exact order:

   ### Summary
   Provide a clear, concise summary (2-4 sentences) of what this PR accomplishes and why it exists.

   ### Changes
   - Bullet point list of key changes made in this PR
   - Focus on WHAT changed at a high level
   - Group related changes together
   - Include file-level changes if significant

   ### Benefits
   - Explain the positive impacts of these changes
   - What problems does this solve?
   - What improvements does this bring?
   - How does this benefit users/developers/the system?

   ### **PUBLIC**
   Analyze all commit messages and files changed in the current branch, then write a conventional commit message that summarizes the entire PR. This should be a single line in the format:
   ```
   type(scope): description
   ```
   Where:
   - `type` is one of: feat, fix, refactor, docs, test, chore, perf, style, build, ci
   - `scope` is the area of the codebase affected (optional but recommended)
   - `description` is a concise summary of all changes

   Examples:
   - `feat(auth): implement JWT-based authentication system`
   - `fix(api): resolve race condition in user session management`
   - `refactor(db): simplify connection pool configuration`

   ### How was it tested?
   - If this is a content-only change (docs, README, comments only), state: "Content-only change, no functional testing required"
   - If this is a refactor with existing test coverage, verify the existing tests still pass and state: "Refactor covered by existing test suite (X tests passing)"
   - If this adds new functionality:
     * Check for new/updated test files
     * List the types of tests added (unit, integration, e2e)
     * Mention test coverage if measurable
   - Ask the user: "Did you perform any exploratory/manual testing? If so, please describe the scenarios tested."
   - Include any specific test commands run (e.g., `./gradlew test`, `npm test`)

4. **Create the PR**
   - Use `gh pr create --title "..." --body "..."` with the generated title and description
   - Use a HEREDOC for the body to preserve formatting:
     ```bash
     gh pr create --title "type(scope): description" --body "$(cat <<'EOF'
     [full PR description here]
     EOF
     )"
     ```
   - Target the appropriate base branch (check current branch's upstream or default to main)

## Important Notes
- The **PUBLIC** section must use exactly that markdown formatting (`**PUBLIC**`)
- The **PUBLIC** section must be placed AFTER the Benefits section and BEFORE the "How was it tested?" section
- Ask clarifying questions if you're unsure about testing details
- Be thorough but concise - quality over quantity
EOF
    echo "✓ Created: $CREATE_PR_FILE"
fi

echo ""
echo "=========================================="
echo "Setup complete!"
echo ""
echo "Available commands:"
echo "  /review     - Comprehensive code review"
echo "  /create-pr  - Create PR with detailed description"
echo ""
echo "These commands are now available in all Claude Code sessions."
echo "=========================================="