菜单
Squashes WIP commits into clean commits before merge. Use when the user says squash commits, clean up commits, squash these, combine commits, or I have a bunch of WIP commits. Apply when the user wants to tidy history before opening a PR even if they don't say 'squash'.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | squash-commits |
| description | Squashes WIP commits into clean commits before merge. Use when the user says squash commits, clean up commits, squash these, combine commits, or I have a bunch of WIP commits. Apply when the user wants to tidy history before opening a PR even if they don't say 'squash'. |
The git mechanics here (interactive rebase, merge --squash) are project-agnostic. The
commit-message format is project-specific. Read it from .agents/project-contract.md (shared contract), then layer .agents/project-contract.personal.md on top if it exists (personal entries win where they overlap):
## Commit conventions: subject-line format, issue-ref prefix, wrap width, and what the body
should cover. If the project contract has no ## Commit conventions section, fall back to
## Tracker → Issue ref format for the prefix and use a sensible default (imperative subject,
72-char wrap, body explains the why).## Branch / plan conventions: Base branch (the target you squash a feature branch into)
and the branch-name pattern.## Voice: the voice config to apply to the squashed message (see Voice below).## Attribution marker: whether the project defines one (see Attribution below).If no project contract is present, ask the user for the commit-message convention rather than inventing one.
Invoke when the user wants to squash multiple WIP or incremental commits into one clean commit (or a small number of logical commits) before merging.
git log --oneline to see the rangegit merge --squashFormat the subject line per the project contract's ## Commit conventions (issue-ref prefix from
## Tracker → Issue ref format, imperative description, project contract wrap width):
[<issue-ref>] Brief imperative description
Optional body explaining what changed and why. Wrap per the project contract (default 72 characters).
Use the project contract's Base branch wherever a target branch is referenced:
# Squash last N commits interactively
git rebase -i HEAD~N
# Or squash a branch into one commit from the base branch (see project contract Base branch)
git merge --squash <feature-branch>
git commit
Flag if any commits in the range should be kept separate rather than squashed.
Apply the voice config from the project contract's ## Voice section (e.g. .agents/style/voice.md) to the
squashed commit message.
Pull the specifics from the project contract's ## Commit conventions section. Convention-independent rules
that hold across projects:
## Tracker → Issue ref format), when the project uses one## Commit conventions defines an enforced subject-line regex, every squashed
subject must match itYou ask: use the squash-commits skill on these 4 commits
You get:
Proposed Squashed Message
PROJ-1234 Clear overflow lock after facet deselect
Adds a regression test covering the deselect path. Lock was leaking from
the no-results branch of ajaxComplete.
Commands
git rebase -i HEAD~4
# mark commits 2–4 as `squash`
Notes
- WIP commits collapse cleanly; no commit in the range warrants staying separate.
commit-message-writer (writes the squashed commit message)organize-commits (use when staging working-tree changes from scratch rather than collapsing existing commits)summarize-commits (write the PR description after squashing)Validates a change in the browser using the project's sanctioned browser-inspection MCP, navigating pages, inspecting DOM/console/network, capturing screenshots. Use when the user says browser check, validate locally, test this in the browser, check the console, does this look right, or check this page. Apply when validating any frontend change even if the user does not say 'browser check'.
Writes closure notes for a completed ticket/issue. Use when the user says close this ticket, write closure notes, ticket is done, wrap up this ticket, or I'm closing [issue-ref]. Apply when the user is finishing a ticket even if they don't say 'closure notes'.
Writes QA steps for a ticket or PR. Use when the user says write QA steps, add testing instructions, how do I test this, write the QA section, or what should QA check. Apply when the user is preparing a ticket or PR for review and needs test instructions.
Summarizes commits into a PR description, changelog, or sprint summary. Use when the user says summarize these commits, write a PR description, what changed in this branch, write release notes, or sprint summary. Apply when the user shares a git log and wants a human-readable summary.
Deeper refinement of a ticket/issue to advance it toward Ready for Estimation or Ready for Dev. Use when the user says refine this ticket, prep this ticket, get this ready for estimation, write up the ticket body, this ticket needs more detail, or fill in the AC. Apply after triage when a ticket needs full acceptance criteria, implementation details, and LOE-readiness.
Critically reviews Drupal PHP, Twig, SCSS, or config for correctness, security, performance, and project standards. Use when the user says review this Drupal code, critique this, is this correct, check my service/hook/template, or what's wrong with this. Apply when the user shares backend Drupal code and wants a quality check even if they don't say 'review'.