ShockRock2004/kamar-taj

Wong — guía de aprendizaje de fin de jornada (antes diario-diario)

Convierte un día completo de trabajo con Claude Code (en todas las sesiones y repos) en un único archivo Markdown fechado, escrito como una guía didáctica, para que el usuario pueda aprender realmente del trabajo: re-implementar el código a mano, entender por qué se tomó cada decisión y ser capaz de explicar cómo funciona porque realmente lo entiende.

El resultado NO es un registro de cambios. Es un libro de texto para principiantes, escrito de forma tan sencilla y coloquial que alguien sin experiencia en software podría leerlo de principio a fin y entender tanto lo que se hizo como por qué. Cada término técnico se define en lenguaje sencillo la primera vez que aparece; el código sigue siendo técnico pero se envuelve en explicaciones en inglés sencillo. La profundidad y el "por qué" importan más que la exhaustividad de los detalles triviales. Consulta las reglas completas de Estilo de escritura — OBLIGATORIO en el paso 4.

Paso 0. Lee el nivel de esfuerzo del comando

El usuario puede pasar un nivel de esfuerzo como primer argumento: light, medium o heavy. Si no se da ninguno, el valor predeterminado es heavy. (También pueden pasar una fecha; un token YYYY-MM-DD es la fecha, un token light/medium/heavy es el esfuerzo. Cualquier orden, ambos opcionales. Por ejemplo: /wong medium, /wong light 2026-06-25).

El esfuerzo controla el uso de tokens: escala tanto el tamaño del resumen (a través de --effort en el recolector) como lo que haces mientras escribes:

• light — el más económico. Documenta solo las 2-3 tareas principales. No ejecutes git show/lecturas de archivos adicionales; confía en el resumen + los mensajes de commit, e incluye como máximo un fragmento de código corto en total. Mantén cada sección breve. Aun así, genera la sección de habilidades de Git, el resumen de Slack, el PDF y la subida.
• medium — equilibrado. Documenta las ~5 tareas principales. Extrae código real (git show) solo para las 2-3 más importantes. Profundidad moderada.
• heavy (predeterminado) — el tratamiento completo descrito a continuación: cada tarea de trabajo distinta, extrae código real para cada una, profundidad total.

Mantén el nivel elegido en todos los pasos.

Pasos

1. Recopila el material del día

Ejecuta el recolector con el esfuerzo elegido (lee todas las transcripciones de sesión del disco, por lo que captura todas las sesiones concurrentes/cerradas, no solo esta):

python3 ~/.claude/skills/wong/collect_day.py --effort heavy

Reemplaza heavy con el nivel del Paso 0. Para registrar un día pasado, añade la fecha: python3 ~/.claude/skills/wong/collect_day.py --effort medium 2026-06-25

Imprime la ruta a un archivo de resumen (~/Daily Log/.digest-<date>.md). Lee ese resumen por completo. Contiene, por repositorio: el mapa de commits de Git del día, estadísticas de cambios no confirmados y, por sesión: las indicaciones del usuario, los archivos que Claude editó, la prosa explicativa de Claude y cualquier resultado de subagente.

También lee el glosario en ~/Daily Log/.glossary.md (si no existe, trátalo como vacío). Enumera los términos triviales/fundamentales ya explicados en días anteriores. NO volverás a explicar nada que ya esté en él; consulta "Explicar términos triviales solo una vez" en el paso 4.

Si el resumen indica que no hubo sesiones activas, comunícaselo al usuario y detente.

2. Identifica características/tareas distintas

Agrupa el trabajo del día en tareas de trabajo distintas, no una sección por sesión. Fusiona sesiones/commits que avanzaron la misma característica. Una "tarea de trabajo" es algo que el usuario podría señalar como una pieza de trabajo diferenciada (por ejemplo, "la corrección del error de entrega de llamadas del agente verto", "el límite de tasa de abandono del marcador predictivo"). Apunta a las pocas cosas que realmente importaron; no incluyas trivialidades.

3. Obtén el código real para cada tarea

Puerta de esfuerzo: en light, omite este paso por completo (sin git show/lecturas de archivos — usa el resumen + mensajes de commit, máximo un fragmento en total). En medium, haz esto solo para las 2-3 tareas más importantes. En heavy, hazlo para cada tarea.

