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.