Reorganize a branch's commit history into a few logical commits without changing file contents. Create a backup first, propose groups for approval, remove merges from main, and check the resulting history and working tree.
Reorganize messy branch commits into a small set of logical, meaningful commits without changing any content. Drops merge-from-main commits. Safe: creates a backup branch first.
Review the instructions the agent will receive before you install.
Reorganize the commits on the current branch into a small number of logical commits. Do NOT change any file content — only the commit structure changes.
git status --short
If there are uncommitted changes, stop and tell the user to commit or stash them first.
git log main..HEAD --oneline
git diff main..HEAD --name-only
List every file changed vs main and every commit on the branch (excluding merge commits from main).
git branch backup/<current-branch-name>
Tell the user the backup exists so they can recover if needed.
git reset --soft main
git restore --staged .
All branch changes are now in the working tree, unstaged. No content has changed.
Read the changed files and the original commit messages to understand what the work covers. Group related files into logical commits. Typical groups:
Use the changelog files (if any) as a strong hint — each changelog entry often maps to one commit.
Present the proposed grouping to the user and ask for confirmation before committing.
For each group, stage only the relevant files and commit with a clear message following the project's conventions:
git add <file1> <file2> ...
git commit -m "..."
Use conventional commit prefixes if the project uses them (feat:, fix:, refactor:, test:, chore:).
git log main..HEAD --oneline
git diff main..HEAD --name-only
git status --short
Confirm:
main is identical to beforeThe branch history has been rewritten. Tell the user they will need to git push --force-with-lease when they are ready to update the remote. Do NOT push automatically.
git reset --hard backup/<branch-name>.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Create changelog files for significant changes in a pull request, a proposed code change. Describe effects users will notice and organize entries by PR number and change type, such as features or fixes.
Review and improve code changes on the current branch using Pipecat conventions. Refine names and structure, add type hints and documentation, check example patterns, and make conservative performance improvements while preserving compatibility.
Review GitHub pull requests with specialized agents that check for clear bugs and violations of project instructions in CLAUDE.md. Validate bug findings before posting focused comments on the affected lines, with fix suggestions where appropriate.
Add or improve Google-style docstrings, the explanations embedded in Python code, for modules and classes. Document constructor arguments, public methods, configuration fields, and enum values while preserving existing documentation that already meets the project’s conventions.
Draft or update GitHub pull request descriptions using the actual changes and related context. Explain the problem, changed behavior, and review concerns in plain language, including breaking changes and explicit issue-closing references when applicable.
Submit current work as a GitHub pull request, handling relevant uncommitted changes and reviewing prose before pushing. After creating the PR, run companion skills to generate changelog files, update the description, and return its URL.