Automating a Weekly Excel Checklist With PowerShell, TypeScript and WSL

PowerShell earns its keep by turning a pile of Windows clicking into a few lines. Machine details, services, scheduled tasks: it's the quickest route to all of them. Pair that with the wish to find out how an AI agent fits into real development work, not as a one-prompt app generator but as a partner for researching unfamiliar APIs, working through errors, questioning an approach and iterating, and you've got an experiment waiting for a problem. Here's one that turned up on its own.

A checklist that wanted to be automated

Plenty of people have thought "I should keep an Excel checklist." It's an easy way to stay on task, say during a job hunt. Then a second thought arrives. Will you really keep updating it every single week? That means copying unfinished items into the next week, filing finished ones somewhere, changing dates, saving the old week and doing it all again forever.

Repetition like that triggers a familiar programmer reflex: surely this can be automated. How hard could it be?

Picking the stack

The first instinct was PowerShell. The machine ran Windows, Excel was installed locally, Task Scheduler came with the OS, and PowerShell can talk to all three.

But one giant PowerShell script wasn't appealing. The goal was something other developers could read and extend, and something easy to build on later. Since most day-to-day work was JavaScript and TypeScript, TypeScript became the project skeleton and PowerShell took on only the Windows-specific parts. The layering looks like this:

TypeScript
    ↓
PowerShell
    ↓
Windows / Excel

TypeScript handles configuration and orchestration. PowerShell does what it's naturally good at.

WSL path trouble

Development happened in WSL, so the project runs from Ubuntu while the Excel file sits on Windows. That brings quirks. A WSL path looks like this:

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

but Excel needs the Windows form:

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

WSL ships wslpath for exactly this conversion. From TypeScript you can translate the path before passing it to PowerShell:

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

That's short, and now the Linux-side app hands PowerShell a proper Windows path.

Let Excel be Excel

The first attempt edited the .xlsx file directly with a JavaScript library. Technically it worked: the data moved and the workbook opened. But the formatting got wrecked. Dropdowns, styling and workbook behavior, everything that made the sheet pleasant to use, turned into a bigger problem than the one being solved.

That led to a key architectural call. Why recreate Excel's behavior when Excel is already installed? Simplify instead. PowerShell can create an Excel COM object:

$excel = New-Object -ComObject Excel.Application

and then have the real desktop application open the workbook:

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

With that, all existing formatting stays exactly as it was.

The weekly rollover

The main script is rollover.ts. It takes the current checklist and gets it ready for the next week. The workbook has three sheets:

• This Week holds active tasks.
• Task History holds finished ones.
• Settings decides things such as whether unfinished tasks carry forward and whether notes are kept.

When it runs, it reads the real system date and works out the current Monday-to-Sunday span. That mattered more than expected. An early version simply pushed the workbook ahead one week per run, which sounds fine until you test it fifteen times and discover you've automated your way into November.

The fix was to make the system date the source of truth. The logic stopped asking what the workbook's week plus seven days was and started asking which week it actually is.

That also solved a problem with the Weeks Carried column. An unfinished task shouldn't pick up an extra carried week just because the script ran. So instead of incrementing, the code counts the weeks between the task's original carried date and the real current week. The operation is now idempotent: running it several times in one week gives the same result each time. Much better.

Archiving the old week

Before anything changes, the workbook is copied into a Previous Weeks folder under a name covering the week's range:

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

That archive is a full copy of the pre-rollover file, with finished and unfinished tasks exactly as they stood. Then the live workbook is updated. Completed tasks land in Task History, newest on top. Unfinished tasks stay in the active list if carry-forward is on. The new week's dates are filled in, and Excel saves.

Scheduling the scheduler

A rollover script still has to be remembered and run, which defeats the point. That's where configure.ts comes in. The Settings sheet stores a rollover day, Monday by default. The configuration script opens the workbook, reads that value and uses PowerShell to register a Windows scheduled task.

The task also uses the StartWhenAvailable option. If rollover is due Monday at 8:00 AM and the computer is off, Windows runs it the next time the machine is available. The spreadsheet now maintains itself.

Where the AI agent helped

The AI agent wasn't asked to build an automated Excel checklist from one request, with the result accepted as given. It took part in the whole process. The rhythm looked like this:

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

Which, come to think of it, is much like ordinary software development. The agent proved most useful outside everyday technologies. PowerShell and TypeScript were familiar, but Excel COM automation has its own strange behaviors. Copying values between cells acts differently depending on whether you assign .Value2 directly or use Excel's own Copy() and PasteSpecial(). Dates add another layer, because Excel stores them as serial numbers while PowerShell has its own .NET types. And everything crosses a boundary, from Node in WSL to PowerShell on Windows and finally into Excel through COM. At times the stack looked roughly like this:

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

Pasting the exact error, explaining a theory about the cause and then using the agent to find the right Microsoft documentation worked well. What mattered most was still testing every answer. More than once, a suggestion that looked reasonable on paper behaved differently once Excel got involved.

That's the central lesson about AI in development here: it shortens the distance between not knowing something yet and knowing what to test. It speeds up learning and turnaround once you've got a solid architectural picture. That's very different from trusting generated code blindly.

Your experience still steers

Existing technical knowledge kept paying off:

• Knowing PowerShell made it easy to see where PowerShell belonged in the design.
• Knowing TypeScript made it clear that Windows automation shouldn't run the whole application.
• Understanding scheduled tasks showed there was no need for a continuously running Node process.
• Recognizing when a solution was getting absurdly complicated was perhaps the most valuable skill of all.

At several points the implementation started growing around problems instead of solving them. That's when being able to direct the agent, veto ideas and steer it back to a sensible approach beat letting it dictate the project.

What users see

From the user's seat the workflow is plain. Use the Excel checklist as normal: add tasks, set priorities, give due dates, mark things done. When the week changes, a copy of the old workbook goes into the Previous Weeks folder, completed tasks move to the Task History tab and unfinished tasks flow into the new week's workbook.

Everything stays local. No database, no server, no subscription, nothing running in the background. The moving parts are Excel, TypeScript, PowerShell, WSL and Windows Task Scheduler. That's admittedly a lot of technology for a weekly checklist, but the size wasn't the point. The point was taking a repetitive chore, applying tools you already understand, and treating the unfamiliar pieces as chances to learn. PowerShell gave a starting point, the AI agent offered a new way into the unfamiliar parts, and a dull little checklist turned into a surprisingly interesting automation project. Not bad for something that began with the thought that this could probably be automated.