PR Simplification

Trim complexity that accumulated during development. This is NOT a code review — focus on removing cruft, not evaluating design decisions.

1. Understand the Changes

Determine the PR's base branch and review the full diff and changed files to understand what was built.

2. Look for Accumulated Cruft

During development, code often accumulates:

3. Check for Over-Engineering

Look for complexity added "just in case" that isn't actually needed:

• Unused flexibility: Config options, parameters, or generics that only have one value/type
• Premature abstraction: Interfaces/base classes with single implementation
• Dead code paths: Branches that can never execute given current callers
• Wrapper functions: Functions that just call another function (inline them)
• Speculative generality: "We might need this later" code with no current use

Ask: "Is this complexity earning its keep, or was it added speculatively?"

4. Check for Common Anti-Patterns

Backwards Compatibility Hacks

If you're not shipping a public API, remove:

• Renamed unused _vars kept for "compatibility"
• Re-exported types that nothing imports
• // removed comments marking deleted code
• Deprecated function wrappers

Error Handling Theater

Remove defensive code that can't actually help:

• Try/catch that just re-throws
• Null checks after operations that guarantee non-null
• Type assertions immediately after type guards
• Validation of values from trusted internal sources

Copy-Paste Artifacts

Look for:

• Duplicate logic that should be a shared function
• Similar but slightly different implementations
• Code comments that describe a different function

5. Clean Up Development-Context Comments

Comments written during development often reference context that won't exist for future maintainers:

Reference PR/Review Context

Reference PRD/Issue Context

Temporal References

Rule of thumb: If a comment only makes sense to someone who read the PR, rewrite it or delete it.

6. Address PR Review Comments

If there are review comments from GitHub Actions, reviewers, or automated tools — address substantive findings, verify they're still valid (reviewers see old commits), and explain trade-offs if not implementing a suggestion.

7. Verify

Run the project's linter, build, and tests to verify nothing broke. Check project docs (README, CONTRIBUTING, CLAUDE.md) for project-specific commands.

Output

Summary table of changes made:

Risk levels:

• Low: Removed dead code, comments, or unused imports
• Medium: Simplified logic, removed defensive code
• High: Changed behavior, removed "defensive" error handling

If no changes needed, state that the code is already clean and why.

Gotchas

• Named booleans like isStarting are often MORE readable than inlining conditions. Prefer clarity over minimal code.
• Shell constructs like $(), &&, and variable assignments in Bash calls can trigger permission prompts. Prefer simple, single-command calls when possible.

Quick Checklist

• No commented-out code remaining
• No TODO comments for completed work
• No debug logging/print statements
• No unused imports or variables
• No single-use abstractions
• No duplicate code blocks
• No PR/PRD/review-context comments (rewritten for maintainers)
• All tests pass
• Linting passes

$ARGUMENTS