Skip to main content

pr

Create a pull request with conventional commit title and description

소스 정보

저장소
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에서 보기