ai-team-weekly-report

AI Team Weekly Report

Generates a factual, natural-language weekly report on a team's Jira activity, written in Russian in the voice of a Team Lead. The set of employees is a roster of emails stored in emails.json and managed through a helper script.

When to use

• The user wants a weekly team report / «недельный отчёт по команде».
• The user wants to add, remove, list, or clear the employees in the roster.

Roster management (save / add / remove)

The roster lives in emails.json (a JSON array of emails) in the skill root. Manage it only through scripts/manage_emails.py so validation and de-duplication are applied. Run from the skill directory:

python scripts/manage_emails.py list                             # show current roster
python scripts/manage_emails.py add [email protected] [email protected]   # add one or more
python scripts/manage_emails.py remove [email protected]             # remove one
python scripts/manage_emails.py clear                            # empty the roster

Every command prints the resulting roster as JSON ({"count": N, "emails": [...]}). Invalid emails are rejected with a non-zero exit code; surface the error to the user.

When the user only asks to manage emails, run the relevant command and confirm the result — do not generate a report.

Generating the report

Follow these steps in order.

0. Check required MCPs

Before doing anything else, verify that the Jira MCP is available by checking whether the tool jira_search (MCP: jira) is listed in your current tool set. If it is not available, stop immediately and show this error to the user:

❌ Ошибка: MCP-коннектор Jira недоступен.
Для работы скилла необходим подключённый Jira MCP.
Проверьте настройки подключения и попробуйте снова.

Do not attempt to generate a report without this MCP.

1. Load the roster

Run python scripts/manage_emails.py list (or read emails.json) to get the emails. If the roster is empty, tell the user and ask them to add emails first (show the add command). Do not invent employees.

2. Determine the report window

"Week" means from Monday of the current week (00:00) through today, inclusive — not a rolling 7 days. Compute the Monday date explicitly so it does not depend on Jira's locale startOfWeek() (which may begin on Sunday):

python3 -c "import datetime; t=datetime.date.today(); print((t - datetime.timedelta(days=t.weekday())).isoformat())"

This prints the current week's Monday as YYYY-MM-DD. Examples: today Tuesday → covers Mon–Tue; today Friday → covers Mon–Fri.

3. Fetch each employee's issues — in parallel

For each email, issue a jira_search call. Send all employee searches in a single message so they run in parallel. Use this JQL per employee (covers tasks, bugs, and every other issue type), filtering by the exact workflow statuses this team uses:

assignee = "EMAIL" AND (
  (resolutiondate >= "WEEK_START" AND status in ("Done", "To release", "to merge", "On merge", "Cancelled", "To review", "to test", "Feature test", "Ready for Testing"))
  OR
  (updated >= "WEEK_START" AND status in ("Pause", "Accepted", "In Progress"))
) ORDER BY status DESC

Replace WEEK_START with the computed Monday date (e.g. "2026-06-01"). Completed tasks are filtered by resolutiondate (Дата решения); in-progress tasks have no resolutiondate so they are filtered by updated instead. Set fields to: summary,status,assignee,issuetype,resolutiondate,updated,description. Raise limit (up to 50) if a person has many issues; paginate with start_at if total exceeds what was returned.

Notes on the response shape (Jira Server/DC at jira.demo.io):

• issues[].key, issues[].summary, issues[].description
• issues[].status.name is the only grouping key — match it against the status names below (case-insensitive).
• Ignore issues[].status.category completely. It does not match this team's grouping. For example «Ready for Testing» has category «В работе», but it is a Completed status here. Never decide a task's group from status.category — always use status.name.
• issues[].issue_type.name (e.g. «Задача», «Ошибка»/bug, «Dev Task»).
• issues[].assignee.display_name / .email identify the person.

Aggregate all issues across all employees into one consolidated list, tagging each with its group (Completed vs In Progress) per the status mapping in step 5. The roster only defines whose work to fetch — the report itself is about the team as a whole, so do not track or report who did what.

4. Enrich sparse items only if needed

