chore(skill): add split commit and push workflow

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

@@ -0,0 +1,60 @@
+---
+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.

.codex/skills/split-commit-and-push/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Split Commit and Push"
+  short_description: "Help split git changes into clear commits"
+  default_prompt: "Use $split-commit-and-push to group the current changes into logical commits and push the branch."