القائمة
Prepare, validate, and send or update a pull request with full due diligence
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/MystenLabs/sui --skill send-prيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | send-pr |
| description | Prepare, validate, and send or update a pull request with full due diligence |
Prepare and send (or update) a pull request. Follow every step below in order. If any step fails trivially (lint warning, minor test fix, formatting), fix it and continue. If a failure is non-trivial (widespread test breakage, unclear intent), STOP and report the failure.
Retrieve the GitHub username from git config:
GH_USER=$(git config github.user || gh api user -q .login)
Store this as $GH_USER — it is used for branch naming in later steps.
Determine the base branch for this PR. If a PR already exists, use its base branch. Otherwise, check if the branch was created from another feature branch (e.g. git log --oneline --graph or tracking info). Default to $BASE if unclear. Store this as $BASE — all subsequent steps that reference the upstream use $BASE instead of hardcoding $BASE.
Verify that the author and committer for every commit on this branch match the configured git identity:
EXPECTED_NAME=$(git config user.name)
EXPECTED_EMAIL=$(git config user.email)
git log $BASE..HEAD --format='%an%n%ae%n%cn%n%ce' | sort -u
Every name returned should equal $EXPECTED_NAME and every email should equal $EXPECTED_EMAIL. If any commit has a different author or committer, rewrite those commits using git rebase -x with git commit --amend --reset-author to align them with the configured identity. Do NOT use interactive rebase (-i).
First, check if there is an open PR for the current branch (gh pr view). Note the result — you will need it in Step 11. If a PR exists, use its base branch as $BASE.
Then ensure the branch name:
$GH_USER/, continue.main/master, create a new branch named $GH_USER/<short-description> based on the recent commit messages, switch to it, and continue.$GH_USER/ AND there is no open PR for it, rename it with git branch -m $GH_USER/<current-name>.$GH_USER/ AND there IS an open PR, do not rename. Continue with the current name.First, revert any simtest contamination: if Cargo.lock is dirty, check whether it contains simtest tokio patches (real_tokio, local path references to tokio). If so, run git checkout Cargo.lock to discard those changes. Only commit Cargo.lock changes that reflect real dependency additions from this branch.
Stage and commit all unstaged/untracked files EXCEPT:
DESIGN.md, a README, a docs/ page) should be committed like any other file.patches/ dir or Cargo.toml [patch] entries pointing at local tokio paths)All changes should go into a single commit with a concise single-line message. Do NOT include Co-Authored-By lines. Do NOT create separate commits for Cargo.lock, formatting, or other mechanical changes — everything goes into one commit that will be amended in Step 9.
If there is nothing to commit, move on.
Rebase the current branch onto $BASE. Fetch first.
Resolve merge conflicts automatically — read both sides, understand intent, and pick the correct resolution. Most conflicts in this codebase are mechanical (import ordering, adjacent additions, config entries). Only stop if a conflict involves genuinely contradictory logic where the correct resolution is ambiguous.
Run git diff $BASE...HEAD and review the full diff for obvious issues:
Obvious bugs & security issues - pause and alert the user
Obvious code quality issues:
dbg!, println!, temporary info!/warn! calls, any llm signature)todo!(), unimplemented!(), or FIXME markersFix anything found. Stage changes but do not commit yet — they will be amended in Step 9. If something looks intentional but questionable, note it to the user but continue.
Determine which packages were changed on this branch (compare against $BASE).
SUI_SKIP_SIMTESTS=1 cargo nextest run --no-capture -p <package>sui-e2e-tests: cargo simtest --no-capture -p sui-e2e-tests <test_filter>Fix trivial test failures (assertion message changes, snapshot updates, etc.) and re-run. Stage changes but do not commit yet — they will be amended in Step 9.
After simtest runs, ALWAYS revert Cargo.lock with git checkout Cargo.lock — simtest patches tokio locally which contaminates the lockfile with real_tokio entries that must never be committed.
If tests fail non-trivially, stop and report.
Run cargo xclippy -- -D warnings. Fix all warnings and errors. Stage changes but do not commit yet — they will be amended in Step 9.
Repeat until clean. If a clippy issue is non-trivial to fix, stop and report.
Run cargo fmt --all. If it produces changes, stage them but do not commit yet — they will be amended in Step 9.
If any commit on this branch touches crates/sui-protocol-config/src/lib.rs, run:
./scripts/update_all_snapshots.sh
Stage any snapshot changes but do not commit yet — they will be amended in Step 9.
All changes from Steps 4–8 should now be staged but uncommitted. Before amending, run git checkout Cargo.lock one final time to ensure no simtest contamination is staged. Then amend everything into the most recent commit on the branch using git commit --amend --no-edit. The goal is a clean history: no separate commits for formatting, clippy fixes, or lockfile updates.
Check ALL commits on this branch (vs $BASE) for Co-Authored-By lines mentioning claude or anthropic (case-insensitive), as well as Generated by Claude or similar AI attribution footers. If found, use git rebase -x with git commit --amend to strip those lines. Do NOT use interactive rebase (-i).
Push to the remote feature branch with git push -u origin HEAD. NEVER push to main or master.
If the remote branch exists and has diverged (due to rebase), force-push with git push --force-with-lease. This is expected after rebasing.
Check if a PR already exists for this branch (gh pr view).
gh pr create --draft. Write a title and body following the description guidelines below. Print the PR URL.Follow the repo template (.github/PULL_REQUEST_TEMPLATE.md): ## Description, ## Test plan, ## Release notes.
A description has two possible parts: the why and the what. Write the minimum that lets a reviewer approach the diff with the right context — for many PRs this is a single sentence.
The test for every sentence: does it tell the reviewer something the diff does not already make obvious? If not, cut it. When in doubt, write less — a one-line description is a good outcome, not a deficiency.
NEVER do these:
Example — a PR that tightens the PR-description rules in this very skill:
Only state what a reviewer genuinely needs in order to trust the change. Do NOT restate CI blockers — "unit tests pass", "clippy clean", "cargo fmt", "CI is green" — these are assumed for every PR and add zero information.
<area>.") rather than a paragraph of boilerplate.Check only the boxes whose surface this PR actually changes, and for each checked box write the user-visible impact and any action users must take. Leave the rest unchecked and empty. If nothing user-facing changed, leave all boxes unchecked.
One concise line describing the change in terms of its effect, matching the existing commit-message style of the repo. No type-prefix unless the surrounding history uses one.