branch-pr

name	branch-pr
description	Create pull requests with branch, validation, and publication checks. Trigger: creating, opening, or preparing PRs for review.
license	Apache-2.0
metadata	{"author":"manuel-retamozo-garcia","version":"2.1"}

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. Issue linkage is optional. If a PR links an issue, verify it is relevant and approved; never fabricate or self-approve an issue.
2. Every PR MUST have exactly one type:* label
3. Automated checks must pass before merge is possible
4. PRs MUST describe scope and validation, whether or not an issue is linked.
5. No model/tool attribution in the PR title, body, or comments — never include Generated with, a 🤖 footer, or any mention of Claude, Claude Code, Anthropic, GPT, OpenAI, Codex, Copilot, Gemini, or any other model/vendor. See rules/no-model-attribution.instructions.md.
6. Feature branch MUST be created before any project file is edited — run git checkout -b <tipo>/<descripción> main as Step 0 before writing any code.
7. NEVER edit files or commit directly on the default branch (main) — all changes require a feature branch and PR.

---

Workflow

0. Crear una rama de feature: git checkout -b <tipo>/<descripción> main
1. If an issue is linked, verify it has the `status:approved` label; otherwise continue without issue linkage
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

---

Multi-Developer Collaboration

Working in teams requires extra branch discipline to avoid conflicts:

• Branch hygiene: one branch per task, named <type>/<description>; delete branches after merge.
• Default-branch protection: NEVER edit files or commit directly on main; all work goes through feature branches and PRs.
• Sync coordination: git pull --rebase main before branching; rebase feature branches regularly to stay current.
• Parallel work: each developer works on a dedicated branch; integrate only via PR review, never direct push.
• Commit conventions: use Conventional Commits with Spanish imperative verbs; keep commits atomic and buildable.

---

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 (OPTIONAL)

Include Closes #<issue-number>, Fixes #<issue-number>, or Resolves #<issue-number> only when a relevant approved issue exists. Otherwise omit issue linkage; do not invent an issue or approval.

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

| File | Change |
|------|--------|
| `path/to/file` | What changed |

5. Test Plan

- [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 when one exists, or explicitly omitted issue linkage
• 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
• No model/tool attribution in commits or PR body (no Claude/GPT/Gemini/Copilot/etc., no 🤖 footer)

---

Automated Checks (all must pass)

Check	Job name	What it verifies
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\._-]+\))?!?: .+

Format: type(scope): descripción or type: descripción

• type — required, one of: build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test
• (scope) — optional, lowercase with a-z0-9._-
• ! — optional, indicates breaking change
• description — required, starts after : and MUST be Spanish imperative
• Commit body, when needed, MUST be Spanish prose

Type-to-label mapping:

Commit type	PR label
feat	type:feature
fix	type:bug
docs	type:docs
refactor	type:refactor
chore	type:chore
style	type:chore
perf	type:feature
test	type:chore
build	type:chore
ci	type:chore
revert	type:bug
feat! / fix!	type:breaking-change

Examples:

feat(scripts): añade soporte de Codex a setup.sh
fix(skills): corrige el formato de topic en sdd-apply
docs(readme): actualiza la guía de configuración multi-modelo
refactor(skills): extrae la lógica compartida de persistencia
chore(ci): añade shellcheck a la validación de PR
perf(scripts): reduce el tiempo de ejecución de setup.sh
style(skills): corrige el formato markdown
test(scripts): añade pruebas de integración para setup.sh
ci(workflows): añade validación de nombres de rama
revert: deshaz el cambio roto de setup
feat!: rediseña el sistema de carga de skills

---

Commands

# Create branch
git checkout -b feat/my-feature main

# Run shellcheck before pushing
shellcheck scripts/*.sh

# Push and create PR
git push -u origin feat/my-feature
gh pr create --title "feat(scope): añade descripción" --body "Closes #N"

# Add type label to PR
gh pr edit <pr-number> --add-label "type:feature"