Branch Pr
Open a compliant pull request for Agent Config repos with approved issues, correct branch names, and required labels.
Overview
Branch-pr is an agent skill for the Ship phase that walks you through Agent Config’s issue-linked PR workflow with branch naming, labels, and pre-merge checks.
Install
npx skills add https://github.com/fearovex/claude-config --skill branch-prWhat is this skill?
- 7-step workflow from approved issue verification through automated checks
- Every PR must link an approved issue and carry exactly one type:* label
- Branch names must match type/description regex for feat, fix, chore, docs, and related conventional types
- Requires shellcheck on modified scripts before opening the PR
- Blank PRs without issue linkage are blocked by GitHub Actions
- 7-step PR workflow
- 4 critical rules including one type:* label per PR
Adoption & trust: 1 installs on skills.sh; 1 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You are ready to submit changes but the repo blocks PRs that skip approved issues, wrong branch names, or missing type labels.
Who is it for?
Contributors to fearovex/claude-config (Agent Config) who want the agent to enforce the official PR ritual end to end.
Skip if: Generic open-source repos without issue-first GitHub Actions or repos that do not use the Agent Config label and branch conventions.
When should I use this skill?
When creating a pull request, opening a PR, or preparing changes for review in Agent Config.
What do I get? / Deliverables
You open a template-backed PR on a correctly named branch with one type:* label and checks passing so merge is unblocked.
- Pull request from the project template with issue link and type:* label
- Branch and commits that pass automated checks including shellcheck on scripts
Recommended Skills
Journey fit
How it compares
Use instead of ad-hoc “open a PR” chat when this repository’s GitHub Actions enforce issue linkage and label rules.
Common Questions / FAQ
Who is branch-pr for?
Anyone creating or reviewing pull requests in Agent Config who needs the enforced issue-first and type-label workflow spelled out for the agent.
When should I use branch-pr?
Use it in Ship (review) when creating a pull request, preparing a branch for submission, or helping a contributor open a PR after implementation.
Is branch-pr safe to install?
It is procedural documentation under Apache-2.0; confirm fit with your repo policies and review the Security Audits panel on this page before enabling in CI-heavy workflows.
SKILL.md
READMESKILL.md - Branch Pr
**Triggers**: creating a pull request, opening a PR, preparing a branch for review. ## When to Use Use this skill when: - Creating a pull request for any change - Preparing a branch for submission - Helping a contributor open a PR --- ## Critical Rules 1. **Every PR MUST link an approved issue** — no exceptions 2. **Every PR MUST have exactly one `type:*` label** 3. **Automated checks must pass** before merge is possible 4. **Blank PRs without issue linkage will be blocked** by GitHub Actions --- ## Workflow ``` 1. Verify issue has `status:approved` label 2. Create branch: type/description (see Branch Naming below) 3. Implement changes with conventional commits 4. Run shellcheck on modified scripts 5. Open PR using the template 6. Add exactly one type:* label 7. Wait for automated checks to pass ``` --- ## Branch Naming Branch names MUST match this regex: ``` ^(feat|fix|chore|docs|style|refactor|perf|test|build|ci|revert)\/[a-z0-9._-]+$ ``` **Format:** `type/description` — lowercase, no spaces, only `a-z0-9._-` in description. | Type | Branch pattern | Example | |------|---------------|---------| | Feature | `feat/<description>` | `feat/user-login` | | Bug fix | `fix/<description>` | `fix/zsh-glob-error` | | Chore | `chore/<description>` | `chore/update-ci-actions` | | Docs | `docs/<description>` | `docs/installation-guide` | | Style | `style/<description>` | `style/format-scripts` | | Refactor | `refactor/<description>` | `refactor/extract-shared-logic` | | Performance | `perf/<description>` | `perf/reduce-startup-time` | | Test | `test/<description>` | `test/add-setup-coverage` | | Build | `build/<description>` | `build/update-shellcheck` | | CI | `ci/<description>` | `ci/add-branch-validation` | | Revert | `revert/<description>` | `revert/broken-setup-change` | --- ## PR Body Format The PR template is at `.github/PULL_REQUEST_TEMPLATE.md`. Every PR body MUST contain: ### 1. Linked Issue (REQUIRED) ```markdown Closes #<issue-number> ``` Valid keywords: `Closes #N`, `Fixes #N`, `Resolves #N` (case insensitive). The linked issue MUST have the `status:approved` label. ### 2. PR Type (REQUIRED) Check exactly ONE in the template and add the matching label: | Checkbox | Label to add | |----------|-------------| | Bug fix | `type:bug` | | New feature | `type:feature` | | Documentation only | `type:docs` | | Code refactoring | `type:refactor` | | Maintenance/tooling | `type:chore` | | Breaking change | `type:breaking-change` | ### 3. Summary 1-3 bullet points of what the PR does. ### 4. Changes Table ```markdown | File | Change | |------|--------| | `path/to/file` | What changed | ``` ### 5. Test Plan ```markdown - [x] Scripts run without errors: `shellcheck scripts/*.sh` - [x] Manually tested the affected functionality - [x] Skills load correctly in target agent ``` ### 6. Contributor Checklist All boxes must be checked: - Linked an approved issue - Added exactly one `type:*` label - Ran shellcheck on modified scripts - Skills tested in at least one agent - Docs updated if behavior changed - Conventional commit format - No `Co-Authored-By` trailers --- ## Automated Checks (all must pass) | Check | Job name | What it verifies | |-------|----------|-----------------| | PR Validation | `Check Issue Reference` | Body contains `Closes/Fixes/Resolves #N` | | PR Validation | `Check Issue Has status:approved` | Linked issue has `status:approved` | | PR Validation | `Check PR Has type:* Label` | PR has exactly one `type:*` label | | CI | `Shellcheck` | Shell scripts pass `shellcheck` | --- ## Conventional Commits Commit messages MUST match this regex: ``` ^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\([a-z0-9\