baratihd/skills

Nota de Lanzamiento de Treatment Backend

Genera una nota de lanzamiento en inglés precisa y auditable a partir de evidencia real del repositorio al promover una rama origen a una rama destino, especialmente stage o production. Después de escribir la nota de lanzamiento, produce un resumen titular separado en persa solo en la conversación. Nunca agregues, incrustes o escribas el resumen en persa dentro de la nota de lanzamiento o cualquier otro archivo del proyecto.

Contrato de ejecución entre agentes

• Este skill es portable entre Codex, OpenCode y Claude Code; no se requiere ninguna herramienta específica de un proveedor. Lee este SKILL.md y los archivos references/ vinculados cuando se invoque.
• Una copia canónica se almacena en .agents/skills/treatment-backend-release-note/; .claude/skills/ y .opencode/skills/ apuntan a la misma copia cuando se usa el instalador empaquetado. No mantengas copias divergentes.
• Si las herramientas o permisos no están disponibles, informa la limitación con precisión; no fabriques evidencia de Git ni estado del lanzamiento.
• Acepta invocación en lenguaje natural, o $treatment-backend-release-note en Codex, /treatment-backend-release-note en Claude Code y configuraciones compatibles de OpenCode. Todas las invocaciones siguen exactamente el mismo flujo de trabajo y política de salida.

Entradas y alcance

• Requerido: source_branch, target_branch (solo destino predeterminado si el usuario establece explícitamente una convención del proyecto; de lo contrario, pregúntalo cuando realmente no esté disponible).
• Opcional: versión del lanzamiento, ventana de despliegue, referencias de tickets, nombre de archivo de salida (almacenado en docs/releases/), método de despliegue, propietario.
• Detecta remotos y valida referencias, estado del árbol de trabajo y raíz del repositorio antes de recopilar cambios. No cambies de rama, hagas pull, fetch, commit, merge, tag, despliegues ni modifiques código de la aplicación sin autorización explícita.
• Si no se especifica origen/destino, intenta inferirlos del contexto claro (por ejemplo, el usuario dice "lanzar develop a stage"); de lo contrario, pregunta. Nunca asumas silenciosamente que la rama actualmente checkout es la origen.
• Ambas referencias pueden ser ramas locales o ramas de seguimiento remoto; especifica exactamente qué referencias resueltas y hashes de commit fueron analizados.
• Interpreta el informe como cambios introducidos por origen en destino, no todo lo commitado alguna vez en la rama origen.

Flujo de trabajo

1. Verificación previa y evidencia de Git

Desde la raíz del repositorio, inspecciona estos comandos (adapta los nombres de referencia de forma segura; no interpoles argumentos de shell no confiables):

git status --short
git remote -v
git branch -a
git rev-parse --verify <source>^{commit}
git rev-parse --verify <target>^{commit}
git merge-base <target> <source>
git log --date=short --format='%h %ad %s' <target>..<source>
git diff --stat <target>...<source>
git diff --name-status <target>...<source>
git diff <target>...<source> -- <relevant-paths>

target..source identifica commits no alcanzables desde target. target...source en git diff compara el merge-base con source, aproximando los cambios propuestos por la rama origen. Estos pueden no ser iguales al diff de merge exacto resultante para ramas divergentes, cherry-picks o rebases. Para un lanzamiento propuesto, inspecciona ambas perspectivas (commits y diff), identifica anomalías y, si es necesario, usa un worktree desechable/merge temporal solo con autorización. No afirmes un resultado mergeado definitivo a partir de un diff de tres puntos no verificado. Para un lanzamiento ya completado, prefiere el commit de merge registrado, tag, SHA desplegado o las referencias reales antes/después del despliegue, si están disponibles.

Revisa archivos fuente significativos, migraciones, configuración, esquemas de API, serializadores, permisos, tareas en segundo plano, integraciones, pruebas y manifiestos de despliegue; evita confiar solo en los asuntos de los commits. Excluye archivos generados/de ruido de la narrativa cuando sea apropiado, pero no ocultes migraciones generadas impactantes o cambios en archivos de bloqueo. Busca cambios con efectos empresariales que abarquen múltiples commits. Agrupa por capacidad empresarial en lugar de listar cada archivo modificado. Vincula el código con tickets/PRs cuando sea demostrable.

2. Clasificar cambios e impacto

Separa y describe:

