---

name: TASK-DONE description: > Marca una feature de docs/features/ como terminada: actualiza sus checkboxes, la mueve a docs/done/, agrega/actualiza su fila en docs/logros.md y agrega una entrada en docs/changelog-interno.md (técnico) y docs/changelog.md (para compartir con el cliente/usuarios externos). Usar cuando el usuario dice "marcar feature como done", "actualizar estado de features", "cerrar feature", "feature terminado", o pide reflejar que un trabajo ya quedó completo en la documentación del proyecto.

TASK-DONE

Propósito

Cuando una feature de docs/features/*.md queda completa (o se retoma/ajusta después de estar en docs/done/), este skill deja consistentes los 4 lugares donde el proyecto trackea trabajo terminado:

1. El doc de la feature (checkboxes + estado)
2. docs/logros.md (tabla para el cliente, no técnico, con impacto/pago)
3. docs/changelog-interno.md (historial técnico, uso interno — NO compartir con el cliente)
4. docs/changelog.md (novedades en lenguaje simple, SÍ se puede compartir con el cliente/usuarios externos)

No commitear ni hacer push — solo dejar los archivos editados, como el resto del flujo de este proyecto.

Si docs/ o alguno de estos archivos no existe

Crearlos. No asumir que ya existen ni preguntar — si falta la carpeta docs/, crearla; si falta docs/logros.md, docs/changelog-interno.md o docs/changelog.md, crearlos con un header mínimo (título + una línea de propósito, igual que los existentes) antes de agregar la entrada nueva.

Proceso

1. Doc de la feature (docs/features/<nombre>.md o docs/done/<nombre>.md)

• Marcar todos los ítems de ## Todo list con [x]
• Actualizar ## Estado con una línea corta: qué quedó activo, fecha (formato YYYY-MM-DD, usar la fecha actual del sistema)
• Si el archivo vive en docs/features/, moverlo a docs/done/ con git mv
• Si ya vive en docs/done/ (se está reactivando o cerrando un ajuste posterior), no moverlo de nuevo — solo actualizar ## Estado

2. docs/logros.md

• Buscar si ya existe una fila para esta feature (por nombre)
  • Si existe: actualizar Fecha fin a la fecha de hoy
  • Si no existe: agregar una fila nueva al final de la tabla
• Redactar la columna Descripción en lenguaje simple, sin jerga técnica — el cliente no es técnico
• Elegir Impacto (Bajo/Medio/Alto) según complejidad real: cuántos archivos, si tocó backend/DB, si es una feature nueva vs. un ajuste
• Pago: dejar como está si la fila ya existía (no asumir que se cobró); si es fila nueva, usar Todavía

3. docs/changelog-interno.md (técnico, interno)

• Agregar una entrada nueva al inicio del archivo (después del header, antes de la entrada más reciente existente)
• Formato: ## YYYY-MM-DD — Título corto
• Contenido técnico: qué se tocó, decisiones de diseño, gotchas encontrados (ej. bugs de contraste, APIs deprecadas, workarounds) — este archivo sí lleva detalle técnico

4. docs/changelog.md (externo, compartible)

• Agregar una entrada nueva al inicio del archivo (mismo formato ## YYYY-MM-DD — Título corto)
• Redactar en lenguaje 100% no técnico, orientado a "qué puede hacer ahora el usuario" — nada de nombres de archivos, librerías, decisiones internas ni bugs
• Esta entrada normalmente es una versión resumida de la fila que se agregó en docs/logros.md

Ejemplo de una pasada completa

Ver docs/done/feat-share-routine.md (Estado + Todo list), la fila "Compartir y guardar rutinas" en docs/logros.md, la entrada 2026-07-11 en docs/changelog-interno.md, y la entrada equivalente en docs/changelog.md — esa secuencia es el resultado esperado de una corrida de este skill.

Boundaries

• No inventar fechas de inicio para features viejas si no hay commit/dato real — buscar en git log primero
• No marcar Pago como Pagado sin que el usuario lo confirme explícitamente
• No borrar contenido existente en ninguno de los 4 archivos — solo agregar/actualizar
• Nunca poner detalle técnico (nombres de archivo, librerías, bugs internos) en docs/changelog.md — eso es exclusivo de docs/changelog-interno.md
• Si la feature tiene cambios de código pendientes de verificar (sin probar en navegador), decirlo en ## Estado en vez de afirmar que está 100% validado