review

Visión general de review skill

Qué hace review skill

review es una skill de revisión de PR antes del merge, pensada para comprobar diffs frente a la rama base antes de integrar el código. Está orientada a revisores que necesitan algo más que un prompt genérico: se centra en riesgos estructurales concretos como la seguridad de SQL, violaciones de límites de confianza, efectos secundarios condicionales, inyección en shell y la completitud de enum.

Quién debería usarla

Usa review skill cuando vayas a integrar código, cuando te pidan “review this PR” o cuando quieras un flujo coherente de review for PR Review entre repos. Es especialmente útil para agentes que necesitan detectar defectos reales con rapidez y evitar comentarios ruidosos solo de estilo.

Por qué es diferente

La skill tiene una postura clara sobre el orden de revisión y la severidad. Da prioridad primero a las comprobaciones críticas de seguridad y después a los problemas de menor gravedad, y además admite rutas de revisión especializadas para áreas como testing, seguridad, rendimiento y mantenibilidad. Eso hace que la review guide sea más accionable que un prompt amplio de “examinar el diff”.

Encaje y limitaciones

Rinde mejor en cambios de código con un diff de git claro y una rama base significativa. Es menos útil para críticas de diseño de alto nivel, ediciones de texto de producto o casos en los que el usuario solo quiere elogios o un resumen. Si necesitas una opinión ligera en lugar de una revisión centrada en correcciones, puede bastar un prompt genérico.

Cómo usar review skill

Instálala y actívala

Instálala con npx skills add garrytan/gstack --skill review. La skill está diseñada para activarse con frases como “review this PR”, “code review”, “check my diff” y “pre-landing review”, así que el input debería nombrar el cambio y el punto de comparación siempre que sea posible.

Dale a la skill un objetivo real de revisión

El mejor review usage empieza con una solicitud consciente del diff, no con una petición vaga. Los buenos inputs incluyen el repo, la rama y la intención:

• “Review this PR against origin/main; focus on safety, merge risk, and anything that would block landing.”
• “Review the diff in packages/billing for SQL injection, race conditions, and API contract breaks.”

Lee primero estos archivos

Para verificar de forma práctica el review install, empieza por SKILL.md, luego checklist.md, design-checklist.md y greptile-triage.md. Si vas a adaptar el flujo, revisa también TODOS-format.md y la carpeta specialists/ para entender qué incidencias se derivan a subagentes y cuáles se quedan en la checklist principal.

Usa el flujo que la skill espera

El repo está organizado en torno a una revisión en dos pasadas: primero las comprobaciones críticas de seguridad y después los problemas informativos. Un buen prompt debe pedir una salida accionable con referencias a archivo y línea, además de soluciones, no solo “encuentra bugs”. Si conoces el área del cambio, inclúyela para que la skill pueda priorizar la ruta especialista pertinente.

Preguntas frecuentes sobre review skill

¿review es mejor que un prompt normal?

Sí, cuando necesitas un comportamiento repetible de revisión de PR. Un prompt normal puede pasar por alto reglas de alcance, el orden de escalado o el enrutado a especialistas. La review skill incorpora todo eso al flujo, lo que reduce la incertidumbre sobre qué inspeccionar primero.

¿La review skill es apta para principiantes?

En general sí, si la persona puede describir la rama o el PR. Los principiantes se benefician de la checklist guiada, pero aun así necesitan aportar un diff real y suficiente contexto para distinguir el comportamiento previsto de una regresión.

¿Cuándo no debería usar review?

No la uses para preguntas sin código, lluvia de ideas o discusiones abstractas de arquitectura sin un conjunto concreto de cambios. Tampoco es la opción adecuada si solo quieres una comprobación rápida de cordura y no necesitas hallazgos a nivel de línea.

¿Qué debería esperar de review for PR Review?

Espera comentarios breves, orientados a correcciones y con priorización por severidad. La skill está diseñada para señalar bloqueos de integración, no para repetir todo el repositorio ni para producir un resumen celebratorio.

Cómo mejorar review skill

Aporta inputs más precisos

Los inputs más sólidos de review skill nombran la rama base, el subsistema con riesgo y el estándar deseado. En lugar de “review my PR”, usa “review feature/payment-retry against origin/main; prioritize data safety, idempotency, and any behavior change that could break clients.”

Incluye el contexto que cambia el juicio

Si el cambio asume un riesgo intencional, dilo. Si un patrón está permitido por la política del proyecto, menciónalo desde el principio. Eso reduce los falsos positivos y ayuda a que la revisión se centre en los tradeoffs reales en lugar de reabrir decisiones ya conocidas.

Pide el formato que necesitas

Si quieres una salida orientada al merge, pide hallazgos con file:line, severidad y correcciones concretas. Si solo quieres bloqueos, dilo. Si quieres cobertura de especialistas, solicítala explícitamente para que la revisión no se quede en la primera pasada.

Itera después de la primera pasada

Usa la primera revisión para corregir los problemas evidentes y luego vuelve a ejecutar review sobre el diff actualizado. Las mayores mejoras de calidad suelen venir de aclarar el alcance, afinar la rama de comparación y alimentar a la skill con el área de riesgo exacta que más te importa.