How do I install the Pr Listo skill?

Run npx skillmds@latest add eve-devs/pr-listo in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Pr Listo safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Pr Listo?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Pr Listo free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Pr Listo?

eve-devs (@eve-devs) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Pr Listo by eve-devs — Agent Skill

Name: Pr Listo
Rating: 4.2 (5 reviews)
Author: eve-devs

Pr Listo

Prepara un pull request completo a partir del diff real de la rama: titulo, descripcion con contexto y decisiones, plan de pruebas, y una auto-revision que detecta lo que falta (tests, migraciones, docs, cambios rompientes) antes de que lo vea un reviewer. Usar cuando el usuario diga: "prepara el PR", "abre un pull request", "descripcion del PR", "que le pongo al PR", "revisa mi rama antes de subirla", "esta listo para review", "PR listo", "sube esto a review", "checklist antes del PR".

eve-devs Updated Sep 22, 2026

File contents

PR listo

Un PR bien armado se aprueba mas rapido porque le ahorra trabajo al reviewer. Esta skill produce ese PR y, antes, encuentra lo que el reviewer iba a encontrar.

Paso 1: leer la rama completa

BASE=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@.*/@@' || echo main)
git log --oneline "origin/$BASE"..HEAD
git diff "origin/$BASE"...HEAD --stat
git diff "origin/$BASE"...HEAD

Tres puntos (...), no dos: compara contra el ancestro comun, que es lo que el reviewer vera en GitHub.

Paso 2: auto-revision

Antes de escribir la descripcion, busca lo que falta. Reporta cada hallazgo con archivo y linea:

Lo que bloquea:

Secretos o credenciales en el diff
Restos de debug: console.log, print(), debugger, .only, .skip
Codigo comentado sin explicacion
Cambios rompientes de API sin nota (firma de funcion, campo de respuesta eliminado, endpoint renombrado)
Migracion de base de datos sin su reversa (down)

Lo que hay que preguntar:

Logica nueva sin ningun test que la toque
Variable de entorno nueva que no esta en .env.example
Dependencia nueva: ¿hace falta o el repo ya tiene algo equivalente?
Comportamiento documentado en el README que este PR cambia
Archivos de mas de ~400 lineas de diff que probablemente deban dividirse

Paso 3: escribir el PR

Titulo: mismo formato que los commits del repo (git log --oneline -20 para confirmar). Describe el resultado, no el proceso.

mal:  Cambios del ticket 482
bien: fix(auth): evitar refresh infinito al expirar el token

Descripcion:

## Que cambia
Dos o tres frases. Que hace distinto el sistema despues de este PR.

## Por que
El problema o el requerimiento. Enlaza el issue si existe.

## Como
Solo si la solucion no es obvia leyendo el diff. Aqui van las decisiones:
que alternativa descartaste y por que.

## Como probarlo
Pasos numerados y reproducibles.
1. `npm run dev`
2. Entrar a `/login` con un token expirado
3. Esperado: una sola peticion de refresh, luego 401 limpio

## Notas para quien revisa
- El archivo X tiene 300 lineas de diff pero es solo el formateo automatico
- La migracion hay que correrla antes de desplegar

Escribe la descripcion en el idioma del repo. Si los PRs anteriores estan en ingles, este tambien.

Paso 4: crear el PR

Confirma con el usuario antes de publicar nada. Publicar un PR es una accion hacia afuera: el equipo recibe notificaciones.

git push -u origin "$(git branch --show-current)"
gh pr create --title "..." --body-file /tmp/pr-body.md --base "$BASE" --draft

Usa --draft si la auto-revision encontro cosas sin resolver. Si el repo tiene .github/pull_request_template.md, rellena esa plantilla en vez de la de arriba.

Errores comunes

