Skill: Crear Pull Request (PR / MR)

Crear un PR o MR desde la rama actual hacia una rama destino preguntada al usuario, sobre cualquier repo git con remoto configurado.

Origen = rama actual, sin excepción. Hay dos modos válidos, que el skill deduce del par origen→destino (ver Modos: implementación y promoción):

• PR de implementación — de una rama de trabajo (feature/, fix/, chore/, refactor/, test/, hotfix/…) a su rama de integración o despliegue. Es el caso por defecto.
• PR de promoción — de una rama de integración a una de despliegue (develop → master, develop → release/x, release/x → main). No trae código nuevo: consolida trabajos que ya pasaron sus puertas al integrarse.

El modo lo decide una sola tabla de decisión, evaluada en el Paso 3 con el destino ya conocido; ver Modos: implementación y promoción. Ahí se define también cuándo se para y cuándo se pregunta.

Working tree sucio no detiene el flujo: si hay cambios sin commitear, el skill invoca automáticamente el flujo del skill git-commit (sin preguntar al usuario si desea commitear — la decisión de invocarlo es automática) y, una vez el working tree queda limpio, continúa con el resto del pre-flight. Nota: git-commit no tiene modo silencioso — un commit único lo ejecuta sin confirmar, pero puede pausar para confirmar su propuesta de división cuando el diff se reparte en varios commits (con commitConfirmation = always) y puede detenerse del todo ante secretos, rama protegida o hook fallido; ese comportamiento no se suprime al invocarlo desde aquí.

Plataforma se auto-detecta del remoto origin. No preguntar.

Puertas de calidad obligatorias y bloqueantes: en un PR de implementación se ejecutan siempre quality-check, code-review y trace-validate; en uno de promoción, solo quality-check. En ambos modos, si existe la Definition of Done (docs/policies/definition-of-done.md), se verifica. Todas las que apliquen deben quedar en aprobado; si alguna no lo está, no se crea el PR. No hay flujo "crear como draft" ni "ignorar y continuar", ni forma de saltarse una puerta que aplica.

No incluye: modificar código por iniciativa propia, merges, rebases, resolver conflictos, asignar reviewers/labels/milestones, editar PRs existentes. (Las correcciones solo se aplican si el usuario las autoriza explícitamente — ver Manejo de fallos en las puertas.)