If a summary is too terse to understand at all, call jira_get_issue for that issue key (fields: "summary,description,issuetype,status") to grasp what the task is about. Do this only for the issues that need it — not for every issue. Use the description only to extract the essence of the task; never copy long descriptions into the report.

5. Write the report (Russian, Team-Lead voice)

Compose the report in Russian using only factual data from Jira. Rules:

Structure

The report has exactly two sections in this order. Each section opens with its fixed phrase — that phrase IS the section divider. Do not add any separate header, title, or label before or after it (no «Завершённые задачи», no «Задачи в работе», no bold heading of any kind):

1. Completed — first line of the entire report, verbatim: «На этой неделе команда выполнила следующие задачи:» Statuses that belong here: Done, To release, to merge, On merge, Cancelled, To review, to test, Feature test, Ready for Testing.

2. In Progress — first line of the second section, verbatim: «В активной работе находятся следующие задачи:» Statuses that belong here: Pause, Accepted, In Progress.

Match status names case-insensitively. Group strictly by status.name — never by status.category. In particular, «Ready for Testing», «to test», «To review», «to merge», «On merge», «Feature test» go to Completed even if their Jira category says «В работе».

Tone and phrasing

• Write in flowing prose as a Team Lead summarizing the team's week.
• Group related tasks into a few thematic paragraphs (e.g. платежи и переводы, миграция интерфейса, безопасность) — not one sentence per task.
• Describe Completed tasks in past tense («реализована», «исправлено», «завершена»). Describe In Progress tasks in present continuous («ведётся», «исправляется», «дорабатывается»).
• For Cancelled tasks: do not write «задача отменена» or anything about cancellation. Instead describe what was done — investigated, checked, reviewed — and that no action was needed, e.g. «Разобрали обращение по X, проверили логи — проблем не выявлено», «Проверили предполагаемую ошибку Y, воспроизвести не удалось». Write in the same past-tense active style as other completed tasks.
• Write about the team as a whole — do not name individuals or attribute tasks to specific people.
• State only the essence of each task — do not include long descriptions, full ticket text, or issue keys.
• No technical implementation details. Do not name specific libraries, frameworks, APIs, class names, flags, or language constructs (e.g. no Room, Compose BOM, Timber, SharedPreferences, CoroutineScope, !!-operators, specific annotation names). Describe what was done and why, not how at the code level. For example: instead of «заменили CoroutineScope на viewModelScope» write «доработали асинхронные вызовы»; instead of «Fragment-ktx, Room, Compose BOM» write «обновили библиотеки до актуальных версий».
• No product or app names. Do not name specific apps, services, or internal project names (e.g. no «Мой О!», no «Android-приложение» — just «приложение»). Exception: names that appear in the task summary itself and are essential to understand the task (e.g. a third-party service being replaced) may be kept if they add clarity.

Forbidden patterns — apply zero tolerance

• No summary lead-ins. Never open a paragraph with a sentence that describes the theme before listing the work, e.g.: «Значительная часть работы была сосредоточена на…», «Основное внимание уделялось…», «В рамках спринта продолжилась работа по…». Start each paragraph directly with the concrete action («Реализована интеграция…», «Исправлено отображение…»).
• No filler connectives. Delete words like «Также», «Активно», «Кроме того», «В частности», «При этом» when they appear at the start of a sentence or as a sentence opener. Begin the sentence directly with the verb or subject.
• No filler adverbs. Remove «Активно», «Успешно», «Эффективно» and similar intensifiers.
• No editorial conclusions. Do not add praise, assessments, or forward-looking statements at the end of sections or the report.
• No bullet lists, numbered lists, or images.
• No personal opinions or speculation — describe only what the Jira data shows.

Edge cases

• If a section has no issues: state that plainly, e.g. «На этой неделе завершённых задач не зафиксировано.»
• By default present the finished report in the chat. Only save it to a file if the user asks.

Files

• emails.json — the roster (JSON array of emails).
• scripts/manage_emails.py — list/add/remove/clear the roster.