Describir los commits uno por uno. Al reviewer le importa el resultado final.
"Como probarlo: correr los tests". Eso ya lo hace CI; di que probar a mano.
Un PR que mezcla refactor y feature: se revisa mal y se revierte peor. Ofrece dividirlo.
Abrir el PR contra la rama equivocada.

---name: pr-listodescription: Prepara un pull request completo a partir del diff real de la rama: titulo, descripcion con contexto y decisiones, plan de pruebas, y una auto-revision que detecta lo que falta (tests, migraciones, docs, cambios rompientes) antes de que lo vea un reviewer. Usar cuando el usuario diga: "prepara el PR", "abre un pull request", "descripcion del PR", "que le pongo al PR", "revisa mi rama antes de subirla", "esta listo para review", "PR listo", "sube esto a review", "checklist antes del PR".---# PR listoUn PR bien armado se aprueba mas rapido porque le ahorra trabajo al reviewer. Esta skill produce ese PR y, antes, encuentra lo que el reviewer iba a encontrar.## Paso 1: leer la rama completa```bashBASE=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@.*/@@' || echo main)git log --oneline "origin/$BASE"..HEADgit diff "origin/$BASE"...HEAD --statgit diff "origin/$BASE"...HEAD```Tres puntos (`...`), no dos: compara contra el ancestro comun, que es lo que el reviewer vera en GitHub.## Paso 2: auto-revisionAntes de escribir la descripcion, busca lo que falta. Reporta cada hallazgo con archivo y linea:**Lo que bloquea:**- Secretos o credenciales en el diff- Restos de debug: `console.log`, `print()`, `debugger`, `.only`, `.skip`- Codigo comentado sin explicacion- Cambios rompientes de API sin nota (firma de funcion, campo de respuesta eliminado, endpoint renombrado)- Migracion de base de datos sin su reversa (`down`)**Lo que hay que preguntar:**- Logica nueva sin ningun test que la toque- Variable de entorno nueva que no esta en `.env.example`- Dependencia nueva: ¿hace falta o el repo ya tiene algo equivalente?- Comportamiento documentado en el README que este PR cambia- Archivos de mas de ~400 lineas de diff que probablemente deban dividirse## Paso 3: escribir el PR**Titulo:** mismo formato que los commits del repo (`git log --oneline -20` para confirmar). Describe el resultado, no el proceso.```mal: Cambios del ticket 482bien: fix(auth): evitar refresh infinito al expirar el token```**Descripcion:**```markdown## Que cambiaDos o tres frases. Que hace distinto el sistema despues de este PR.## Por queEl problema o el requerimiento. Enlaza el issue si existe.## ComoSolo si la solucion no es obvia leyendo el diff. Aqui van las decisiones:que alternativa descartaste y por que.## Como probarloPasos numerados y reproducibles.1. `npm run dev`2. Entrar a `/login` con un token expirado3. Esperado: una sola peticion de refresh, luego 401 limpio## Notas para quien revisa- El archivo X tiene 300 lineas de diff pero es solo el formateo automatico- La migracion hay que correrla antes de desplegar```Escribe la descripcion en el idioma del repo. Si los PRs anteriores estan en ingles, este tambien.## Paso 4: crear el PRConfirma con el usuario antes de publicar nada. Publicar un PR es una accion hacia afuera: el equipo recibe notificaciones.```bashgit push -u origin "$(git branch --show-current)"gh pr create --title "..." --body-file /tmp/pr-body.md --base "$BASE" --draft```Usa `--draft` si la auto-revision encontro cosas sin resolver. Si el repo tiene `.github/pull_request_template.md`, rellena **esa** plantilla en vez de la de arriba.## Errores comunes- Describir los commits uno por uno. Al reviewer le importa el resultado final.- "Como probarlo: correr los tests". Eso ya lo hace CI; di que probar a mano.- Un PR que mezcla refactor y feature: se revisa mal y se revierte peor. Ofrece dividirlo.- Abrir el PR contra la rama equivocada.

Frequently asked questions