Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com> Signed-off-by: Ramon Roche <mrpollo@gmail.com> Co-authored-by: Ramon Roche <mrpollo@gmail.com>
1.5 KiB
name, description, argument-hint, allowed-tools
| name | description | argument-hint | allowed-tools |
|---|---|---|---|
| pr | Create a pull request with conventional commit title and description | [optional: target branch or description] | Bash, Read, Glob, Grep |
PX4 Pull Request
No Claude attribution anywhere (no Co-Authored-By, no "Generated with Claude").
Steps
-
Check branch. If on
main, create a feature branch<username>/<description>where<username>comes fromgh 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— simulation
-
PR title:
type(scope): description— under 72 chars, covers the overall change across all commits. This becomes the squash-merge commit message. -
PR body: start with a plain leading paragraph explaining what the PR does and why. No headings (
## Summary,## Test plan, etc.), no boilerplate, no Claude attribution. Use bullet lists only to enumerate discrete changes; don't force prose into bullets. Describe testing inline if relevant, no separate test plan section. Use markdown (links, code blocks, lists) only when warranted. Keep it concise and well-formatted. -
Push with
-uif needed, thengh pr create. Default base ismainunless user says otherwise. -
Return the PR URL.
If the user provided arguments, use them as context: $ARGUMENTS