소스 정보
- 저장소
- PX4/PX4-Autopilot
- 최근 소스 활동
- 2026년 9월 27일 22:27
- 감지된 SKILL.md 언어
- 영어
- 스타
- 12,814
- 포크
- 16,165
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
SKILL.md 표시 중
SKILL.md
소스 지침 · 읽기 전용 미리보기- 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
# PX4 Pull Request
**The user is the author: no `Co-Authored-By`, no "Generated with <assistant>"
footers. Disclose AI assistance as the last line of the PR body, italicized:
`*Assisted-by: <tool>:<model-id>*`, matching the commit trailer.**
## Steps
1. Check branch. If on `main`, create a feature branch `<username>/<description>`
where `<username>` comes from `gh api user --jq .login`.
2. Gather context: `git status`, `git log --oneline main..HEAD`,
`git diff main...HEAD --stat`, check for remote tracking branch.
3. Sanity-build **one** target the change can actually affect — a board for
firmware changes, `px4_sitl` for POSIX-only or simulation changes. Skip the
build entirely when the diff cannot reach any target (submodule pointer
bumps, docs, ROMFS). Build with the `build-px4-linux` or `build-px4-macos`
skill. Fix any build errors before opening the PR.
4. PR **title:** `type(scope): description` — under 72 chars, covers the
overall change across all commits. If a maintainer squash-merges the PR,
this becomes the commit message.
5. PR **body:** as short as it can be while still landing the point — a
reviewer should take it in at a glance, and a long description is one
nobody reads. Sections, in order: `## Summary`, `## Problem`,
`## Solution`, a sentence or two each. Do not restate the diff (no
file-changed lists, no code snippets), do not mention CI, and do not repeat
what the title already says. If the PR closes an issue, the first line of
`## Summary` is `fixes #<N>`, then a blank line, then the summary. No
boilerplate.
6. Optional `## Testing` section after `## Solution`, only for substantial
testing: SITL scenarios, synthetic or replayed data, hardware-in-the-loop,
bench or flight tests. Building and unit tests are not testing; never
mention them. State what was run and what it showed, as tersely as the
other sections. Never report testing that did not happen: ask the user
what they actually ran.
7. Push with `-u` if needed, then `gh pr create`. Default base is `main`
unless user says otherwise.
8. Return the PR URL.
GitHub에서 보기