61 lines
2.8 KiB
Markdown
61 lines
2.8 KiB
Markdown
---
|
|
name: split-commit-and-push
|
|
description: Use when the user asks to commit or push code and wants the changes split into logical git commits with clear commit messages, verification before commit, and a final push to the remote branch.
|
|
---
|
|
|
|
# Split Commit And Push
|
|
|
|
## Overview
|
|
|
|
This skill standardizes git delivery work when the user wants commits and a push, especially when the workspace contains multiple logical change groups. It helps Codex separate unrelated edits, write high-signal commit messages, verify the tree before each commit, and push only after the requested changes are complete.
|
|
|
|
## When To Use
|
|
|
|
- The user explicitly asks to `commit`, `push`, `提交代码`, `分批提交`, or asks for better commit descriptions.
|
|
- The workspace contains multiple change groups that should not be collapsed into one commit.
|
|
- The task needs a final remote push after verification.
|
|
|
|
## Workflow
|
|
|
|
1. Inspect `git status --short` and `git diff` to identify logical change groups.
|
|
2. Separate changes by user-visible outcome or engineering boundary. Do not mix unrelated docs, refactors, and UI tweaks in one commit unless they are inseparable.
|
|
3. Verify each change group before committing. Prefer targeted build/test commands that are cheap and relevant.
|
|
4. Stage only the files for the current group.
|
|
5. Write a commit message that states scope and result clearly.
|
|
6. Repeat for remaining groups.
|
|
7. Confirm branch and remote, then push the current branch to the requested remote.
|
|
|
|
## Commit Rules
|
|
|
|
- One commit per logical modification point.
|
|
- Do not include unrelated files just to keep the tree clean.
|
|
- Prefer non-interactive git commands.
|
|
- Do not rewrite history unless the user explicitly asks.
|
|
- If the same file spans multiple logical changes, split carefully instead of collapsing the work into one generic commit.
|
|
- Before pushing, make sure the working tree reflects the intended post-push state.
|
|
|
|
## Commit Message Rules
|
|
|
|
- Prefer concise prefixes such as `feat`, `fix`, `docs`, `refactor`, `style`, or `chore`.
|
|
- Mention the subsystem or page when useful, for example `feat(audit): connect rule center to asset APIs`.
|
|
- The subject should describe the delivered outcome, not just the files changed.
|
|
- When multiple commits are requested, ensure adjacent commit subjects are distinguishable.
|
|
|
|
## Verification Rules
|
|
|
|
- Run the smallest relevant verification for each batch.
|
|
- Report verification honestly in the final response.
|
|
- If push fails, report the exact blocker and leave the local commits intact.
|
|
|
|
## Example Outputs
|
|
|
|
- `feat(audit): connect rule center to live asset APIs`
|
|
- `docs(agent-plan): mark day 2 rule center integration complete`
|
|
- `style(audit): simplify list table interactions`
|
|
|
|
## Final Response Checklist
|
|
|
|
- List the commits in order.
|
|
- State the verification that was run.
|
|
- State whether push succeeded and which branch was pushed.
|