Автоматизація щотижневого чек-листа в Excel за допомогою PowerShell, TypeScript і WSL

PowerShell виправдовує себе тим, що перетворює купу кліків у Windows на кілька рядків. Відомості про машину, служби, заплановані завдання: до всього цього через нього дістатися найшвидше. Додайте бажання зрозуміти, як ШІ-агент вписується в справжню розробку, не як генератор застосунків за одним промптом, а як напарник, з яким розбираєшся в незнайомих API, розплутуєш помилки, ставиш під сумнів підхід і пробуєш знову, і вийде експеримент, якому бракує лише задачі. Задача знайшлася сама.

Чек-лист, який просився в автоматизацію

Чимало людей хоч раз думали: "Треба б вести чек-лист в Excel". Це простий спосіб не збиватися з курсу, скажімо під час пошуку роботи. А потім приходить друга думка. Ви справді оновлюватимете його щотижня? Це означає переносити незакриті пункти на наступний тиждень, відкладати виконані кудись убік, міняти дати, зберігати старий тиждень і повторювати все це без кінця.

Така одноманітність запускає знайомий рефлекс програміста: це ж напевно можна автоматизувати. Наскільки це взагалі складно?

Вибір стека

Першим спав на думку PowerShell. На машині стояла Windows, Excel був встановлений локально, Планувальник завдань входить до системи, і PowerShell уміє працювати з усіма трьома.

Але один величезний скрипт на PowerShell не надихав. Хотілося отримати те, що інші розробники зможуть прочитати й розширити і на чому легко будувати далі. Більша частина повсякденної роботи була на JavaScript і TypeScript, тож каркасом проєкту став TypeScript, а PowerShell дісталися лише частини, прив’язані до Windows. Шари виглядають так:

TypeScript
    ↓
PowerShell
    ↓
Windows / Excel

TypeScript відповідає за конфігурацію та оркестрацію. PowerShell робить те, що в нього виходить найкраще.

Проблеми зі шляхами у WSL

Розробка йшла у WSL, тому проєкт запускається з Ubuntu, а файл Excel лежить у Windows. Звідси свої дивацтва. Шлях у WSL має такий вигляд:

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

а Excel потрібен шлях у форматі Windows:

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

Саме для такого перетворення у WSL є wslpath. З TypeScript можна перекласти шлях, перш ніж передати його в PowerShell:

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

Коротко, і тепер застосунок на боці Linux передає PowerShell нормальний шлях Windows.

Хай Excel лишається Excel

У першій спробі файл .xlsx редагувався напряму через JavaScript-бібліотеку. Формально все працювало: дані переносилися, книга відкривалася. Але форматування розсипалося. Випадні списки, стилі й поведінка книги, усе, що робило таблицю зручною, перетворилося на проблему більшу за ту, яку розв’язували.

Це привело до ключового архітектурного рішення. Навіщо відтворювати поведінку Excel, якщо Excel уже встановлений? Краще спростити. PowerShell уміє створювати COM-об’єкт Excel:

$excel = New-Object -ComObject Excel.Application

а потім відкривати книгу у справжньому настільному застосунку:

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

За такого підходу все наявне форматування лишається точно таким, яким було.

Щотижневе перенесення

Головний скрипт називається rollover.ts. Він бере поточний чек-лист і готує його до наступного тижня. У книзі три аркуші:

• This Week містить активні завдання.
• Task History містить виконані.
• Settings визначає, наприклад, чи переносяться незакриті завдання і чи зберігаються нотатки.

Під час запуску скрипт читає реальну системну дату й обчислює поточний проміжок з понеділка по неділю. Це виявилося важливішим, ніж здавалося. Рання версія просто зсувала книгу на тиждень уперед під час кожного запуску. Звучить нормально, доки не протестуєш п’ятнадцять разів і не виявиш, що автоматично докотився до листопада.

Рішення полягало в тому, щоб вважати системну дату джерелом істини. Логіка перестала питати, який тиждень у книзі плюс сім днів, і почала питати, який тиждень насправді.

Заразом розв’язалася проблема зі стовпцем Weeks Carried. Незакрите завдання не повинно отримувати зайвий перенесений тиждень лише тому, що скрипт запустився. Тому замість збільшення лічильника код рахує тижні між початковою датою перенесення завдання і реальним поточним тижнем. Операція стала ідемпотентною: скільки не запускай її протягом одного тижня, результат щоразу однаковий. Значно краще.

Архівування минулого тижня

Перш ніж щось змінювати, книга копіюється в папку Previous Weeks під назвою, у якій зазначено діапазон тижня:

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

Цей архів — повна копія файлу до перенесення, з виконаними й незакритими завданнями точно в тому вигляді, у якому вони були. Потім оновлюється робоча книга. Виконані завдання потрапляють до Task History, найновіші зверху. Незакриті лишаються в активному списку, якщо перенесення ввімкнене. Проставляються дати нового тижня, і Excel зберігає файл.

Плануємо планувальник

Скрипт перенесення все одно треба пам’ятати й запускати, а це вбиває весь сенс. Тут у гру вступає configure.ts. На аркуші Settings зберігається день перенесення, за замовчуванням понеділок. Скрипт конфігурації відкриває книгу, читає це значення і через PowerShell реєструє заплановане завдання Windows.

Завдання також використовує опцію StartWhenAvailable. Якщо перенесення призначене на понеділок о 8:00, а комп’ютер вимкнений, Windows запустить його, щойно машина стане доступною. Тепер таблиця обслуговує себе сама.

Де допоміг ШІ-агент

ШІ-агента не просили зібрати автоматизований чек-лист Excel за одним запитом, щоб потім прийняти результат як є. Він брав участь у всьому процесі. Ритм був приблизно такий:

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

Якщо подумати, це дуже схоже на звичайну розробку. Найбільше агент знадобився поза межами повсякденних технологій. PowerShell і TypeScript були знайомі, але COM-автоматизація Excel має свої дивацтва. Копіювання значень між клітинками поводиться по-різному залежно від того, чи присвоюєте ви .Value2 напряму, чи використовуєте власні Copy() і PasteSpecial() з Excel. Дати додають ще один шар: Excel зберігає їх як порядкові числа, а PowerShell має власні типи .NET. І все перетинає межі: від Node у WSL до PowerShell у Windows і зрештою в Excel через COM. Часом стек виглядав приблизно так:

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

Добре працювала така схема: вставити точний текст помилки, пояснити свою версію причини, а потім за допомогою агента знайти потрібну документацію Microsoft. Найважливішим, як і раніше, було перевіряти кожну відповідь. Не раз порада, розумна на папері, поводилася інакше, щойно до справи долучався Excel.

У цьому й головний урок про ШІ в розробці: він скорочує шлях від «я цього поки не знаю» до «я знаю, що перевірити». Він пришвидшує навчання й обіг, коли у вас уже є чітка архітектурна картина. Це зовсім не те саме, що сліпо довіряти згенерованому коду.

Кермує все одно ваш досвід

Наявні технічні знання раз у раз окупалися:

• Знання PowerShell допомогло легко зрозуміти, де йому місце в архітектурі.
• Знання TypeScript дало зрозуміти, що автоматизація Windows не повинна керувати всім застосунком.
• Розуміння запланованих завдань показало, що постійно запущений процес Node не потрібен.
• Уміння помітити, що рішення стає абсурдно складним, було, мабуть, найціннішою навичкою.

Кілька разів реалізація починала обростати проблемами замість того, щоб їх розв’язувати. У такі моменти здатність скеровувати агента, відхиляти ідеї й повертати його до розумного підходу працювала краще, ніж дозволити йому диктувати хід проєкту.

Що бачать користувачі

З боку користувача все просто. Працюєте з чек-листом в Excel як завжди: додаєте завдання, розставляєте пріоритети, ставите терміни, позначаєте виконане. Коли настає новий тиждень, копія старої книги вирушає в папку Previous Weeks, виконані завдання переїжджають на вкладку Task History, а незакриті перетікають у книгу нового тижня.

Усе лишається локальним. Ні бази даних, ні сервера, ні підписки, нічого не працює у фоні. Рухомі частини — Excel, TypeScript, PowerShell, WSL і Планувальник завдань Windows. Чесно кажучи, забагато технологій для щотижневого чек-листа, але річ була не в розмірі. Сенс полягав у тому, щоб узяти рутинний обов’язок, застосувати вже зрозумілі інструменти й сприймати незнайомі шматки як можливість навчитися. PowerShell дав відправну точку, ШІ-агент відкрив новий шлях до незнайомих частин, і нудний маленький чек-лист перетворився на несподівано цікавий проєкт з автоматизації. Непогано для того, що почалося з думки, що це, мабуть, можна автоматизувати.