branch-pr

Enforce issue linking, branch naming, and label validation for pull requests.

Updated Apr 8, 2026
One-click install
npx skills add https://github.com/aroca89/roca_teams --skill branch-pr-aroca89
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: branch-pr
Source: https://github.com/aroca89/roca_teams/tree/main/skills/branch-pr
Command: npx skills add https://github.com/aroca89/roca_teams --skill branch-pr-aroca89

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This workflow prevents roca_teams contributors from submitting pull requests without an approved issue, clear branch naming, or passing automated checks, eliminating common review bottlenecks. It avoids chaotic context by enforcing a deterministic approval, labeling, and validation path before any code is merged.

Core Features & Use Cases

  • Issue-first enforcement: every PR must link to an issue labeled status:approved, keeping approvals and scope aligned.
  • Branch, label, and commit guardrails: enforces type/description naming, a single type:* label, conventional commit messages, and shellcheck plus CI validations.
  • Use Case: preparing a feature or fix for review now follows the exact same structured steps so reviewers and automation never hit unexpected forked flows.

Quick Start

Prepare your branch as type/description, link the approved issue, and open the PR using the branch-pr workflow before running shellcheck.

Frequently Asked Questions about branch-pr

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce an issue-first pull request workflow with branch naming and label validation?▼

To enforce an issue-first pull request workflow, link every PR to an approved issue, use type/description branch naming, apply a single type:* label, and run conventional commit checks before merging.

What is the required branch naming format for compliant pull request creation?▼

The required branch naming format for compliant pull request creation is type/description, ensuring every feature or fix branch follows a deterministic structure before opening a pull request.

Do I need an approved issue before opening a pull request?▼

Yes, you need an approved issue before opening a pull request. The workflow enforces issue linking by requiring every PR to reference an issue labeled status:approved.

How do I validate conventional commit messages and shellcheck before merging a PR?▼

To validate conventional commit messages and shellcheck before merging a PR, the workflow enforces automated check prerequisites, ensuring commit format and shell scripts pass CI validations.

Can I apply multiple type labels to a pull request using this workflow?▼

No, you cannot apply multiple type labels to a pull request using this workflow. It enforces single type:* label guardrails to prevent chaotic context and maintain clear review scope.

What are the limitations of enforcing automated check prerequisites for pull requests?▼

The limitations of enforcing automated check prerequisites include strict dependency on passing shellcheck and conventional commit validations, which blocks PR merging if any automated check fails.