Saltar al contenido

Cuándo usar este skill

Úsalo cuando el usuario:

  • Pide explícitamente crear o redactar la descripción de un PR.
  • Acaba de hacer commit de cambios sustanciales y está por abrir un PR hacia main o develop.
  • Pide que revises / mejores una descripción de PR ya escrita.

No lo uses para commits individuales (esos van con Conventional Commits).

Formato estándar FIT

Toda descripción de PR en repos FACTORIT debe seguir esta plantilla:

## Contexto

Una o dos frases: **por qué** se hace este cambio. Enlaza al ticket de Linear/Jira si aplica (`FIT-123`).

## Qué cambia

- Bullet list de los cambios más relevantes. No exhaustivo — que el reviewer pueda leer la descripción en < 60 segundos.
- Agrupa por módulo/dominio si hay cambios en varios.

## Cómo probar

Pasos reproducibles para validar el cambio:

1. `npm run ...`
2. Navegar a `...`
3. Verificar que `...`

## Impacto / riesgos

- Migraciones de DB: sí/no
- Feature flag: sí (`flag-name`) / no
- Breaking changes: sí/no — si sí, explica
- Performance: nota si se agregó query N+1 o se optimizó algo crítico

## Screenshots / loom

*(sólo si hay cambios visibles de UI o flujos nuevos)*

Reglas

  1. Título del PR: <tipo>(<scope>): <resumen imperativo> en español o inglés según la convención del repo. Tipos: feat, fix, refactor, chore, docs, test, perf.

    • Ejemplo: feat(billing): soporta pagos recurrentes con Stripe
    • Máximo 70 caracteres.

  2. Secciones obligatorias: Contexto, Qué cambia, Cómo probar. Las demás sólo si aplican.

  3. Enlaza tickets: si hay ticket asociado, inclúyelo al inicio de Contexto con formato [FIT-123](https://factorit.atlassian.net/browse/FIT-123).

  4. No describas el qué código por código — el diff ya lo dice. Describe el por qué y el impacto.

  5. Flags críticas: si el PR introduce una migración, breaking change, o cambio de infraestructura, márcalo con :warning: al inicio del título.

Proceso

Cuando se active el skill:

  1. Lee el diff del branch actual (git diff main...HEAD) y los commits (git log main..HEAD).
  2. Identifica el ticket si está en el nombre de la rama (skill/FIT-123-...) o en los commits.
  3. Genera la descripción siguiendo la plantilla.
  4. Si falta contexto crítico (por qué se hace el cambio, cómo probar), pregúntalo al usuario antes de inventar.
  5. Propón el título siguiendo la convención.

Ejemplo

Input: usuario hace git diff main...HEAD mostrando cambios en src/billing/stripe.ts y src/billing/webhooks.ts, con 3 commits: “agrega soporte recurring”, “tests”, “fix edge case trial period”.

Output:

**Título**: `feat(billing): soporta suscripciones recurrentes con Stripe`

## Contexto

[FIT-412](https://factorit.atlassian.net/browse/FIT-412) — necesitamos facturación recurrente para el plan Pro que se lanza en Q2.

## Qué cambia

- Nuevo endpoint `POST /billing/subscriptions` que crea una suscripción Stripe.
- Webhook `invoice.paid` procesa renovaciones y actualiza el estado del cliente.
- Edge case: clientes en trial no reciben cobro hasta el día 15.

## Cómo probar

1. `npm run dev` y autentica como un usuario de prueba.
2. POST a `/billing/subscriptions` con `{ "plan": "pro" }`.
3. En Stripe Dashboard (test mode) verifica que se creó la suscripción.
4. Simula el webhook `invoice.paid` con `stripe trigger invoice.paid`.

## Impacto / riesgos

- Migraciones: sí — `20260416_add_subscription_id.sql`.
- Feature flag: sí (`billing.recurring`), rollout gradual.
- Breaking changes: no.

Referencias

  • Convención de commits FIT: pendiente de documentar en factorit/eng-handbook.
  • Plantilla de PR en GitHub: .github/pull_request_template.md (si el repo la tiene, ajústate a ella).