El resumen enumera los SHA de los commits y los archivos editados, pero NO los diff completos. Para cada tarea que estés documentando, extrae el código real para que los fragmentos sean reales, no parafraseados:

git -C <repo> show <sha>            # diff completo de un commit
git -C <repo> show <sha> -- <path>  # diff de un archivo
git -C <repo> diff -- <path>        # trabajo no confirmado

O lee el archivo actual en las líneas relevantes. Prefiere mostrar las líneas clave (las que transmiten la idea) en lugar de volcar archivos completos.

Consulta el CLAUDE.md del repositorio y docs/GOTCHAS.md (si existe) para buscar minas terrestres relevantes para el trabajo; son oro para la sección "Errores y lecciones".

4. Escribe la guía didáctica — INCREMENTALMENTE, nunca sobrescribas

Formato del nombre del archivo. El archivo se guarda en ~/Daily Log/ y se nombra:

<YYYY-MM> - <DD> - <una línea de lo que hicimos ese día>.md

Por ejemplo: 2026-06 - 26 - Corregida la entrega de llamadas del agente y comenzada la página de aterrizaje 3D de Yotel.md. La parte de una línea es un titular corto y en lenguaje sencillo del trabajo del día (sin guiones, ya que los separadores de fecha ya usan " - "; mantenlo por debajo de ~12 palabras). El encabezado # superior del archivo debe ser la misma cadena que el nombre del archivo sin la extensión .md.

Encontrar el archivo de hoy (importante para la lógica de añadir). Debido a que el sufijo de una línea varía, nunca busques un archivo exacto <date>.md. En su lugar, encuentra el archivo de hoy por su prefijo de fecha: lista ~/Daily Log/ y busca la coincidencia del archivo que comienza con <YYYY-MM> - <DD> - (por ejemplo, ls "~/Daily Log/" y elige el que comienza con 2026-06 - 26 - ). Hay como máximo uno por día.

Esta habilidad puede ejecutarse varias veces en un día. En cada ejecución después de la primera, debes añadir solo el trabajo aún no documentado — nunca sobrescribas ni dupliques lo que ya está.

Procedimiento:

