Automatizar una checklist semanal de Excel con PowerShell, TypeScript y WSL

PowerShell se gana el sueldo convirtiendo un montón de clics en Windows en unas pocas líneas. Datos del equipo, servicios, tareas programadas: es el camino más rápido para llegar a todo eso. Si a eso le sumas las ganas de descubrir cómo encaja un agente de IA en el desarrollo real, no como generador de apps a partir de un solo prompt, sino como compañero para investigar APIs desconocidas, resolver errores, cuestionar un enfoque e iterar, tienes un experimento esperando un problema. Y el problema apareció solo.

Una checklist que pedía a gritos automatizarse

Mucha gente ha pensado alguna vez: "Debería llevar una checklist en Excel". Es una forma sencilla de no perder el rumbo, por ejemplo mientras buscas trabajo. Luego llega un segundo pensamiento. ¿De verdad vas a actualizarla cada semana? Eso significa pasar las tareas pendientes a la semana siguiente, archivar las terminadas en algún sitio, cambiar fechas, guardar la semana anterior y repetirlo todo para siempre.

Una repetición así despierta un reflejo de programador muy conocido: seguro que esto se puede automatizar. ¿Qué tan difícil puede ser?

Elegir el stack

El primer instinto fue PowerShell. El equipo usaba Windows, Excel estaba instalado en local, el Programador de tareas viene con el sistema y PowerShell sabe hablar con los tres.

Pero un único script gigante de PowerShell no resultaba atractivo. La idea era tener algo que otros desarrolladores pudieran leer y ampliar, y sobre lo que fuera fácil construir más adelante. Como casi todo el trabajo diario era JavaScript y TypeScript, TypeScript se convirtió en el esqueleto del proyecto y PowerShell se quedó solo con las partes específicas de Windows. Las capas quedan así:

TypeScript
    ↓
PowerShell
    ↓
Windows / Excel

TypeScript se encarga de la configuración y la orquestación. PowerShell hace lo que mejor se le da por naturaleza.

Líos con las rutas de WSL

El desarrollo se hizo en WSL, así que el proyecto se ejecuta desde Ubuntu mientras el archivo de Excel vive en Windows. Eso trae sus rarezas. Una ruta de WSL tiene este aspecto:

/mnt/c/Users/username/Documents/AutoTask/Weekly_Checklist.xlsx

pero Excel necesita la forma de Windows:

C:\Users\username\Documents\AutoTask\Weekly_Checklist.xlsx

WSL incluye wslpath justo para esta conversión. Desde TypeScript puedes traducir la ruta antes de pasársela a PowerShell:

const windowsChecklist = execFileSync(
  'wslpath',
  ['-w', checklist],
  { encoding: 'utf8' },
).trim();

Es breve, y ahora la app del lado de Linux le entrega a PowerShell una ruta de Windows como es debido.

Que Excel siga siendo Excel

El primer intento editaba el archivo .xlsx directamente con una librería de JavaScript. Técnicamente funcionaba: los datos se movían y el libro se abría. Pero el formato quedaba destrozado. Listas desplegables, estilos y comportamiento del libro, todo lo que hacía agradable la hoja, se convirtió en un problema mayor que el que se quería resolver.

Eso llevó a una decisión de arquitectura clave. ¿Para qué recrear el comportamiento de Excel si Excel ya está instalado? Mejor simplificar. PowerShell puede crear un objeto COM de Excel:

$excel = New-Object -ComObject Excel.Application

y después hacer que la aplicación de escritorio real abra el libro:

$workbook = $excel.Workbooks.Open($checklist)

Así, todo el formato existente se queda exactamente como estaba.

El cambio de semana

El script principal es rollover.ts. Toma la checklist actual y la deja lista para la semana siguiente. El libro tiene tres hojas:

• This Week guarda las tareas activas.
• Task History guarda las terminadas.
• Settings decide cosas como si las tareas pendientes se arrastran y si se conservan las notas.

Al ejecutarse, lee la fecha real del sistema y calcula el tramo actual de lunes a domingo. Eso importó más de lo esperado. Una versión temprana simplemente adelantaba el libro una semana en cada ejecución, lo que suena bien hasta que lo pruebas quince veces y descubres que te has automatizado hasta noviembre.

La solución fue convertir la fecha del sistema en la fuente de verdad. La lógica dejó de preguntar cuál era la semana del libro más siete días y empezó a preguntar qué semana es realmente.

Eso también resolvió un problema con la columna Weeks Carried. Una tarea pendiente no debería sumar una semana arrastrada más solo porque el script se ejecutó. Así que, en lugar de incrementar, el código cuenta las semanas entre la fecha original de arrastre de la tarea y la semana actual real. La operación ahora es idempotente: ejecutarla varias veces en la misma semana da siempre el mismo resultado. Mucho mejor.

