How do I install the Reshape Pr Commits skill?

Run npx skillmds@latest add tomevault-io/reshape-pr-commits in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Reshape Pr Commits safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Reshape Pr Commits?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Reshape Pr Commits free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Reshape Pr Commits?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Reshape Pr Commits by tomevault-io — Agent Skill

Name: Reshape Pr Commits
Author: tomevault-io

Reshape Pr Commits

Reorganize the commits on the current PR branch into a clean, logically-grouped history with short one-line messages. Use when the user asks to tidy, squash, reshape, or clean up commits on the current branch or PR. ALSO proactively suggest this skill (ask, do not run unprompted) when the user signals a PR is finished or ready to review — e.g. "done with this PR", "ready for review", "let's open the PR", or just before calling `gh pr ready` / marking a draft ready — especially if `git log <base>..HEAD --oneline` shows many small WIP / fixup / "oops" commits. Use when this capability is needed.

tomevault-io Updated Sep 17, 2026

File contents

reshape-pr-commits

Goal

Turn the current branch's commit history into a set of commits that each represent one coherent logical change, with terse messages.

Proactive suggestion (when not explicitly invoked)

When the user signals the PR is done (see the trigger list in the description frontmatter), check git log <base>..HEAD --oneline. If the history is noisy — WIP / fixup / "oops" commits, or many tiny commits touching the same area — offer once: suggest running this skill before review. Accept either answer and move on; do not re-ask in the same session.

Non-negotiable guardrails

Only ever rewrite the current feature branch. Refuse if the branch is main, or if the current HEAD is already merged.
Always --force-with-lease, never --force.
Before touching history, surface the proposed final shape (one line per planned commit) and get explicit user approval.
If the branch has commits from other authors, stop and ask — do not silently re-author someone else's work.

Flow

Identify the base: git merge-base HEAD origin/main (or whatever the PR targets). Show git log --oneline <base>..HEAD.
Read the combined diff (git diff <base>..HEAD) to understand what actually changed, not just what the existing commit messages claim.
Propose a regrouping. Rules:
- One commit per logical change. Unrelated files → separate commits.
- Pure refactor and behavior change don't mix.
- Test additions usually ride with the code they test, unless the user is landing tests separately on purpose.
Present the plan as a numbered list: <type>(<scope>): <subject> + (optional) one-line rationale for why that split. Wait for approval.
Execute with git reset --soft <base> followed by staged git add + git commit per group. (Prefer this over interactive rebase — simpler, fewer merge conflicts, no editor dance.)
git push --force-with-lease.

Commit message rules

Follow the Commits section of CONTRIBUTING.md — type set, scope enumeration, subject rules, banned subjects, and body policy. Do not restate them here.

When in doubt

If the user's intent for the split is ambiguous (e.g. "clean this up" with 15 mixed commits), ask one clarifying question before proposing the plan — do not guess at ten different groupings.

Source: qualcomm/nexa-sdk — distributed by TomeVault.

---name: reshape-pr-commitsdescription: Reorganize the commits on the current PR branch into a clean, logically-grouped history with short one-line messages. Use when the user asks to tidy, squash, reshape, or clean up commits on the current branch or PR. ALSO proactively suggest this skill (ask, do not run unprompted) when the user signals a PR is finished or ready to review — e.g. "done with this PR", "ready for review", "let's open the PR", or just before calling `gh pr ready` / marking a draft ready — especially if `git log <base>..HEAD --oneline` shows many small WIP / fixup / "oops" commits. Use when this capability is needed.---# reshape-pr-commits## GoalTurn the current branch's commit history into a set of commits that eachrepresent one coherent logical change, with terse messages.## Proactive suggestion (when not explicitly invoked)When the user signals the PR is done (see the trigger list in the`description` frontmatter), check `git log <base>..HEAD --oneline`. Ifthe history is noisy — WIP / fixup / "oops" commits, or many tinycommits touching the same area — offer once: suggest running this skillbefore review. Accept either answer and move on; do not re-ask in thesame session.## Non-negotiable guardrails- **Only ever rewrite the current feature branch.** Refuse if the branch is `main`, or if the current HEAD is already merged.- **Always `--force-with-lease`**, never `--force`.- Before touching history, surface the proposed final shape (one line per planned commit) and get explicit user approval.- If the branch has commits from other authors, stop and ask — do not silently re-author someone else's work.## Flow1. Identify the base: `git merge-base HEAD origin/main` (or whatever the PR targets). Show `git log --oneline <base>..HEAD`.2. Read the combined diff (`git diff <base>..HEAD`) to understand what actually changed, not just what the existing commit messages claim.3. Propose a regrouping. Rules: - One commit per logical change. Unrelated files → separate commits. - Pure refactor and behavior change don't mix. - Test additions usually ride with the code they test, unless the user is landing tests separately on purpose.4. Present the plan as a numbered list: `<type>(<scope>): <subject>` + (optional) one-line rationale for why that split. Wait for approval.5. Execute with `git reset --soft <base>` followed by staged `git add` + `git commit` per group. (Prefer this over interactive rebase — simpler, fewer merge conflicts, no editor dance.)6. `git push --force-with-lease`.## Commit message rulesFollow the Commits section of[CONTRIBUTING.md](../../../CONTRIBUTING.md) — type set, scopeenumeration, subject rules, banned subjects, and body policy. Do notrestate them here.## When in doubtIf the user's intent for the split is ambiguous (e.g. "clean this up"with 15 mixed commits), ask one clarifying question before proposingthe plan — do not guess at ten different groupings.---> Source: [qualcomm/nexa-sdk](https://github.com/qualcomm/nexa-sdk) — distributed by [TomeVault](https://tomevault.io).

Frequently asked questions