1. Si no existe ningún archivo para hoy (ningún archivo coincide con el prefijo de fecha): créalo con la estructura completa a continuación (Resumen del día + una sección por tarea de trabajo, numeradas ## 1., ## 2., …), nombrado en el formato anterior.
2. Si el archivo de hoy YA EXISTE (encontrado mediante el prefijo de fecha): léelo primero. Construye un conjunto de lo que ya está cubierto escaneando sus encabezados ## N. <título> existentes y los SHA de commits / identificadores de sesión en cada línea de Referencias. Luego, del resumen de hoy, identifica las tareas de trabajo cuyos commits/sesiones aún no están en ese conjunto.
   • Mantén la línea de una línea del nombre del archivo precisa para todo el día: si el trabajo recién añadido cambia cuál debería ser el titular del día, renombra el archivo (y actualiza su encabezado # para que coincida) para que la línea de una línea aún refleje todo lo hecho ese día. Si el titular aún encaja, deja el nombre como está.
   • Si no hay nada nuevo, dile al usuario que el archivo ya está actualizado y detente (no lo reescribas).
   • De lo contrario, añade nuevas secciones ## N. (continuando la numeración existente) solo para el trabajo nuevo, utilizando la misma plantilla por característica.
   • Actualiza el bloque Resumen del día en su lugar: aumenta los recuentos de Commits/Sesiones y amplía el Titular para mencionar el trabajo recién añadido. No toques las secciones de características existentes.
   • Usa Editar (inserciones dirigidas), no una sobrescritura completa, para que las secciones anteriores — incluyendo aquellas que editaste a mano — se conserven textualmente.

Trata una "tarea de trabajo" como ya cubierta si su(s) SHA de commit o el identificador de sesión ya aparecen en el archivo. Coincide con esos identificadores, no con la redacción, para que una re-ejecución nunca produzca una sección casi duplicada.

Estilo de escritura — OBLIGATORIO (este es el objetivo principal)

Escríbelo como un capítulo de libro de texto para un completo principiante — alguien inteligente que no sabe nada sobre software. El lector debe poder seguir cada sección de principio a fin sin contexto previo.

• Coloquial y simple. Oraciones cortas. Palabras sencillas. Explica como si hablaras con un amigo, no como si escribieras un informe. Evita la jerga en la narrativa.
• Define cada término técnico una vez en toda la serie, no una vez al día. La primera vez que aparece un término alguna vez, defínelo en lenguaje cotidiano en un cuadro de cita: > **Qué significa "X".** … (usa analogías del mundo real). Pero primero verifica el glosario (~/Daily Log/.glossary.md) y nunca re-definas un término que ya esté enumerado allí. Esto es más importante para conceptos básicos triviales y recurrentes: qué es un repo/commit/rama, qué es Yotel, git básico; explícalos una vez y luego simplemente úsalos. Un término completamente nuevo que es genuinamente central para el trabajo de hoy aún recibe su cuadro; un concepto básico que ya se ha cubierto antes no. Consulta "Explicar términos triviales solo una vez" a continuación para conocer los detalles.
• Mantente técnico solo donde la precisión técnica es el punto — por ejemplo, el cambio de código real, el archivo exacto, la compensación real. Muestra el código real, pero envuélvelo en explicación en lenguaje sencillo antes y después, y comenta el fragmento en lenguaje sencillo. Nunca te limites a volcar código.
• Encabeza cada sección con la "versión cotidiana" — la historia en lenguaje sencillo de lo que estaba roto/era necesario y por qué es importante — antes de cualquier detalle técnico.
• Usa una nota corta "Cómo leer este documento" al principio, y una descripción general "El panorama general (lee esto primero)" que explique los proyectos en términos sencillos (qué es este producto, quién lo usa, por qué).
• Mantén los puntos de "cómo explicarlo" en forma de una oración sencilla y segura, seguida de la única idea inteligente para explicar de forma simple.
• Sé honesto: separa claramente el código real enviado de la configuración/exploración, y dilo en palabras sencillas.

Coincide con el tono del archivo existente más reciente en ~/Daily Log/ (léelo como ejemplo de referencia si existe uno).

Explicar términos triviales solo una vez (el glosario)

Un lector de toda la serie no debería ver "qué es un repo" o "qué es Yotel" re-explicado todos los días. Así que:

1. Antes de escribir, lee ~/Daily Log/.glossary.md (la lista de términos ya explicados). Trata todo lo que está en él como conocido — no escribas un cuadro > **Qué significa "X".** para ningún término de la lista. Simplemente usa el término normalmente.
2. Mientras escribes, solo añade un cuadro de definición para un término que sea genuinamente nuevo en la serie (no está en el glosario). Inclínate fuertemente en contra de re-definir conceptos básicos triviales; si tienes dudas sobre un concepto básico, asume que ya se ha cubierto y omítelo.
3. Después de escribir/añadir, actualiza ~/Daily Log/.glossary.md: añade (uno por línea) cualquier término que hayas definido por primera vez hoy. Nunca elimines las entradas existentes. Si el archivo no existe, créalo.

Esto se aplica ante todo a términos triviales y recurrentes (repo, commit, rama, árbol de trabajo, qué es el producto, git básico). Un término complejo que es el corazón del trabajo de un día aún puede explicarse ese día, pero una vez que está en el glosario, no se vuelve a explicar más adelante.

Plantilla por característica y estructura del Resumen del día (adapta los encabezados a la voz amigable para principiantes anterior — estos son los contenidos a cubrir, no etiquetas rígidas para copiar textualmente):

# <YYYY-MM> - <DD> - <una línea de lo que hicimos ese día>

> **Cómo leer este documento.** (1-2 oraciones que indiquen a un principiante cómo usarlo.)

## El panorama general (lee esto primero)
Descripción general en lenguaje sencillo de lo que se hizo hoy. Define "proyecto/repositorio", "commit" y qué es el producto (por ejemplo, Yotel) aquí **solo si aún no están en el glosario** — es decir, en el primer registro. En todos los días posteriores, omite esos conceptos básicos y la explicación de "qué es este producto"; simplemente nómbralos y continúa.

---

## 1. <Título en lenguaje sencillo de la tarea>   (<repo>)

### La versión cotidiana
La historia sin jerga: qué estaba roto o era necesario, y por qué es importante para una persona real. Usa una analogía.

### Lo que realmente estaba pasando / la solución (la parte técnica)
Ahora el detalle preciso: la causa real, el cambio de código real (mostrado y explicado en inglés sencillo con fragmentos comentados), la ruta exacta del archivo `path`. Pon un cuadro `> **Qué significa "término".**` antes de cada palabra técnica nueva.

### Cómo podrías hacer esto tú mismo, paso a paso
Pasos numerados y concretos que un principiante podría seguir.

### Cómo explicarlo (una vez que lo entiendes)
- Un resumen de una oración sencilla de lo que hace el trabajo.
- La única idea inteligente, explicada de forma simple.
- La compensación a defender, en términos cotidianos.

### Lecciones que vale la pena recordar
Conclusiones en lenguaje sencillo + cualquier mina terrestre relevante de CLAUDE.md / docs/GOTCHAS.md.

**Dónde encontrarlo:** archivos, SHA(s) de commit, identificador(es) de sesión.

---

## 2. <siguiente tarea…>

---

## Habilidades de Git utilizadas hoy
(Siempre la ÚLTIMA sección del documento. Construida a partir de los bloques "Comandos de Git ejecutados por Claude" del resumen; consulta las instrucciones dedicadas a continuación.)

### <operación de git, por ejemplo, Confirmar cambios>   `git commit`
**Qué hizo** — en palabras sencillas, qué logró este comando hoy.
**Por qué** — por qué este paso era necesario en ese punto del flujo de trabajo.
**Cómo hacerlo tú mismo** — el comando real con una nota corta sobre qué significa cada parte y bandera, para que el lector pueda ejecutarlo manualmente.

### <siguiente operación de git…>

La sección "Habilidades de Git utilizadas hoy" — OBLIGATORIA (siempre la última sección)

Termina el documento de cada día con una sección ## Habilidades de Git utilizadas hoy, construida a partir de los bloques "Comandos de Git ejecutados por Claude" en el resumen (un bloque por sesión).

Cómo construirla:

1. Recopila todos los comandos de git de cada sesión en el resumen. Una entrada capturada puede ser un comando compuesto (por ejemplo, cd repo && git add ... && git commit ...); extrae la(s) parte(s) de git.
2. Agrúpalos por operación de git (por ejemplo, confirmar, crear una rama, crear un árbol de trabajo, subir, preparar, almacenar, restaurar, reorganizar, inspeccionar con log/diff/show/status). Una subsección por operación distinta — no enumeres la misma operación muchas veces. Si muchos comandos son solo de inspección de solo lectura (git status, git log, git diff, git show), cúbrelos juntos en una subsección corta "Mirando alrededor del repositorio" en lugar de uno por uno.
3. Para cada operación, escribe tres cosas con la voz amigable para principiantes que se usa en todas partes del documento:
   • Qué hizo — qué logró esto en el trabajo real de hoy.
   • Por qué — por qué ese paso era necesario en ese momento.
   • Cómo hacerlo tú mismo — el comando real, con una nota sencilla sobre qué significa cada parte y bandera importante, para que el lector pueda ejecutarlo manualmente. Pon un cuadro > **Qué significa "X".** antes del primer uso

... [truncado para traducción]

La sección de resumen de Slack

Después de la sección de habilidades de Git, genera un resumen de Slack del día. Usa la API de Slack para enviarlo al canal o usa el archivo. (Los detalles de implementación pueden variar).

La sección de PDF

Después del resumen de Slack, genera un PDF del archivo de registro del día. Usa pandoc u otra herramienta. (Los detalles de implementación pueden variar).

La sección de subida

Después del PDF, sube el archivo de registro del día y el PDF a un servicio de almacenamiento o a un repositorio remoto. (Los detalles de implementación pueden variar).

5. Finaliza y confirma

Al final de la ejecución, confirma que todo esté correcto y proporciona un resumen de lo que se hizo.

Notas adicionales

• Múltiples ejecuciones en un día: Como se mencionó, la habilidad está diseñada para ser ejecutada varias veces en un día. Siempre verifica el archivo existente antes de escribir.
• Glosario compartido: Todos los registros comparten un solo glosario para evitar la redefinición de términos.
• Niveles de esfuerzo: Ajusta la profundidad y el costo según el nivel de esfuerzo elegido.
• Formato de salida: El formato del archivo de salida está estrictamente definido. Síguelo exactamente.