pr-workflow

Files (1)

• SKILL.md

SKILL.md (first lines)

# Crear pull requests

Una PR explica qué cambió, por qué y cómo verificarlo. Canal por defecto:
GitHub MCP (`github/*`). `gh` es fallback. Si no hay MCP ni `gh`, dilo y
no finjas la PR.

Alineado con el flujo GitHub del equipo: rama `feat/<slug>` o `fix/<slug>`,
issue en `in-review` al abrir, merge lo decide el usuario.

## Proceso

1. **Estado.** `git status` y `git diff`. Si hay cambios sin commitear,
   confirma con el usuario.

2. **Rama.** Nunca `main`. Si no hay rama: `feat/issue-N-slug` o `fix/slug`.

3. **Título** menor de 70 caracteres, `tipo: descripción`. Ejemplos:
   `feat: add date search filter`, `fix: correct invoice VAT`.

4. **Cuerpo** (sigue `.github/pull_request_template.md` si existe):

   ## Resumen
   - qué cambia y por qué

   ## Motivación
   Closes #N

   ## Plan de pruebas
   - [ ] paso verificable
   - [ ] regresión

   ## Notas para el revisor
   decisiones, zonas delicadas

5. **Abrir:** GitHub MCP con título, cuerpo y `Closes #N`. Si el MCP no
   está, `gh pr create`. Labels (`bug`, `feature`, `refactor`, `docs`) si
   el repo las tiene. Reviewers solo si el usuario indica quién.

6. Marca la issue `in-review` (quita `in-progress`). Comprueba que CI arranca.

## Qué NO hacer

- No menciones asistentes ni herramientas de IA en la PR.
- No abras PR sin cuerpo.
- No mezcles cambios no relacionados.
- No fusiones tú: el merge es del usuario (o de devops si el flujo de entrega lo dice).

From SrScorpio/alfred-dev-vscode, MIT.

More from SrScorpio/alfred-dev-vscode