weekly-review

Revisión semanal — una página para cerrar la semana

Produce una página HTML corta que responde, al final de una semana laboral:

1. ¿Qué logré?
2. ¿Dónde fue mi tiempo?
3. ¿Qué se retrasó o sigue esperándome?
4. ¿Cuáles son las tres cosas que importan la próxima semana?

La página debe poderse leer en menos de tres minutos. Es un espejo, no un informe para un jefe: di lo que muestran los datos, incluidas las partes incómodas.

Paso 0 — Conocer al usuario y la semana

• Idioma: el idioma en que escribe el usuario. Todo en la página usa ese idioma, con los formatos de fecha y hora de esa configuración regional.
• Semana: la semana actual, de lunes a hoy, a menos que el usuario mencione otra. Si se ejecuta un lunes por la mañana, revisa la semana anterior.
• Horario laboral: usa lo que el usuario haya dicho o lo que indique un archivo weekly-review.config.md; de lo contrario, asume de 9:00 a 18:00, de lunes a viernes.
• Fuentes: usa las herramientas de calendario, correo, chat y tareas que estén conectadas. Nunca le pidas al usuario que conecte algo a mitad de la ejecución; trabaja con lo que haya.

Si no hay ninguna fuente conectada, no inventes una semana. Pídele al usuario que te cuente en unas líneas en qué trabajó y construye la revisión a partir de eso.

Paso 1 — Qué se logró

A partir de tareas completadas, correos enviados, documentos compartidos y reuniones realizadas, enumera los resultados de la semana, no la actividad.

• Escribe "Envié la propuesta de precios al cliente", no "Trabajé en precios".
• Agrupa por proyecto o tema cuando haya más de seis elementos.
• Máximo diez elementos. Si la semana produjo más, quédate con los que tengan un resultado visible.
• Solo enumera lo que una fuente confirme. Una reunión en el calendario prueba que fue programada, no lo que decidió.

Paso 2 — Dónde fue el tiempo

Solo a partir del calendario:

• Total de horas en reuniones y el porcentaje de las horas laborales que representa.
• Los tres bloques de tiempo más grandes por tema o proyecto.
• El bloque libre ininterrumpido más largo de la semana.
• Una frase de lectura: por ejemplo "Las reuniones ocuparon el 60% de tu semana y ningún bloque libre duró más de 90 minutos."

Omite eventos de todo el día, eventos rechazados y bloques marcados como concentración o personales. Si el calendario no está conectado, salta esta sección por completo.

Paso 3 — Qué se retrasó

• Tareas que vencían esta semana y siguen abiertas.
• Hilos de correo o chat donde alguien le preguntó algo al usuario y no obtuvo respuesta. Ignora boletines, notificaciones y remitentes automatizados.
• Reuniones que fueron canceladas o movidas sin una nueva fecha.

Máximo siete elementos, los más antiguos primero. Para cada uno, una línea: qué es, quién espera, desde cuándo.

Paso 4 — Tres prioridades para la próxima semana

Propón tres, nunca más, a partir de: lo que se retrasó, lo que vence la próxima semana y lo que el calendario de la próxima semana ya compromete. Para cada una, nombra el primer paso concreto.

Preséntalas como propuestas. El usuario decide; tú le das un punto de partida.

Paso 5 — Construir la página

Un único archivo HTML autocontenido:

• Una columna, cómodo en un teléfono, modo claro y oscuro mediante prefers-color-scheme.
• Título con las fechas de la semana, luego las cuatro secciones en orden.
• Sin scripts, fuentes ni imágenes externas.
• Un pie de página de una línea que nombre las fuentes utilizadas y las que faltaron.

Publícalo como artifact cuando esté disponible; de lo contrario, guárdalo como weekly-review-<YYYY-MM-DD>.html.

Reglas

• Solo lectura. Nunca envíes, respondas, aceptes, rechaces, completes o archives nada.
• Sin invención. Una fuente faltante significa una sección omitida, con una línea que diga por qué.
• Sin juzgar a la persona. Describe la semana, no al usuario.
• Privado. No cites el cuerpo de correos o mensajes; describe en tus propias palabras lo que está pendiente.
• Breve. Si una sección está vacía, dilo en una línea y sigue adelante.

Configuración (opcional)

Un archivo weekly-review.config.md puede establecer: idioma, horario laboral, el primer día de la semana, proyectos para agrupar, remitentes o calendarios que ignorar, y secciones adicionales (por ejemplo, un KPI que revisar o un hábito que seguir).

Programación

Si el usuario lo pide cada semana, propón el viernes a las 16:30 en su zona horaria y configúralo con la herramienta de programación disponible. En una ejecución programada no hay a quién preguntar: asume los supuestos documentados y anótalos en el pie de página.