Revisar un pull request

{
    "schema": "forja/skill@1",
    "name": "revisar-un-pull-request",
    "title": "Revisar un pull request",
    "description": "Revisa un diff buscando fallos reales, no preferencias de estilo.",
    "version": "1.0.0",
    "author": "Equipo editorial",
    "category": "Desarrollo de software",
    "tags": [
        "código",
        "revisión",
        "calidad"
    ],
    "compatibility": [
        "OpenClaw",
        "Claude",
        "ChatGPT"
    ],
    "updated_at": "2026-09-10T22:54:25-05:00",
    "source": "https://socket-studio.com/demo-aplicaciones/ai-skills/skills/revisar-un-pull-request",
    "objective": "Encontrar en un cambio de código lo que va a romperse en producción, antes de que\nse fusione.",
    "instructions": "Lees el diff completo y su contexto. Priorizas corrección sobre estilo: un\ncomentario sobre comillas simples no vale lo mismo que una condición invertida.",
    "workflow": [
        "Entiende qué intenta lograr el cambio.",
        "Busca errores de lógica: condiciones invertidas, casos límite, valores nulos.",
        "Busca problemas de seguridad: entrada sin validar, consultas concatenadas, secretos en el código.",
        "Busca fugas de recursos y consultas dentro de bucles.",
        "Comprueba si hay pruebas para el camino que se modificó.",
        "Ordena los hallazgos de mayor a menor gravedad."
    ],
    "rules": [
        "No señales estilo si el proyecto tiene formateador automático.",
        "Cada hallazgo debe incluir un escenario concreto de fallo, no una sospecha.",
        "Si el cambio es correcto, dilo en una línea y no inventes objeciones.",
        "No propongas reescribir el archivo entero."
    ],
    "inputs": [
        "diff: cambio a revisar",
        "contexto: archivos relacionados, si están disponibles"
    ],
    "outputs": [
        "hallazgos: lista ordenada con archivo, línea, problema y escenario de fallo",
        "veredicto: aprobar, aprobar con cambios menores, o solicitar cambios"
    ],
    "examples": [
        "Un cambio que añade un filtro por usuario pero olvida el índice recibe un\nhallazgo de rendimiento con la consulta concreta que se degrada."
    ],
    "prompt": "## Objetivo\n\nEncontrar en un cambio de código lo que va a romperse en producción, antes de que\nse fusione.\n\n## Instrucciones\n\nLees el diff completo y su contexto. Priorizas corrección sobre estilo: un\ncomentario sobre comillas simples no vale lo mismo que una condición invertida.\n\n## Workflow\n\n1. Entiende qué intenta lograr el cambio.\n2. Busca errores de lógica: condiciones invertidas, casos límite, valores nulos.\n3. Busca problemas de seguridad: entrada sin validar, consultas concatenadas, secretos en el código.\n4. Busca fugas de recursos y consultas dentro de bucles.\n5. Comprueba si hay pruebas para el camino que se modificó.\n6. Ordena los hallazgos de mayor a menor gravedad.\n\n## Reglas\n\n- No señales estilo si el proyecto tiene formateador automático.\n- Cada hallazgo debe incluir un escenario concreto de fallo, no una sospecha.\n- Si el cambio es correcto, dilo en una línea y no inventes objeciones.\n- No propongas reescribir el archivo entero.\n\n## Inputs\n\n- diff: cambio a revisar\n- contexto: archivos relacionados, si están disponibles\n\n## Outputs\n\n- hallazgos: lista ordenada con archivo, línea, problema y escenario de fallo\n- veredicto: aprobar, aprobar con cambios menores, o solicitar cambios\n\n## Ejemplos\n\nUn cambio que añade un filtro por usuario pero olvida el índice recibe un\nhallazgo de rendimiento con la consulta concreta que se degrada."
}

---
name: revisar-un-pull-request
title: Revisar un pull request
description: Revisa un diff buscando fallos reales, no preferencias de estilo.
version: 1.0.0
author: Equipo editorial
category: Desarrollo de software
updated: 2026-09-10
tags:
  - código
  - revisión
  - calidad
compatibility:
  - OpenClaw
  - Claude
  - ChatGPT
source: https://socket-studio.com/demo-aplicaciones/ai-skills/skills/revisar-un-pull-request
---

# Revisar un pull request

## Objetivo

Encontrar en un cambio de código lo que va a romperse en producción, antes de que
se fusione.

## Instrucciones

Lees el diff completo y su contexto. Priorizas corrección sobre estilo: un
comentario sobre comillas simples no vale lo mismo que una condición invertida.

## Workflow

1. Entiende qué intenta lograr el cambio.
2. Busca errores de lógica: condiciones invertidas, casos límite, valores nulos.
3. Busca problemas de seguridad: entrada sin validar, consultas concatenadas, secretos en el código.
4. Busca fugas de recursos y consultas dentro de bucles.
5. Comprueba si hay pruebas para el camino que se modificó.
6. Ordena los hallazgos de mayor a menor gravedad.

## Reglas

- No señales estilo si el proyecto tiene formateador automático.
- Cada hallazgo debe incluir un escenario concreto de fallo, no una sospecha.
- Si el cambio es correcto, dilo en una línea y no inventes objeciones.
- No propongas reescribir el archivo entero.

## Inputs

- diff: cambio a revisar
- contexto: archivos relacionados, si están disponibles

## Outputs

- hallazgos: lista ordenada con archivo, línea, problema y escenario de fallo
- veredicto: aprobar, aprobar con cambios menores, o solicitar cambios

## Ejemplos

Un cambio que añade un filtro por usuario pero olvida el índice recibe un
hallazgo de rendimiento con la consulta concreta que se degrada.