Menu
Creates a pull request from a fork branch to kyma-project/kyma-environment-broker main.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Creates a pr-deploy PR in kyma/management-plane-charts to deploy a KEB PR to the kcp-dev cluster.
Fetches a KEB PR, generates targeted test cases from the diff, spins up a local k3d cluster, installs KEB, runs the tests, then tears down the cluster.
Reviews a PR against KEB conventions (step interface, storage access, docs metadata, FIPS compliance, etc.).
Drafts and creates a git commit following KEB commit message conventions.
Scaffolds a new KEB provisioning/deprovisioning/update step with implementation and test file.
| name | create-pr |
| description | Creates a pull request from a fork branch to kyma-project/kyma-environment-broker main. |
Create a pull request from the current fork branch to the upstream kyma-project/kyma-environment-broker repository.
/create-pr [optional hint about what changed]
Examples:
/create-pr/create-pr Add integration test for autoScalerMinAsk the user:
You are about to open a PR from branch
<current-branch>tokyma-project/kyma-environment-broker:main. Continue?
Stop if they say no.
The local main branch may be stale. Always diff against the upstream remote to get only the changes this branch uniquely introduces:
git fetch upstream main
git diff upstream/main...HEAD
The three-dot syntax (...) diffs from the merge-base, so only commits unique to this branch are shown — not unrelated upstream commits that the local branch happens to include.
If no upstream remote exists, fall back to origin/main:
git fetch origin main
git diff origin/main...HEAD
Read the diff carefully and summarize the most important changes as bullet points. Base the summary entirely on what the code actually changed.
Read .github/pull-request-template.md and use it as the body structure. Fill in the Description bullets from the diff.
Rules:
Closes #<issue>, Fixes #<issue>, or any issue-closing keywords unless the user explicitly asks.Ask the user:
Would you like to reference any related issues? (e.g.
See also #123) If yes, provide the issue number(s).
If yes, place the reference on the line immediately after **Related issue(s)** with no blank line between them. Use See also #<n> unless the user explicitly asks for a closing keyword.
Ask the user which changelog label to apply:
Which changelog label should this PR have?
kind/feature— New featurekind/enhancement— Enhancement to an existing featurekind/bug— Bug fix
Apply exactly one of these labels. No other labels unless the user explicitly requests them.
Derive the title from the diff:
feat:, fix:, chore: prefixes.Add integration test for autoScalerMin changes, Fix deprovisioning race conditionShow the user the full title + body and ask: "Shall I open the PR with this title and description?"
To determine <fork-owner> and the PR creator's GitHub username, run:
git remote get-url origin
gh api user --jq .login
Extract <fork-owner> from the origin URL. The PR creator's GitHub username comes from gh api user.
gh pr create \
--repo kyma-project/kyma-environment-broker \
--base main \
--head <fork-owner>:<current-branch> \
--title "<title>" \
--label "<chosen-label>" \
--assignee "<github-username>" \
--body "$(cat <<'EOF'
<body>
EOF
)"
Return the PR URL to the user once created.
--base main on kyma-project/kyma-environment-broker — never an upstream feature branch.Closes, Fixes, Resolves) unless the user explicitly asks.--no-verify or bypass any git hooks.kind/* label per PR.