andrea-steva/personal-agents-skills

Resumen de tarea

Cada tarea completada termina con un resumen: lo último en la respuesta, después de todas las llamadas a herramientas. Le dice al lector en diez segundos qué es ahora cierto, cómo lo sabemos y qué queda pendiente. Es un resumen, no un registro de la sesión.

Si el proyecto actual tiene su propia habilidad task-recap, síguela en su lugar: lleva los nombres de verificaciones y convenciones del proyecto.

Plantilla

### <glifo> <Título: qué es ahora cierto, ≤ 8 palabras>

<Una o dos frases: el resultado y por qué es importante. Sin narración del proceso.>

**Cambios**
- [`Archivo.ext`](ruta/a/Archivo.ext) — qué cambió, en pocas palabras
- [`Otro.ext`](ruta/a/Otro.ext:42) — …

**Verificaciones** · `compilación ✓` · `pruebas 14/14 ✓` · `lint ✓`

**Siguiente** — <el elemento abierto, decisión o seguimiento>

Glifo de estado

Exactamente un glifo, solo en el encabezado:

Glifo	Significado
✅	Hecho y verificado
⚠️	Hecho, pero algo no está verificado o una verificación falló
⛔	Bloqueado: no pudo finalizar (di por qué en el resumen)
🔎	Investigación o pregunta respondida, sin cambios de código

Secciones

• Título — el resultado, no la actividad: "Los resultados de búsqueda conservan su orden", no "Corregido error en SearchService".
• Resumen — una o dos frases. Nombra primero el efecto visible para el usuario, luego la causa o el enfoque si no es obvio.
• Cambios — un punto por archivo o grupo lógico, como máximo 6; agrupa el resto ("+ 4 traducciones en Localizable.xcstrings"). Los archivos son enlaces markdown relativos al directorio de trabajo, con :linea cuando un lugar es relevante. Omite la sección cuando no haya cambios.
• Verificaciones — una línea de insignias en código en línea, solo para lo que se ejecutó realmente en esta tarea, nombrado según las herramientas propias del proyecto:
  • compilación ✓ / compilación ✗, pruebas N/M ✓, ui ✓ (pruebas de UI o de extremo a extremo), lint ✓, tipos ✓ (verificador de tipos), changelog ✓, más cualquier verificación que las instrucciones del proyecto requieran (por ejemplo, una verificación de traducción).
  • Una verificación que aplica pero no se ejecutó se escribe como compilación – y se nombra en Siguiente o en el resumen. Nunca marques ✓ lo que no se ejecutó.
  • Omite la línea para tareas solo de documentación o investigación.
• Siguiente — una línea: la decisión que espera al usuario, el seguimiento o el estado de git (sin comprometer en main, PR abierto). Omítela cuando no haya nada pendiente.

Reglas

• Conciso: 4–12 líneas en total. Si necesita más, la lista de Cambios es demasiado detallada; agrúpala.
• Honesto: una prueba fallida o un paso omitido se indica claramente con ⚠️, nunca se oculta.
• Sin narración: nada de "Primero miré…, luego…". No repetir la solicitud. Sin despedidas ni "dime si…".
• Sin bloques de código a menos que el usuario deba ejecutar un comando; entonces un bloque bash con un comando, colocado después de Siguiente.
• Solo markdown simple: un encabezado ###, etiquetas en negrita, viñetas, código en línea. Sin tablas, sin emojis extra, sin reglas horizontales.
• Escribe en el idioma en que el usuario escribió; mantén nombres de archivos, código y etiquetas de insignias en inglés.
• Refiérete a PRs e issues como enlaces completos ([propietario/repo#94](https://github.com/propietario/repo/pull/94)), nunca un #94 desnudo.
• En la aplicación de escritorio de Claude, el resumen es el mensaje de cierre escrito después de la llamada wrap_up; no repite la pregunta mostrada en el cuadro de siguiente paso.

Ejemplos

Una funcionalidad:

### ✅ La pantalla de perfil muestra la fecha de registro

Cada perfil ahora muestra cuándo se registró el usuario, debajo del nombre, formateado según la configuración regional del usuario.

**Cambios**
- [`ProfileHeader.swift`](Sources/Profile/ProfileHeader.swift) — etiqueta de fecha de registro
- [`Localizable.xcstrings`](Sources/Profile/Resources/Localizable.xcstrings) — cadena `Joined %@`
- [`CHANGELOG.md`](CHANGELOG.md) — entrada bajo Sin publicar

**Verificaciones** · `compilación ✓` · `pruebas 32/32 ✓` · `lint ✓`

**Siguiente** — sin comprometer en `feature/profile-join-date`; listo para abrir el PR.

Un resultado parcial:

### ⚠️ El progreso de carga sobrevive a la entrada en segundo plano

El progreso ahora se deriva de los bytes que el servidor confirmó en lugar de un contador local, por lo que se mantiene correcto después de que la aplicación se suspenda.

**Cambios**
- [`UploadViewModel.swift`](Sources/Upload/UploadViewModel.swift:58) — progreso leído desde `acknowledgedBytes`

**Verificaciones** · `compilación ✓` · `pruebas 11/12 ✗` · `lint ✓`

**Siguiente** — `testPauseResume` todavía espera el contador antiguo; ¿actualizarlo o mantener el comportamiento de pausa anterior?

Una investigación:

### 🔎 El panel se retrasa porque la caché guarda tarde

El panel lee la caché antes de que finalice el guardado en segundo plano, por lo que muestra los datos anteriores hasta la próxima actualización.

**Siguiente** — corregir actualizando después de que termine el guardado en `SyncService`; ¿hacerlo aquí?