X-Financial/.codex/skills/split-commit-and-push/SKILL.md

name, description

name	description
split-commit-and-push	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.