القائمة
Creates a pull request from a fork branch to kyma-project/kyma-environment-broker main.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.