菜单
Create a pull request from the current branch. Use when the user wants to open a PR, create a pull request, or push their branch up for review.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
End-to-end workflow for building out a ticket — write code, open a PR, watch it for CI, code review, and QA, then address feedback, push fixes, and converse with QA via /qa-manager comments. Use when the user wants to take a ticket through the full Cosmos PR review loop, drive a PR to green, or process reviewer/QA feedback on an open PR.
Autofix common code-quality issues by running a pipeline of focused sub-agents (one-class-per-file, etc.). Use when the user wants to clean up code smells, normalize file structure, or run autofix on a set of files.
Show a dashboard of actionable PRs you've authored. Use when the user wants to see their open PRs, check PR status, review their PR pipeline, or find PRs that need attention.
Review and interactively address PR comments. Use when the user wants to review PR feedback, go through PR comments, or address reviewer requests on a pull request.
Send a notification to the
This skill should be used proactively whenever Claude needs to interact with, test, validate, verify, or observe a terminal user interface (TUI). This includes after writing TUI code and wanting to confirm it works, when debugging TUI behavior, when asked to verify UI changes, when running end-to-end validation of a TUI application, or any time Claude determines that launching and driving a TUI programmatically would help complete the task. Do not wait for the user to ask — use this skill autonomously whenever TUI interaction would validate work or answer questions.
| name | gh:pr-create |
| description | Create a pull request from the current branch. Use when the user wants to open a PR, create a pull request, or push their branch up for review. |
| argument-hint | [base-branch] |
Create a well-titled, labeled pull request from the current branch.
$ARGUMENTS — Optional base branch (defaults to main).
Run these commands to understand what's being submitted:
git branch --show-current
git log main..HEAD --oneline
git diff main...HEAD --stat
git diff main...HEAD
Read the branch name, commit history, and full diff carefully. Understand what system components were modified and the nature of the changes.
The title MUST start with the branch name followed by a concise description of the changes.
Format: <branch-name> <short description>
Examples:
feature/auth-refresh Add token refresh flow with silent retryfix/null-cart Handle null cart edge case in checkoutchore/deps-update Bump React to v19 and fix breaking changesKeep the description part under ~60 characters. Focus on what changed and why, not how.
Write a Summary section with 2-10 bullet points covering:
Do NOT include a test plan section. Keep it concise — reviewers can read the diff.
Determine labels based on the system components touched in the diff. Look at the directories and files modified to infer which part of the system is affected.
Common label patterns (adapt to the repo's actual structure):
frontend — UI components, styles, client-side codebackend — API routes, server logic, middlewaredatabase — Migrations, schema changes, queriesinfra — CI/CD, Docker, deployment configs, IaCauth — Authentication/authorization relatedapi — API contracts, endpoints, OpenAPI specsdocs — Documentation changesconfig — Configuration, env vars, feature flagstesting — Test files, test utilitiesAlso add a type label:
feature — New functionalitybugfix — Bug fixchore — Maintenance, deps, refactoringhotfix — Urgent production fixBefore applying labels, check what labels actually exist on the repo:
gh label list
Only use labels that exist. If a good label doesn't exist, create it:
gh label create <name> --color <hex> --description "<description>"
git push -u origin $(git branch --show-current)
Then create the PR:
gh pr create --title "<title>" --body "<body>" --label "<label1>,<label2>"
Print the PR URL when done.
gh CLI for all GitHub interactions.