SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsajiang-git-commit-pr

ajiang-git-commit-pr

Coding & development

View repository

Updated 10-16 12:15

About this skill

Commit code and create a PR

Choose by task: commit only, create a PR, or commit and create a PR; when only push is required, check the commits to be pushed and the remote target, then push.

Common rules

  • Only handle changes for this task and protect existing user modifications; do not automatically reset, clean, stash, or overwrite unrelated work.
  • Committing, pushing, creating a PR, and merging follow the current authorization. Creating a PR includes the source branch needed for publication and does not include merging changes directly into the target branch.
  • Commit messages and PR descriptions should be concise and follow the project style; do not add AI signatures, generated markers, or unrelated email addresses.
  • Do not commit credentials, and do not force push, modify Git configuration, or bypass hooks without authorization. When there are no changes, do not create an empty commit.

Mode 1: Commit only

  1. Read the project Git rules and run git status、git diff、git diff --cached and git log --oneline -5to confirm the repository, branch, scope of changes, and commit style. If it is not a Git repository, explain the reason and do not initialize it yourself.
  2. Run checks related to the content to be committed. If existing dirty files affect the results, verify in an isolated copy when necessary.
  3. Stage this task's changes using specific file paths; when a file contains unrelated modifications, separate this task's part and do not directly git add -A. If ownership cannot be safely determined, explain the specific issue.
  4. Check the staged diff and commit. The commit message should describe the actual changes and only reference real issues; changes with different purposes should be split into separate commits as needed.
  5. After committing, check git status and the commit SHA. If a hook fails, fix the relevant cause and retry; do not bypass checks, and do not amend existing commits for this.

Mode 2: Create a PR

  1. Confirm the source branch, the PR's target repository, target remote, and target branch. Determine them according to user specification, project rules, or existing PRs; they cannot default to local main or origin/main. Ask again if the target is unclear.
  2. You must first complete sync with the latest upstream and business conflict check: fetch the latest target, integrate it into the PR branch, check for textual and business conflicts, and verify the integrated result. Perform this step for regular directories, worktrees, and forks alike.
  3. Review the commits and full diff between the latest target and the source branch, and confirm that the PR includes only this scope. When only PR creation is required, do not casually commit uncommitted changes of unknown origin.
  4. Use a concise title and description to clearly state the problem, final behavior, and actual verification. Write multi-line descriptions to a file and pass them via gh pr create --body-file ; do not include discussion history or unimplemented plans.
  5. Before publishing, fetch again and verify the target SHA. If the target has advanced, resync, check, and verify the affected paths, then push the source branch and create the PR. Unresolved conflicts or failed key verification must not be reported as a completed PR; when unable to continue, deliver the specific blocker.
  6. Create the PR with the explicitly specified target repository, base, and head, and check the real URL. Report the verified target SHA, final source SHA, and PR URL; a pass on an old target cannot substitute for the current result.

Mode 3: Commit and create a PR

First commit according to Mode 1, then sync, verify, and create the PR according to Mode 2. Do not skip integration verification against the latest upstream just because pre-commit checks were just performed.

When the target branch needs to be merged

Execute only when the task includes merging. Check the target worktree and existing changes, merge according to the project strategy, and verify the final target state; do not forcibly modify the references of an already checked-out target, and do not automatically treat PR branch verification as verification after the target merge.

Output Results

Report the completed operations, commit SHA, pushed branch or PR URL, and any unfinished items. When CI needs to be checked, confirm the actual results, and report local checks and remote CI separately.

For multiple commits or merges, you can use Git operation records to save the scope, version, and verification results.