القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
استنادا إلى تصنيف SOC المهني
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/PX4/PX4-Autopilot --skill prيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
Create a conventional commit for PX4 changes
Substance-focused review of a PX4 pull request — merit, first-principles correctness, architecture fit. Produces a debrief for the user and a draft review comment.
Rebase a branch onto main, handling squash-merged parent branches cleanly
| name | pr |
| description | Create a pull request with conventional commit title and description |
| argument-hint | [optional: target branch or description] |
| allowed-tools | Bash, Read, Glob, Grep |
The user is the author: no Co-Authored-By, no "Generated with Claude"
footers. AI disclosure lives in the commit trailers (Assisted-by:), not in
the PR body.
Check branch. If on main, create a feature branch <username>/<description>
where <username> comes from gh api user --jq .login.
Gather context: git status, git log --oneline main..HEAD,
git diff main...HEAD --stat, check for remote tracking branch.
Sanity-build the targets we care about. Fix any build errors before opening the PR:
make px4_fmu-v6x — hardware targetmake px4_sitl — simulationPR title: type(scope): description — under 72 chars, covers the
overall change across all commits. This becomes the squash-merge commit
message.
PR body: concise and terse — do not restate what the diff already shows (no file-changed lists, no code snippets that reproduce the diff). Use exactly three sections, in order: ## Summary, ## Problem, ## Solution. If the PR closes a GitHub issue, the first line of ## Summary must be fixes #<N>, then a blank line, then the summary text. No ## Test plan section, no boilerplate, no Claude attribution. Use markdown (links, code blocks, lists) only when warranted. Never state testing that did not happen: ask the user what they actually ran beyond the builds in step 3, report exactly that, and say so plainly when something is untested.
Push with -u if needed, then gh pr create. Default base is main
unless user says otherwise.
Return the PR URL.
If the user provided arguments, use them as context: $ARGUMENTS