Archivar la semana anterior

Antes de cambiar nada, el libro se copia en una carpeta Previous Weeks con un nombre que abarca el rango de la semana:

2026-09-07_to_2026-09-13.xlsx

Ese archivo es una copia completa del documento antes del cambio, con las tareas terminadas y pendientes tal como estaban. Después se actualiza el libro activo. Las tareas completadas van a Task History, las más recientes arriba. Las pendientes se quedan en la lista activa si el arrastre está activado. Se rellenan las fechas de la nueva semana y Excel guarda.

Programar el programador

Un script de cambio de semana sigue teniendo que recordarse y ejecutarse, lo que anula su sentido. Ahí entra configure.ts. La hoja Settings guarda un día de cambio, el lunes por defecto. El script de configuración abre el libro, lee ese valor y usa PowerShell para registrar una tarea programada de Windows.

La tarea también usa la opción StartWhenAvailable. Si el cambio toca el lunes a las 8:00 y el ordenador está apagado, Windows lo ejecuta la próxima vez que el equipo esté disponible. La hoja de cálculo ya se mantiene sola.

Dónde ayudó el agente de IA

Al agente de IA no se le pidió construir una checklist automatizada de Excel con una sola petición para aceptar el resultado tal cual. Participó en todo el proceso. El ritmo era más o menos este:

I define behavior
      ↓
AI suggests implementation
      ↓
I run it
      ↓
Something explodes
      ↓
We inspect the actual error
      ↓
Check documentation
      ↓
Fix it
      ↓
Run it again

Lo cual, pensándolo bien, se parece mucho al desarrollo de software de siempre. Donde más útil resultó el agente fue fuera de las tecnologías del día a día. PowerShell y TypeScript eran conocidos, pero la automatización COM de Excel tiene sus propias rarezas. Copiar valores entre celdas se comporta distinto según asignes .Value2 directamente o uses los propios Copy() y PasteSpecial() de Excel. Las fechas añaden otra capa, porque Excel las guarda como números de serie mientras PowerShell tiene sus propios tipos de .NET. Y todo cruza fronteras, de Node en WSL a PowerShell en Windows y por último a Excel mediante COM. Por momentos, el stack se veía más o menos así:

TypeScript
→ Node
→ WSL
→ PowerShell
→ COM
→ Excel
→ Why is this a System.Double?

Funcionó bien pegar el error exacto, explicar una teoría sobre la causa y luego usar el agente para dar con la documentación correcta de Microsoft. Lo más importante seguía siendo probar cada respuesta. Más de una vez, una sugerencia razonable sobre el papel se comportó de otra forma en cuanto Excel entró en juego.

Esa es la lección central sobre la IA en el desarrollo: acorta la distancia entre no saber algo todavía y saber qué probar. Acelera el aprendizaje y los tiempos de respuesta cuando ya tienes una imagen clara de la arquitectura. Eso es muy distinto de fiarse a ciegas del código generado.

Tu experiencia sigue al volante

El conocimiento técnico previo no dejó de rendir:

• Conocer PowerShell facilitó ver dónde encajaba PowerShell en el diseño.
• Conocer TypeScript dejó claro que la automatización de Windows no debía dirigir toda la aplicación.
• Entender las tareas programadas mostró que no hacía falta un proceso de Node ejecutándose todo el tiempo.
• Darse cuenta de cuándo una solución se estaba volviendo absurdamente complicada fue quizá la habilidad más valiosa de todas.

En varios momentos la implementación empezó a crecer alrededor de los problemas en lugar de resolverlos. Ahí, saber dirigir al agente, vetar ideas y devolverlo a un enfoque sensato funcionó mejor que dejar que él marcara el proyecto.

Lo que ven los usuarios

Desde el punto de vista del usuario, el flujo es sencillo. Usas la checklist de Excel como siempre: añades tareas, fijas prioridades, pones fechas límite y marcas lo hecho. Cuando cambia la semana, una copia del libro anterior va a la carpeta Previous Weeks, las tareas completadas pasan a la pestaña Task History y las pendientes fluyen al libro de la nueva semana.

Todo se queda en local. Sin base de datos, sin servidor, sin suscripción, nada ejecutándose en segundo plano. Las piezas móviles son Excel, TypeScript, PowerShell, WSL y el Programador de tareas de Windows. Hay que admitir que es mucha tecnología para una checklist semanal, pero el tamaño no era lo importante. Lo importante era tomar una tarea repetitiva, aplicar herramientas que ya entiendes y ver las piezas desconocidas como oportunidades para aprender. PowerShell dio el punto de partida, el agente de IA abrió una vía nueva hacia las partes desconocidas y una checklist pequeña y aburrida se convirtió en un proyecto de automatización sorprendentemente interesante. Nada mal para algo que empezó con la idea de que esto probablemente se podía automatizar.