create-pull-request
Create a GitHub pull request following project conventions. Use when the user asks to create a PR, submit changes for review, or open a pull request. Handles commit analysis, branch management, PR template usage, and PR creation using the gh CLI tool.
Оригинален текст · няма потвърден превод на българскиПърво прочетете инструкцията.
Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.
GitHub хранилище- Звезди на репото
- 63 049
- Лиценз
- Не е посочен. Проверете в репозитория.
- Последна проверка на записа
- Няма посочена дата
Добавете в своя инструмент.
Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.
npx skills add cline/clineСтраницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.
Откъс от SKILL.md
Началото на файла на автора, без превод.
Create Pull Request
This skill guides you through creating a well-structured GitHub pull request that follows project conventions and best practices.
Prerequisites Check
Before proceeding, verify the following:
1. Check if gh CLI is installed
gh --version
If not installed, inform the user:
The GitHub CLI (
gh) is required but not installed. Please install it:
- macOS:
brew install gh- Other: https://cli.github.com/
2. Check if authenticated with GitHub
gh auth status
If not authenticated, guide the user to run gh auth login.
3. Verify clean working directory
git status
If there are uncommitted changes, ask the user whether to:
- Commit them as part of this PR
- Stash them temporarily
- Discard them (with caution)
Gather Context
1. Identify the current branch
git branch --show-current
Ensure you're not on main or master. If so, ask the user to create or switch to a feature branch.
2. Find the base branch
git remote show origin | grep "HEAD branch"
This is typically main or master.
3. Analyze recent commits relevant to this PR
git log origin/main..HEAD --oneline --no-decorate
Review these commits to understand:
- What changes are being introduced
- The scope of the PR (single feature/fix or multiple changes)
- Whether commits should be squashed or reorganized
4. Review the diff
git diff origin/main..HEAD --stat
This shows which files changed and helps identify the type of change.
Information Gathering
Before creating the PR, you need the following information. Check if it can be inferred from:
- Commit messages
- Branch name (e.g.,
fix/issue-123,feature/new-login) - Changed files and their content
If any critical information is missing, use ask_followup_question to ask the user:
Required Information
- Related Issue Number: Look for patterns like
#123,fixes #123, orcloses #123in commit messages - Description: What problem does this solve? Why were these changes made?
- Type of Change: Bug fix, new feature, breaking change, refactor, cosmetic, documentation, or workflow
- Test Procedure: How was this tested? What could break?