| name | status-report |
| model | haiku |
| effort | low |
| description | Genera el end-of-day combinando los commits del período y los bullets manuales pegados en el prompt. Escribe directamente al archivo canónico `/mnt/c/Users/jutoc/Documents/Personal/Lecturas/BlueStack/END OF DAY.md` (markdown estándar, reemplaza contenido anterior). Soporta --full para log técnico crudo. |
| invocation | name-only |
ROL
Producir el end-of-day del usuario para una lectura externa — el destinatario es un stakeholder no-técnico que no conoce la implementación, ni la nomenclatura interna del trabajo, ni el roadmap, ni los planes de fase, ni las skills/agentes/audits del agente IA, ni el detalle del framework QA. Solo le interesa qué valor se entregó hoy en términos de producto, equipo o destrabes concretos.
Asumir audiencia que entiende a alto nivel: "el CMS", "tickets en Jira", "tests automatizados", "el equipo de Front/Back", "deploy a una versión". No asumir que entiende: nombres internos de iniciativas, fases del roadmap, audits, skills, agents, pipelines internos, archivos, ramas, métricas internas (issues, líneas, palabras, tokens) sin un "para qué" traducido.
Combinás dos fuentes en un único shot:
- Avance de código: commits del período via
scripts/skills/commit-parser.ts.
- Avance manual: bullets pegados en el mismo prompt (tickets reportados, validaciones, comunicación destrabante, hallazgos).
El output default es ejecutivo (resumen + logros, ≤14 líneas). El modo --full desactiva la síntesis y muestra los commits crudos agrupados por fecha — para el log técnico interno del usuario.
Destino del output (obligatorio)
El reporte se escribe a un archivo .md — no se imprime al chat como bloque pegable. El usuario revisa el archivo en su editor de Windows y desde ahí copia/comparte.
Path canónico (Windows visto desde WSL2):
/mnt/c/Users/jutoc/Documents/Personal/Lecturas/BlueStack/END OF DAY.md
Reglas del file-write:
- Reemplazar contenido completo (overwrite). Lo que había era el reporte del día anterior.
- Antes de escribir, leer el archivo una vez (el tool
Write lo exige cuando ya existe).
- Si el path no existe (path Windows no montado, archivo movido) → escalar al usuario, no crear directorios nuevos ni paths alternativos.
- No imprimir el contenido completo del reporte al chat. Tras escribir, confirmar con un mensaje de una línea + path, ej.:
End of Day escrito en /mnt/c/Users/jutoc/Documents/Personal/Lecturas/BlueStack/END OF DAY.md (N logros, próximos pasos: sí/no).
Autor git filtrado: jtcaldera-bluestack.
Formato del archivo .md (markdown estándar)
El destino es un .md que se renderiza con CommonMark/GFM (no Google Chat). Usar:
- Heading principal
# End of Day — DD de mes de YYYY (fecha en español, mes en minúsculas).
- Heading de sección
## Logros, ## Próximos pasos. Nunca usar negrita suelta como pseudo-heading.
- Bold con
**texto** (doble asterisco — markdown estándar). El bullet usa **Título corto:** seguido de la descripción.
- Listas con
- (guion). No •, no *.
- Una línea por bullet — sin saltos de línea forzados a mitad de oración. La terminal puede mostrar wrap visual, pero el archivo debe tener cada bullet en una sola línea lógica. Esto es crítico: cuando el usuario copia, los saltos forzados rompen el reporte.
- Línea en blanco entre el heading y el contenido de cada sección.
- Sin
--- separadores horizontales. Sin emojis. Sin tablas.
La traducción de commits a bullets vive en scripts/skills/commit-parser.ts (SSoT runtime). La tabla en wiki/development/commit-conventions.md es derivada (guía de redacción humana para smart-commit). Esta skill consume el script — no duplica reglas.
RESTRICCIONES
Vocabulario prohibido (audiencia externa)
Nunca aparecen en el archivo:
- Nombres internos de iniciativas o fases: "Fase J", "Fase A", "plan multi-fase", "sprint X", "milestone Y", "iniciativa Z". El destinatario no tiene idea qué fase es cuál — describir la entrega ("dashboard de reportes operativo"), no su etiqueta interna.
- Jerga del agente IA del proyecto: "skill", "agente del pipeline", "ticket-analyst", "test-engine", "audit", "audits cross-skill", "hooks", "governance drift", "SSoT". Si una mejora en el agente sale al EOD, traducirla al impacto observable ("el agente IA consume 69% menos contexto" o simplemente omitirla si no genera valor visible para el lector).
- Jerga de implementación: clases TypeScript (
MainPostPage), paths de archivos, hashes git, nombres de ramas, jerga git ("merge", "rebase", "cherry-pick"), nombres de helpers o templates, "ADF", "JSDoc", "POM", "factory", "wrapper".
- Métricas internas sin contexto traducido: "83 issues", "70 assertions", "21 skills auditadas", "split pipeline/manual", "2627→814 palabras". Solo aparecen si vienen acompañadas del por qué le importa al lector ("69% menos consumo de contexto = más rápido y barato"). Si no hay traducción razonable → omitir.
- Tooling/governance interno: scripts del repo, hooks, lints, rotation policies, "wiki", "SSoT canónica", "evals". Si la mejora es puramente de mantenimiento del agente, no va al EOD.
- Emojis (excepto los de excepción), hashtags, mail boilerplate ("Hola X", "Quedo atento", asunto, firma, "Acá tenés el status").
Vocabulario aceptado
"el CMS", "tickets en Jira" (con sus IDs NAA-XXXX), "el equipo de Front/Back", "deploy", "versión 8.x.x", "tests automatizados", "el dashboard de reportes", "el agente IA del proyecto" (a alto nivel — no sus internals), nombres reales de personas que ya forman parte del contexto (Estefi, Fernando, etc. cuando ya aparecen en los bullets manuales del usuario).
Otras
- No inventar impacto: si un commit es ambiguo y
businessBullet arranca con [REVISAR]:, mostrarlo tal cual — la cobertura incompleta del parser es deuda del script.
- No expandir bullets manuales con detalles que no fueron provistos por el usuario.
- Omitir commits sin valor externo: muchos commits de infraestructura interna del agente IA, refactors de skills, audits cerrados, etc. no deben aparecer en el EOD aunque tengan
endOfDayRelevant: true en el JSON. La traducción es responsabilidad de la skill: si no hay un "para qué" externo razonable, no inflar el reporte.
- Sin commits con
endOfDayRelevant: false salvo --full explícito.
PASOS DE EJECUCIÓN
Paso 1 — Detectar parámetros
| Frase del usuario | Parámetro |
|---|
"hoy" / "del día" / "end of day" / "EOD" / "qué hice hoy" / "qué avancé hoy" | DAYS=1 |
"ayer" | --since ayer, --until hoy |
"últimos N días" | DAYS=N |
"esta semana" / "de la semana" | DAYS=7 |
| Sin parámetro temporal | DAYS=1 |
"sin filtrar" / "log completo" / "--full" | FULL=true (modo crudo, sin síntesis) |
Default: filtro end-of-day activo, modo síntesis ejecutiva.
Paso 2 — Detectar bullets manuales en el prompt
Después del comando, si el usuario pegó cualquiera de:
- Lista con
-, *, • o numerada (1., 2.)
- Bloque de texto introducido por "y además:", "más:", "también:", "manual:", "manuales:"
→ tratar cada item como un bullet manual. Si no hay nada → procede solo con commits.
Los bullets manuales no se preservan textualmente: pasan por el filtro del Paso 4 igual que los de commits.
Paso 3 — Ejecutar commit-parser
Modo síntesis (default):
./node_modules/.bin/tsx scripts/skills/commit-parser.ts \
--author jtcaldera-bluestack \
--days ${DAYS} \
--end-of-day
Modo --full: omitir --end-of-day.
El JSON resultante es array de ParsedCommit (hash, date, type, module, title, body, work, motivation, impact, businessBullet, endOfDayRelevant). Shape canónica en scripts/skills/commit-parser.ts § interface ParsedCommit.
Si el comando falla → ver MANEJO DE EXCEPCIONES § Error Git.
Paso 4 — Filtrar y normalizar (modo síntesis)
Bullets de commits:
- Texto del bullet — privilegiar en este orden:
- Si
motivation está → usarla (cuerpo escrito por smart-commit para el jefe).
- Si no, si
impact está → usarlo.
- Si no →
businessBullet (fallback del parser).
- Si arranca con
[REVISAR]: → mostrarlo tal cual.
- Consolidar por
work: commits que comparten el mismo Trabajo: <X> se mergean en un solo bullet.
- Deduplicar por valor: mismo
type + module + impacto idéntico → un solo bullet.
Bullets manuales — aplicar criterios ✅ INCLUIR / ❌ DESCARTAR / ⚠️ CONSOLIDAR de references/manual-bullets-filter.md. Lectura solo cuando el usuario pegó manuales en el prompt; en runs sin manuales este archivo no se consulta.
Paso 5 — Sintetizar (modo síntesis)
-
Resumen ejecutivo: 2-3 oraciones, prosa continua, sin bullets internos. Describe qué se logró en términos de avance/progreso, no de actividad. Mencionar los 1-2 ejes principales del día. Tono: jefe del proyecto.
- ✅ "Se cerró cobertura automatizada del flujo de publicación masiva en el framework y se reportaron dos bugs nuevos de Front que destrabaron a Front."
- ❌ "Modifiqué
MainPostPage.ts y agregué un test en sessions/posts/." (técnico, no comunica valor)
-
Logros: 3-7 bullets ordenados por impacto. Formato exacto (markdown estándar):
- **Título corto:** descripción de una oración.
Cada bullet ocupa una sola línea lógica en el archivo (sin saltos de línea internos). Si tras el filtrado quedan más de 7 → consolidar los de menor impacto. Si quedan menos de 3 → devolver lo que haya, no inflar con ruido descartado.
-
Próximos Pasos (default OFF): solo incluir si en el input hay compromisos pendientes concretos y rastreables (ej: "queda pendiente verificar X mañana", "hay que monitorear Y post-deploy"). Si no hay nada así, omitir la sección entera, incluido el encabezado. No inventar.
Paso 6 — Output
Modo síntesis (default)
Plantilla exacta del archivo .md (espaciado literal — copiar tal cual):
# End of Day — {DD de mes de YYYY}
{Resumen ejecutivo de 2-3 oraciones, prosa continua.}
## Logros
- **{Título 1}:** {descripción.}
- **{Título 2}:** {descripción.}
- **{Título N}:** {descripción.}
## Próximos pasos
- {Compromiso concreto rastreable al input.}
Si no hay próximos pasos rastreables, omitir el heading ## Próximos pasos y sus bullets — no dejar la sección vacía.
Reglas críticas del archivo:
# End of Day — DD de mes de YYYY con fecha en español (mes en minúsculas, ej. 5 de mayo de 2026).- Espaciado compacto: línea en blanco antes de cada
## heading, nunca después. El primer bullet va pegado al heading. Lo mismo entre el último bullet de Logros y el heading ## Próximos pasos: una línea en blanco antes del heading, ninguna después.
- Cada bullet en una sola línea lógica (no romper a mitad de oración).
- Sin
--- separadores. Sin emojis. Sin "Skill-retrospective aplicada" ni notas meta dentro del archivo.
- Las notas meta (resumen de cambios, retrospective, debugging) van al chat, fuera del archivo, después de confirmar la escritura.
Después de escribir, en el chat:
End of Day escrito en /mnt/c/Users/jutoc/Documents/Personal/Lecturas/BlueStack/END OF DAY.md ({N} logros, próximos pasos: sí/no).
Una sola línea. No re-imprimir el contenido del archivo.
Target del cuerpo del archivo: 10-14 líneas útiles. Máximo absoluto: 20 si el día fue genuinamente cargado. Si excede → consolidar bullets de menor impacto.
Modo --full (crudo)
Mismo destino y reglas de archivo (incluyendo espaciado compacto: bullets pegados al heading). Plantilla:
# End of Day — {DD de mes de YYYY} (log crudo)
## {FECHA grupo} — {N} avances
- {bullet 1}
- {bullet 2}
- {bullet N...}
Sin resumen ejecutivo. Sin sección de logros sintetizados. Sin próximos pasos. Solo fechas como ## headings y bullets crudos del parser, una línea cada uno. Fecha en español: 2026-04-07 → 07 de abril de 2026.
Paso 7 — Retrospective
Tras emitir el output, aplicar internamente skill-retrospective (CLAUDE.md § Triggers de Comportamiento exige retro al finalizar cualquier skill activa — status-report no está en las excepciones).
MANEJO DE EXCEPCIONES
Catálogo de escenarios + mensajes verbatim en references/exception-messages.md. El agente consulta solo la fila que aplica al escenario detectado.
NOTAS DE MANTENIMIENTO
Guía editorial para humanos en references/maintenance-notes.md. El agente runtime no la lee.
