菜单
Create a pull request or merge request from the current branch by detecting the Git host, choosing a target branch, generating a title and body from branch commits, and using the provider-appropriate CLI or API.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Plan coding work as a compact implementation-step bundle with a conservative research decision, high-level overview first, and planning artifacts written only under .steiner/plans/YYYY-MM-DD_FEATURE_NAME/. Use when invoked by name or when asked to plan a feature, refactor, migration, or other code change. This skill plans only — it never writes, edits, or refactors implementation code, and never skips ahead to building. If only the skill name is given, ask for a high-level description first before writing planning files.
Analyze branch changes for code quality improvements across reuse, simplification, efficiency, and altitude categories using parallel sub-agents. Produces a report and fix plan, then runs an approved fix/review loop. Use on a feature branch to clean up before review.
Execute an approved coding plan as serial-first implementation steps with tight scope control, planner-defined verification strategy, and isolated Steiner delegation/worktree execution when available. Use when planning is complete and the task should be implemented from the planner's artifacts.
Review coding changes against the approved plan, identify concrete bugs, regressions, and plan-adherence gaps, run approved isolated fix passes, then close the loop with optional planning-doc cleanup and PR/MR creation. Use after execution is complete.
| name | pull-request |
| description | Create a pull request or merge request from the current branch by detecting the Git host, choosing a target branch, generating a title and body from branch commits, and using the provider-appropriate CLI or API. |
Use this skill to create a PR/MR from the current branch. It works independently of the plan-implement-review loop. Users may invoke it at any time.
The skill detects the Git hosting provider, selects a target branch, assembles a title and body from branch history, and creates the PR/MR using the provider-appropriate method. It must ask for user confirmation before pushing or creating.
Stop and report blockers instead of widening scope.
origin.origin/mainorigin/masterInspect git remote get-url <remote> and match the hostname heuristically. Allow override if the user corrects the detected provider.
| Hostname pattern | Provider |
|---|---|
github.com | GitHub |
gitlab.com or known self-hosted GitLab | GitLab |
dev.azure.com or *.visualstudio.com | Azure DevOps |
bitbucket.org | Bitbucket Cloud |
bitbucket.* or user-declared | Bitbucket Server/DC |
gitea.*, codeberg.org, forgejo.* | Gitea/Codeberg/Forgejo |
If no pattern matches, ask the user to identify the provider or report that automatic creation is not supported.
Before attempting creation, verify the expected auth tool is available:
gh CLI must be installed and authenticated (gh auth status).git must be able to push to the remote (push-options path requires no extra tool).az CLI must be installed and the devops extension configured (az extension list-available).curl REST calls with an app password or token. Ask the user to confirm credentials are available.tea CLI is preferred; otherwise fall back to curl REST calls.If the preferred tool is missing, attempt the fallback path or report the blocker clearly.
Build the PR/MR title and body from:
git log <target>..<branch> --format=%s).git diff <target>...<branch>) for the most significant files.Keep the body concise. Do not dump full diffs into the description unless the user explicitly asks.
Use only the flow matching the detected provider. Confirm before pushing or creating.
gh pr create --title "<title>" --body "<body>" --base <target> --head <branch>
gh fails, report the error and suggest manual creation via the web UI.git push -o merge_request.create -o merge_request.title="<title>" -o merge_request.description="<body>" -o merge_request.target=<target> <remote> <branch>
glab CLI if available:
glab mr create --title "<title>" --description "<body>" --source-branch <branch> --target-branch <target>
az repos pr create --title "<title>" --description "<body>" --source-branch <branch> --target-branch <target> --repository <repo>
az repos pr create fails, report the error and suggest manual creation.curl:
curl -X POST -u <user>:<app_password> \
-H "Content-Type: application/json" \
https://api.bitbucket.org/2.0/repositories/<workspace>/<repo>/pullrequests \
-d '{
"title": "<title>",
"description": "<body>",
"source": { "branch": { "name": "<branch>" } },
"destination": { "branch": { "name": "<target>" } }
}'
curl:
curl -X POST -u <user>:<token> \
-H "Content-Type: application/json" \
https://<host>/rest/api/1.0/projects/<project>/repos/<repo>/pull-requests \
-d '{
"title": "<title>",
"description": "<body>",
"fromRef": { "id": "refs/heads/<branch>", "repository": { "slug": "<repo>", "project": { "key": "<project>" } } },
"toRef": { "id": "refs/heads/<target>", "repository": { "slug": "<repo>", "project": { "key": "<project>" } } }
}'
tea CLI if installed:
tea pr create --title "<title>" --body "<body>" --base <target> --head <branch>
curl:
curl -X POST -H "Authorization: token <token>" \
-H "Content-Type: application/json" \
https://<host>/api/v1/repos/<owner>/<repo>/pulls \
-d '{
"title": "<title>",
"body": "<body>",
"head": "<branch>",
"base": "<target>"
}'
Before pushing or creating:
After the PR/MR is created, report:
If creation is unsupported or blocked, report the reason and suggest manual next steps. Unsupported creation does not invalidate the branch or commits.