---
id: "lib-2026-11-01-automating-a-weekly-management-deck"
type: "library"
title: "Automating a weekly management deck"
title_original: "Как я автоматизировала еженедельную презентацию и научила AI-бота делать правки"
lang: "RU"
org: "Valeria Smirnova (Habr)"
source_type: "Practitioner post"
date: "2026-11-01"
week: "2026-W44"
url: "https://nosov.ai/library/lib-2026-11-01-automating-a-weekly-management-deck/"
original_url: "https://habr.com/ru/articles/1102162/"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "A practical Habr tutorial by BI developer Valeria Smirnova with architecture, code and the failures she hit; credible single-team practice with few measured outcomes and no costs."
summary_basis: "full-text"
original_minutes: "8"
tags: ["business transformation", "reporting automation", "mcp tools"]
---

# Automating a weekly management deck

Original title: Как я автоматизировала еженедельную презентацию и научила AI-бота делать правки

Tier B (Useful, limited): A practical Habr tutorial by BI developer Valeria Smirnova with architecture, code and the failures she hit; credible single-team practice with few measured outcomes and no costs.

Summary based on the full text.

## In short

A Habr tutorial (1 November 2026) by Valeria Smirnova, a BI developer whose profile lists Avito. A weekly department deck of several dozen metric slides, once built by hand from Redash screenshots and spreadsheets, is now generated by a cron job (Redash API, pandas, matplotlib for charts, python-pptx for editable text and KPI cards) and posted to Mattermost with a Nextcloud link. A bot in the post's thread takes edit requests in plain language through a small set of MCP tools implemented in the deck service. Edits are saved as JSON drafts and reach the code only after she reviews a weekly pull request.

## Key numbers

- 20+: managers who previously assembled the weekly department deck by hand, taking several hours a week
- 40+ queries, 10 minutes: Redash queries behind the deck and the time for a full automated build
- 1-3 minutes: time for the thread bot to return a corrected slide after a request
- 409 Conflict: error that hit on the first day when the bot committed each edit directly and two people asked at once

## What it reports

- One function per slide, so a single slide can be rebuilt (`--only`) and one failure leaves a placeholder with the error instead of breaking the deck.
- Each metric has its own "focus week" (the week before last, or four weeks back for slow data) so late-arriving data does not look like a drop.
- Manual slides (initiative status, partner agreements) are copied by title from the previous week's file so colleagues' edits carry over.
- Redash query links are written into each slide's notes.
- The first meeting with the automated deck produced about ten edit requests before the meeting, which led to the bot.
- Bot tools: list published slides with numbers and first lines, search and read code, rebuild on fresh data without code change, preview a fix on a code copy in a temp folder, list and commit weekly drafts, poll long jobs. The bot never overwrites the main deck.
- "Strange number" requests trigger a rebuild and a link to the source query; Redash parameter errors are escalated to the author.
- Failures: direct commits conflicted (409) when two people edited at once; concurrent cleanup deleted another request's temp folders; before the slide-listing tool, the agent sometimes edited the wrong slide.
- Built with Claude Code; she set the rules and checked each slide by asking for an image after every change.

## How they got it

A personal build write-up with simplified code. The only effort figures are "several hours a week" before and a 10-minute build after; no time study or costs.

## Limits

- Single team, self-reported; "several hours" is not quantified.
- No model, token or hosting costs.
- Simplified code; the author says it will need adapting.

## Why it matters for companies

Recurring management decks consume analyst time in most firms. The post shows a modest, auditable pattern: deterministic generation in code, an agent limited to narrow service-side tools, edits returned as separate files, and changes merged by a human once a week. The concurrency and slide-identification failures are the kind any team will hit when several people talk to one bot.

## Key passages in translation

> Поэтому напрямую агент ничего не трогает.

So the agent touches nothing directly.

> После каждого изменения просить картинку слайда и смотреть на неё, а не верить на слово.

After each change, ask for an image of the slide and look at it, rather than taking its word for it.

> Основную презентацию бот не перезаписывает никогда.

The bot never overwrites the main deck.

Original: https://habr.com/ru/articles/1102162/