PR Ready Skill

You are an expert at preparing clean, reviewable pull requests. When this skill is invoked, prepare the current branch for a pull request.

What This Skill Does

Cleans up commits, writes a PR description, runs checks, and ensures the branch is ready for review.

Step-by-Step Instructions

1. Assess the current state. Run:

   • git status to check for uncommitted changes
   • git log --oneline main..HEAD (or the appropriate base branch) to see all commits
   • git diff main..HEAD --stat to see all changed files

2. Handle uncommitted changes. If there are uncommitted changes:

   • Stage and commit them with an appropriate conventional commit message
   • Or ask the user what to do with them

3. Review commit history. Check if commits follow conventional commit format:

   • feat: for new features
   • fix: for bug fixes
   • docs: for documentation
   • refactor: for code restructuring
   • test: for adding tests
   • chore: for maintenance tasks
   • If commits are messy, suggest an interactive rebase to clean them up (but ask first)

4. Run project checks. Execute in order:

   • Linting: npm run lint or equivalent
   • Type checking: npx tsc --noEmit if TypeScript
   • Tests: npm test or equivalent
   • Build: npm run build or equivalent
   • Fix any failures before proceeding

5. Check for common PR issues:

   • Console.log or debug statements left in
   • Commented-out code
   • TODO comments that should be resolved
   • Large files that should be broken up
   • Missing tests for new functionality
   • Unresolved merge conflicts

6. Write the PR description. Generate a clear description:

## Summary
Brief description of what this PR does and why.

## Changes
- Bullet list of specific changes made

## Testing
How the changes were tested.

## Notes for Reviewers
Anything reviewers should pay attention to.

7. Create the PR. Use gh pr create with the title and body. Use conventional format for the title (e.g., feat: add user authentication).

Guidelines

• Keep PRs focused. If the diff touches unrelated areas, suggest splitting into multiple PRs.
• The PR title should be concise (under 72 characters) and follow conventional commit format.
• Link to any relevant issues using Closes #123 or Fixes #123 in the description.
• If the PR is large (more than 500 lines changed), add a section explaining how to review it.
• Do not force-push to shared branches without user confirmation.
• Ensure the branch is up to date with the base branch before creating the PR.
• If there are merge conflicts, resolve them before creating the PR.