1. Cambios empresariales — flujos de trabajo nuevos o modificados, reglas de elegibilidad, cobertura, procesamiento de gastos/reclamaciones, informes, notificaciones y comportamiento observable. Escribe solo cuando esté respaldado por código, pruebas o contexto de producto proporcionado por el usuario; etiqueta claramente inferencia o confirmación faltante.
2. Cambios técnicos — APIs, modelos/migraciones de Django, trabajos/Celery, base de datos/índices, integraciones externas, configuración, seguridad/permisos, confiabilidad, rendimiento, observabilidad, CI/CD y refactorización.
3. Compatibilidad y consumidores — endpoints/métodos REST, campos de solicitud/respuesta, códigos de estado, autenticación, clientes web/móviles, llamadores internos, trabajadores, sistemas de terceros, base de datos y eventos. Indica Breaking change: Yes / No / Unknown con evidencia. Distingue la compatibilidad de API de la compatibilidad de despliegue/datos. Explica las acciones requeridas del consumidor y el orden de despliegue cuando sea relevante.
4. Validación y trazabilidad — referencias origen/destino exactas + SHAs, SHA base, commits notables, enlaces a tickets/PRs cuando se encuentren, pruebas y su estado real observado, planes de migración, aprobadores/estado si se proporcionan. No afirmes que una prueba pasó sin ejecutarla u obtener resultados de prueba confiables.
5. Revertir / reversión — describe pasos y requisitos previos apropiados para el destino, con manejo distinto para reversión de aplicación, migraciones de esquema reversibles, migraciones de datos irreversibles, trabajos reproducibles, mensajes, idempotencia y efectos secundarios de terceros. Siempre distingue una reversión de Git de una reversión operativa. Nunca afirmes que la reversión es segura sin verificar migraciones y efectos secundarios.

Revisa la lista de verificación completa en references/review-checklist.md.

3. Redactar y guardar la nota de lanzamiento en inglés

Sigue references/release-note-template.md. Usa inglés para todo el contenido guardado en la nota de lanzamiento, incluidos los encabezados. Mantenlo conciso pero informativo y apropiado tanto para revisión de ingeniería como empresarial. Usa "Not verified", "Unknown", o "Requires confirmation" en lugar de inventar detalles.

El directorio de salida canónico del proyecto es docs/releases/. Guarda cada nota de lanzamiento allí; no crees un directorio release-notes/ en la raíz. La salida predeterminada es docs/releases/YYYY-MM-DD-<source>-to-<target>.md, con las barras de las ramas reemplazadas por guiones. Respeta un nombre de archivo solicitado explícitamente manteniéndolo bajo docs/releases/. Evita sobrescribir una nota de lanzamiento existente. Si el destino existe, elige un nombre de archivo único o busca aprobación explícita para el reemplazo. Usa la fecha de generación solo como fecha de documentación, no una fecha de despliegue inventada. La nota de lanzamiento es un lanzamiento propuesto hasta que se verifique el despliegue.

Después de guardar, vuelve a leer el archivo y valida: dirección de la rama e identidades de commit, cambios empresariales/técnicos, compatibilidad, verificación, trazabilidad, reversión y ausencia del resumen en persa. No hagas stage o commit automático de la nota de lanzamiento a menos que se solicite. Informa la ruta relativa guardada.

4. Resumen en persa solo en el chat (obligatorio)

Solo después de guardar y validar exitosamente, presenta un breve resumen titular en persa en la respuesta final del agente. Enfócate en resultados legibles para el negocio, riesgos significativos, acciones requeridas del consumidor/despliegue y preparación/desconocidos. Normalmente de 3 a 7 viñetas cortas, sin detalles de implementación de bajo nivel a menos que sea necesario. Formato de ejemplo:

خلاصه برای ارائه به بیزینس (فقط در پاسخ Agent، خارج از فایل):
- بهبود فرآیند ...
- تغییر در رفتار ...
- نیاز به هماهنگی با ...
- وضعیت اعتبارسنجی: ...
- ریسک و برنامه بازگشت: ...

Solo incluye declaraciones establecidas durante la revisión. No guardes este resumen en ningún archivo, registro, mensaje de commit o apéndice de la nota de lanzamiento. Si la escritura falla, no afirmes que la nota de lanzamiento fue registrada; explica el obstáculo y, si es útil, proporciona un resumen provisional claramente marcado como provisional.

Puertas de calidad

• Basa cada cambio y afirmación en el diff inspeccionado, pruebas, historial de Git o contexto de lanzamiento proporcionado explícitamente; distingue hechos verificados de inferencias.
• No imprimas secretos, tokens, contraseñas, datos privados de clientes o credenciales sin procesar encontrados en los diffs. Redacta ejemplos.
• No equipares código commitado con funcionalidad desplegada, ni equipares una prueba no ejecutada con una prueba aprobada.
• Cuando una rama incluya cambios no relacionados, documenta el alcance y el riesgo en lugar de eliminar silenciosamente modificaciones importantes.
• Usa None identified explícito solo después de verificar; de lo contrario, usa Unknown / Not verified.
• Nunca ejecutes migraciones, manipules datos de producción ni realices reversiones como parte de su documentación.