What does this skill do, and when should you use it?
This skill provides a strict workflow for creating pull requests, ensuring each PR links an approved issue, has exactly one type label, and passes automated checks. It defines branch naming rules, PR body format, commit message conventions, and validation via GitHub Actions. Ideal for teams seeking consistency and traceability in their PR process.
The skill guides through: verifying issue has status:approved label, creating branch in type/description format, using conventional commits, running shellcheck on modified scripts, opening PR with template, adding one type label, and waiting for automated checks. It also validates commit messages against a regex and maps commit types to PR labels.
- Development teams wanting to enforce that every PR references an approved issue, reducing orphan PRs.
- New projects establishing branch naming and commit conventions for clear history.
- Maintainers of repositories that use GitHub Actions to automatically block non-compliant PRs.
- Contributors needing quick guidance to submit a compliant PR and avoid CI failures.
- Teams adopting Conventional Commits to align commit types with PR labels.
How do you install this skill?
- The skill depends on GitHub and GitHub Actions, which may be inaccessible from mainland China; consider providing alternatives or explicitly noting network requirements.
- The skill documentation is in English only, without a Chinese version, potentially hindering Chinese users.
- Some rules, such as mandatory issue linkage, may not fit all projects or teams; verify compliance with your organization's policies before use.
- Shell / CLI
- Local filesystem
GitGitHub CLI (gh)shellcheck
This skill is part of the gentle-ai collection; install the collection via the repo: git clone https://github.com/Gentleman-Programming/gentle-ai, then copy the internal/assets/skills/branch-pr folder to your skills directory.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/Gentleman-Programming/gentle-ai.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/internal/assets/skills/branch-pr" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Creating PR for feat/user-login, please follow the branch-pr skill.
Trigger the skill by mentioning its description when creating a PR, e.g., "Creating PR for feat/user-login, please follow the branch-pr skill." Or manually follow the workflow: create branch feat/my-feature from main, run shellcheck, push and create PR, add type label. Specific commands are provided: gh pr create --title "feat(scope): description" --body "Closes #N".
What are this skill's strengths and limitations?
- Enforces PR standards, improving consistency.
- Enhances traceability via mandatory issue and type labels.
- Automated checks reduce manual review burden.
- Clear rules for branch names and commit messages.
- Provides only guidance; actual enforcement depends on GitHub Actions workflow not included.
- Requires all PRs to link an approved issue, which may not fit every project's flow.
- Relies on shellcheck, may not apply to non-shell projects.
- Skill itself lacks tests; relies on external CI for verification.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Branch & PR Discipline Enforcer this page | 49 · Use with care | ★ 7.6k | 3d ago | MIT |
| Engram PR Workflow | 54 · Use with care | ★ 7.1k | 4d ago | MIT |
| Ship a PR (e2e repo PR delivery workflow) | 59 · Recommended | ★ 8.7k | 1d ago | Apache-2.0 |
| writing-pr: PR Title & Body Standards | 58 · Recommended | ★ 8.7k | 1d ago | Apache-2.0 |
| Engram Commit Hygiene | 43 · Not recommended | ★ 7.1k | 4d ago | MIT |
How did FollowSkills review this skill?
The skill mandates linking an approved issue and defines clear checks, which helps prevent unauthorized changes. However, it lacks explicit least-privilege or user-confirmation details, relying on external GitHub Actions enforcement whose configuration is not verifiable. No malicious behavior found, but data flow and external impact transparency are incomplete, so points deducted.
The skill provides clear rules and commands, but as documentation, there are no automated tests covering its key paths. It relies on shellcheck and GitHub Actions, but it is not verified these checks are fully implemented within the skill. Error handling is not well described, and failure messages are unclear, thus only 7 points.
The skill's scenario is clear, suitable for creating PRs, but it does not specify non-fit cases (e.g., non-GitHub environments). Trigger conditions are specific, but boundaries are incomplete. As it is in English, support for Chinese users is limited, and GitHub may be inaccessible from mainland China, so points deducted.
The skill document is well-structured with version and author, but lacks a changelog and known limitations. It depends on external templates and CI, with no full installation or dependency notes. Maintenance responsibility is not clear, so points deducted.
The skill describes a complete PR creation flow with clear expected outputs, but lacks empirical evidence of actual effectiveness. Commands and templates require manual execution and may deviate. Marginal value is limited since most developers are familiar with GitHub PR workflows, hence only 7 points.
Static review cannot execute any tests, and the repository's CI and tests mainly cover the main project, not this skill. The skill provides no verifiable execution evidence and relies on external services, so only 3 points.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →