У новому гайді на каналі Futurepedia автор показує, як з нуля будувати реальні робочі інструменти у Claude Code без жодного рядка коду. Один із найцікавіших кейсів — невеликий, але показовий таск‑менеджер: канбан‑додаток, який сам витягає action items із нотаток зустрічей через підключений сервіс Granola і перетворює їх на дошку задач.
Цей приклад добре демонструє, як модель може не просто генерувати текст чи код, а фактично «склеювати» між собою вже наявні робочі інструменти в нові інтерфейси та процеси.
Від демонстраційних ігор до реального офісного інструмента
Після показової збірки навчальної гри для друку автор переходить до більш прикладного сценарію: чогось «ближчого до того, що ви реально будували б для роботи» — продуктивність, задачі, мітинги, інтеграції з уже наявними застосунками.
Ідея проста: замість чергової абстрактної демо‑апки створити утиліту, яка вписується у звичний робочий день — автоматизувати шлях від «у нас купа нотаток мітингів» до «у нас структурована дошка задач, розподілена по стовпчиках та відповідальних». Використати для цього пропонується Claude Code та вже під’єднані MCP‑конектори до сторонніх сервісів.
У секції налаштувань конекторів видно, що серед підключених інструментів є Granola — сервіс, який автор «використовує для нотаток зустрічей». Саме він стає основним джерелом даних для майбутнього таск‑менеджера.
Архітектура: канбан‑дошка плюс Granola як MCP‑джерело
Формулювання задачі до Claude Code звучить максимально прикладно: побудувати канбан‑додаток, який витягає action items з нотаток зустрічей і відображає їх у вигляді карток, що рухаються між колонками «to do», «in progress» та «done».
У промпті чітко фіксуються два ключові моменти.
По‑перше, логіка інтерфейсу: саме канбан‑стиль із трьома основними статусами, між якими користувач може вручну перетягувати задачі. Це не просто список тудушок, а візуальне відображення стану роботи.
По‑друге, джерело даних: необхідно «використовувати підключений Granola MCP», щоб «підтягнути нотатки мітингів і витягти з них action items». Тобто Claude має не вигадувати задачі, а працювати з реальними записами з інструмента, яким користувач уже й так фіксує хід зустрічей.
Далі процес виглядає так само, як і в попередніх прикладах у відео: створюється нова папка для проєкту, вмикається плановий режим, модель задає кілька уточнювальних запитань, а потім пропонує план, який користувач затверджує. Після схвалення Claude Code розгортає проєкт, пишучи та організовуючи код у цій папці.
Хоча конкретні технічні деталі реалізації в кадрі не розбираються, акцент робиться на тому, що для користувача це залишається діалогом природною мовою, без необхідності читати чи писати код.
Як Claude перетворює нотатки на задачі
Результат збірки виглядає як короткий, але завершений робочий інструмент. Claude Code підтягує дані з Granola — при цьому йдеться про «найбільш недавню зустріч». На основі цих нотаток модель:
- ідентифікує всі action items;
- визначає, для кого кожен із них призначений.
У підсумку користувач бачить канбан‑дошку, де кожна картка відповідає окремій дієвій задачі, витягнутій зі «сирих» нотаток. На картках уже зазначено, кому належить завдання. Далі ці картки можна вручну рухати між стовпчиками «to do», «in progress» та «done».
Саме це виділяється як ключова цінність: збережено звичний спосіб роботи (вести нотатки у Granola), але додано новий інтерфейс, який перетворює вільну текстову інформацію на структуруваний потік задач.
Автор підкреслює, що цей конкретний білд «простий, але досить корисний» і, що важливо, «відразу спрацював з першої спроби» — без додаткових доопрацювань чи довгих циклів налагодження.
Інтеграції як мультиплікатор продуктивності
Далі прозвучує, по суті, головний меседж всієї демонстрації: як тільки користувач «починає підключати інструменти, які вже й так використовує, і вбудовувати їх у нові інтерфейси та системи», дуже швидко відкриваються нові можливості. Зокрема, з’являється шанс створювати «справді економні за часом інструменти для себе».
Канбан‑таск‑менеджер на базі нотаток мітингів тут — лише один приклад. Але він добре показує загальну модель:
- є наявний сервіс, де вже накопичуються робочі дані (у цьому випадку — Granola з транскриптами й конспектами зустрічей);
- є Claude Code, який через MCP отримує до нього доступ;
- є невеликий новий застосунок‑надбудова, що перекроює спосіб взаємодії з цими даними, роблячи їх більш придатними до дій.
У межах цього кейсу Claude автоматично робить ще й первинну інтерпретацію контенту зустрічі: розпізнає, де саме у тексті йдеться про завдання, а не просто про обговорення, і відносить їх до конкретних людей. Це позбавляє команди від ручного «вичісування» пунктів дій після кожного колу.
Цікаво, що після збірки автор знову запускає команду /init — Claude створює файл claude.md для цього проєкту. Це фіксує поточний стан системи як довгостроковий контекст: якщо чат‑історія з часом розростеться чи загубиться, можна буде почати нову сесію й далі розвивати той самий таск‑менеджер, не втрачаючи розуміння структури.
Втім, саму логіку «довгострокової пам’яті» проєктів через claude.md у цьому фрагменті відео детально не розбирають — тут вона радше виступає як технічний супровід до основної ідеї: зробити з інтеграцій щось, що реально економить час.
Висновки: невеликі збірки, великий вплив на рутину
Кейс із канбан‑дошкою для action items з Granola демонструє важливу зміну парадигми: AI‑інструменти на кшталт Claude Code корисні не лише як середовище для «серйозних» проєктів, а й для дрібних, цілеспрямованих утиліт, що врізаються в уже існуючі робочі потоки.
Тут немає складної бізнес‑логіки, немає довгих налаштувань — лише:
- один підключений MCP‑конектор до сервісу нотаток;
- один промпт із чітко описаним бажаним інтерфейсом;
- одна сесія, після якої вже є працюючий внутрішній інструмент.
На прикладі Granola видно, що ключем до користі стає не сам факт використання моделі, а її вміння підхоплювати дані з тих систем, де вони природно виникають у процесі роботи, і повертати їх у формі, яка спонукає до дії.
У такій логіці подібні збірки можуть стати повсякденним інструментом для команд: замість чекати готових продуктів від сторонніх розробників, офісні працівники отримують можливість самостійно будувати власні мікро‑сервіси, адаптовані під їхні реальні процеси — і робити це, не заходячи в код взагалі.