Menu
Create a pull request to apache/pulsar
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | pulsar-create-pr |
| description | Create a pull request to apache/pulsar |
| allowed-tools | Bash(gh *), Bash(find *), Bash(grep *), Read, Glob, Grep |
To create a pull request to the apache/pulsar repository, you can follow these steps:
Precondition: Before creating a pull request, ensure that checkstyle and spotless check tasks pass locally. This can be done by running the following command in the root directory of the pulsar repository:
./gradlew spotlessCheck checkstyleMain checkstyleTest
Fix any checkstyle or spotless issues that arise before proceeding to create the pull request.
${PULSAR_PR_BRANCH_PREFIX}[fix|improve|feat]-[brief-description].
[fix|improve|feat] prefix reflects the type of change, matching the semantic commit message types defined in @.github/workflows/ci-semantic-pull-request.yml.PULSAR_PR_BRANCH_PREFIX is typically set to the user's initials followed by a hyphen (e.g., my-).my-fix-auth-npe-in-some-scenario.
Create the branch using the following command:git switch -c [branch-name]
PULSAR_FORKED_REMOTE environment variable (default: forked). Set the upstream branch:
git push -u ${PULSAR_FORKED_REMOTE:-forked} [branch-name]
gh). Follow the format described in @.github/PULL_REQUEST_TEMPLATE.md and ensure the title matches the semantic conventions defined in @.github/workflows/ci-semantic-pull-request.yml.PULSAR_PR_REVIEWERS environment variable is set, request reviews from the specified reviewers using the GitHub CLI (gh).When referencing a PIP in the PR description header, include the PIP number such as PIP: 460 in the pull request description to provide context for reviewers. Link this to the PIP in the pip directory of the pulsar repository for easy access (for example, pip/pip-460.md).
When the PR is a fix for a specific issue, include the issue number in the PR description header (e.g., Fixes: #1234) to automatically link the PR to the issue on GitHub. If the issue is a task of an enhancement, use the format Closes: #1234 to indicate that the PR will close the issue once merged.
Design or refine an Apache Pulsar PIP (Pulsar Improvement Proposal) from a draft into a votable, minimal, 5-year-durable proposal. Runs multi-model multi-viewpoint reviews, an iterative minimalism-refinement loop to a fixpoint, and (when the PIP has a reference implementation) the full design-doc + code + CI pipeline. Use when asked to design a PIP, review/harden a PIP draft, or drive a proposal to "nothing left to take away."
Cherry-pick (backport) one or more apache/pulsar commits onto a release/maintenance branch, resolving conflicts and adapting for branch differences. Use this whenever the user asks to cherry-pick, backport, port, or "apply commit X to branch Y" — especially when porting commits from master to an older release branch (branch-4.0/4.1/4.2/3.x etc.), where the logging framework (slog vs slf4j) and build system (Gradle vs Maven) differ and naive cherry-picks fail to compile.
Review a GitHub PR locally using metadata and diff as context. Use when asked to review a pull request, check a PR, or analyze a PR. Outputs findings to terminal only — never posts GitHub comments.
Investigate test failures for a project using the Develocity REST API. Queries failed builds, extracts test and build failures with stacktraces.
Fix flaky tests in apache/pulsar. Investigates Develocity failures, analyzes root causes using git blame, fixes tests, verifies with invocationCount, and creates PRs.
Investigate failing GitHub Actions CI tests for a PR, a specific workflow run (by URL), or recent workflow runs. Auto-detects Maven vs Gradle for the target branch and parses failures in the right format. Downloads logs and optionally test report artifacts for deep analysis.