task-summary

name

task-summary

description

This skill should be used when the user asks to "составь описание задачи", "саммари работы", "опиши проделанную работу", "опиши, что сделано по задаче", "собери описание для Jira", "собери описание для MR", "описание для MR", "task summary", "summarize work". Generates a structured summary of completed work in the current branch by analyzing commits matching the TAXDEV-XXXX prefix: business changes + test coverage table (test name → what it checks).

task-summary — completed work description

Generates a structured task description from the commits of the current branch. Three blocks: «Что изменилось» (QA-facing black-box deltas — NEW added functionality / CHANGED behavior with input→before/after / REMOVED disabled features; internal refactors without observable effect are not bullets), test cases in two layers — Бизнес-сценарий (QA-facing: real user state, action via UI/API, observable outcome) and Техническая привязка (one line for the auto-test author: test path + entrypoint), and manual-check recommendations (heuristic-based — what is not covered by automated tests).

The two-layer format solves the core problem of mirroring unit tests for QA: a manual tester cannot call CustomerService._private_method(set()), cannot read the contents of GHOST_DELAY_AVAILABLE_TARIFFS from the diff, and does not know that Tariff.AUSN_QUARTER_2026 is named «АУСН Квартал 2026» on the tariff card. The skill translates these symbols before printing.

When to use

The user is preparing a description for Jira or MR after finishing work on a task. Team standard: one branch = one Jira task, commit subjects start with TAXDEV-XXXX: <what was done>. Works for both work-in-progress branches and tasks already merged into master.

Trigger phrases (kept in Russian — team workflow)

• «составь описание задачи»
• «саммари работы»
• «опиши проделанную работу»
• «опиши, что сделано по задаче»
• «собери описание для Jira»
• «собери описание для MR»

Algorithm

1. Determine the task ID

The task ID must come from the user's prompt or skill ARGUMENTS. The current branch name is not consulted — explicit always beats implicit.

1. Scan the user message and skill ARGUMENTS for TAXDEV-\d+. If found — use it.
2. If not found — ask the user via AskUserQuestion («Укажи ID задачи (TAXDEV-XXXX)»). Do not proceed until the user provides one.

Case A vs Case B in step 2 is decided by the data, not by the branch:

• try master..HEAD first (Case A — task in progress);
• if it returns 0 commits — fall back to git log --all --grep (Case B — task already merged).

2. Collect the task's commits

Two cases — work-in-progress branch vs. task already merged into master.

Case A: work-in-progress branch (default)

git log master..HEAD --format="%H%x09%s" --grep="^TAXDEV-XXXX:"

master..HEAD — only commits on the branch. --grep filters out merge commits and unrelated ones.

Case B: task is already merged into master

If Case A returns 0 commits, search master's history (not --all):

git log master --no-merges --format="%H%x09%s" --grep="^TAXDEV-XXXX:" --reverse

• master (not --all) — only commits reachable from master. Tasks that went through beta and were cherry-picked back to master would otherwise appear as duplicates with different hashes.
• --no-merges — exclude merge commits whose body matches ^TAXDEV-XXXX: via grep.

Save the first and last commit hashes — they will define the diff range in step 3.

Fail-fast: if both cases return 0 commits — report to the user and stop. Do not fabricate a description.

3. Get the diff

Case A: work-in-progress branch

git diff master...HEAD --stat        # per-file summary
git diff master...HEAD               # full diff
git diff master...HEAD --name-only   # list of changed files

The triple-dot (...) means changes introduced by the branch from its merge base, ignoring new commits on master.

Case B: task is already merged

A naive git diff <first>^..<last> would include unrelated files from master that landed between the branch's base and its merge (rebase noise / stale-base noise). Restrict the diff to files the task commits actually touched:

# Files touched ONLY by the task's master-reachable commits
FILES=$(git log master --no-merges --grep="^TAXDEV-XXXX:" --name-only --format="" | sort -u | sed '/^$/d')

# Diff between pre-first-commit and last-commit, restricted to those files
git diff <FIRST>^..<LAST> --stat -- $FILES
git diff <FIRST>^..<LAST>        -- $FILES
git diff <FIRST>^..<LAST> --name-only -- $FILES

Substitute <FIRST> and <LAST> with the hashes from step 2 Case B. This eliminates rebase noise and shows only what TAXDEV-XXXX changed.

4. Split files

• Tests: paths containing /tests/, names matching test_*.py, *_test.py, conftest.py.
• Production: everything else.

5. «Что изменилось» — black-box delta для тестировщика (3–7 bullets)

The block answers a single QA-facing question: как изменился внешний контракт системы — UI, API, бизнес-процессы, тексты — после этой задачи? Internal refactors without observable effect on UI/API/process do not belong here.

Each bullet must fit one of three patterns. Bullets that do not fit are dropped or rewritten.

Pattern A — NEW (новая возможность)

Добавлено: {действие пользователя / endpoint / экран} — теперь {наблюдаемый результат}.

Use when new functionality appears: new endpoint, new UI screen, new branch in an existing flow, new entity in a response.

Pattern B — CHANGED (black-box дельта поведения)

На {ручке / экране / при действии} при {условии input} результат стал {новое поведение}; раньше — {старое поведение}.

Use when behavior of an existing endpoint, UI element, or process changes. Must name both the trigger (input/condition) and the delta (before → after). Without both — it is not a black-box description.

Pattern C — REMOVED (отключено / удалено)

Отключено: {что больше не доступно / не показывается / не вызывается}. Раньше срабатывало при {условии}.

Use when a feature, endpoint, branch, or behavior is removed.

Heuristic-filter — что НЕ попадает в блок

• bullets with words «рефакторинг», «вынесено», «переписан», «оптимизирован», «декомпозиция», «упрощено» — if they do not name a ручка/экран/действие пользователя/output;
• function, class, constant, fixture names without business translation (translate per step 6a);
• bullets like «изменили метод X», «добавили вспомогательный класс Y», «обновили зависимость Z».

Internal-only fallback

If the production diff contains only internal refactors with no observable effect on UI/API/process — replace the whole block with one honest line:

Только внутренний рефакторинг без изменения внешнего поведения; покрытие — {список тестов}.

Do not pad with «вынесли таблицу», «упростили match», «переименовали поля» bullets.

Source priority

1. commit messages — reuse wording if already at the business level;
2. production diff — derive the input→output delta;
3. test diff — confirms the observable behavior (assertions match Pattern B's «новое поведение»).

Rules

• active voice;
• one bullet = one change;
• no function/class/constant/fixture names — translate per step 6a;
• order: NEW first, then CHANGED, then REMOVED.

6. Extract test cases — two-layer format

See references/test-extraction.md — rules for parsing def test_*, the «Перевод в бизнес-язык» section, and the Given-When-Then extraction rules.

6a. Translate symbols to business language

Before composing test cases, scan the diff for the following symbols and resolve each into a business-level fact. Read the codebase when needed — do not paste raw symbols into the output.

Symbol type	Translation strategy
Fixture (customer_ip, tax_type_ausn_income)	Read the fixture definition. Describe the entity it produces in plain Russian («ИП на УСН-доходы»).
Private method (CustomerService._cancel_not_available_delayed)	Run grep -rn "_method_name" stepler/ to find the public caller. Use the caller name in business terms («смена СНО»). The private method goes into «Техническая привязка» only.
Internal constant / frozenset / set (GHOST_DELAY_AVAILABLE_TARIFFS)	Read the constant definition. List its members in human terms or describe the group («платные тарифы АУСН»).
Code identifier of a domain entity (Tariff.AUSN_QUARTER_2026, Tariff.FREE_AUSN)	Search the codebase (presenters/, marketing strings, MarketingFeatureData, _TARIFF_NAMES dicts) for the витринное название. If not found — keep the code, add tag (витринное название уточнить у PM).
Test mechanism (freeze_time(...), mocker.patch(...), MockedBank)	Do not include in «Бизнес-сценарий». If a frozen date affects period calculation — convert to a single line in «Дано» («дата в марте 2026», «биллинговый период — март 2026»). Mocks go into manual-check recommendations (step 7) if they hide an external integration.

Fail-fast: if a symbol cannot be resolved (private method has no public caller, constant references unknown values, tariff code has no витринное название) — surface the gap in «Техническая привязка», do not fabricate.

6b. Compose the two-layer test case

For each test, produce:

Бизнес-сценарий — what QA can reproduce manually or via API:

• Дано (preconditions): real-world client state, active connections, dates — using translations from 6a;
• Действие (action): the user action through UI/API that exercises the code under test — usually the public method found in 6a;
• Ожидание (outcome): observable result the QA can check in the client card, admin panel, or API response.

Техническая привязка (one line) — for the auto-test author:

• test file path and function name;
• the actual method invoked in the test body (may be private);
• key fixtures/mocks (one-liner: «моки ESB, MockedBank»).

Tag tests as (обновлён) if modified, (параметризован, N кейсов) if parametrized.

Fail-fast: if no new/modified tests exist — write «Тестов в этой задаче не добавлялось», do not fabricate cases. If the test body has no extractable Arrange/Act/Assert — fall back to a one-line «what it checks» description from the docstring or name (see references/test-extraction.md section 2.4).

7. Generate manual-check recommendations

See references/test-extraction.md, section «Heuristics for manual checks». From the diff, build a list of items the unit tests do not cover and that QA should verify manually. Heuristics:

Trigger in the diff	Recommendation
Changes in presenters/, new icons, UI strings	Visually verify rendering in the UI (card/list)
Mocks of external services (mocker.patch, fixture mock_*)	Verify integration with the real service in staging
New customer segment / new Splinter experiment	Verify A/B-group intersection and segment switching in the real environment
New marketing strings/descriptions	Check texts for typos and consistency with design mockups
New API endpoint	Test failure paths from the frontend/Postman (auth, validation)

Label the section explicitly: «Рекомендации, не покрытые автотестами — проверьте при необходимости».

Fail-fast: if no trigger fires — omit the section entirely.

8. Ask for the output format

AskUserQuestion:

• Markdown — for MR description (sections, table);
• Plain text — for Jira (no markdown, tests as blocks).

9. Generate the description

Templates: references/output-formats.md. The structure is the same for both formats:

1. Header: TASK-ID: <subject from the first commit>
2. Section «Что изменилось» — black-box deltas per step 5 patterns (NEW / CHANGED / REMOVED), or the internal-only fallback line
3. Section «Покрытие тестами» — per test: «Бизнес-сценарий» (Дано/Действие/Ожидание) + «Техническая привязка» (one line)
4. Section «Требует ручной проверки» — recommendations from step 7 (if any)
5. Footer: file statistics (N production, M tests)

10. Output

Print the final description to the chat. Do not write a file. The user pastes it into Jira/MR.

Fail-fast rules

• Do not fabricate business changes if the diff is empty.
• Do not emit «Что изменилось» bullets that describe internal refactors without observable effect on UI/API/process. Each bullet must fit Pattern A (NEW) / B (CHANGED, with input→before/after) / C (REMOVED). If the diff has only internal changes — replace the block with one line «Только внутренний рефакторинг без изменения внешнего поведения; покрытие — {tests}».
• Do not put function/class/constant/fixture names into «Что изменилось» — translate per step 6a, same discipline as «Бизнес-сценарий».
• Do not fabricate test cases if there are no new tests.
• Do not fabricate manual-check recommendations if no heuristic fires.
• Do not guess Given-When-Then when the test body has no explicit sections — fall back to a one-liner.
• Do not guess the TAXDEV-ID — require it in the prompt or ask. Never derive it from the current branch.
• Do not silently use the wrong base branch — if master does not exist, stop and ask (main? develop?).
• Do not include rebase noise in Case B (merged task) — always restrict the diff to files actually touched by the task's commits (see step 3).
• Do not paste private methods, internal constants, or test mechanisms (freeze_time, mocker.patch) into «Бизнес-сценарий» — translate first (step 6a). If translation fails, surface the gap explicitly, do not invent.
• Do not invent витринные названия for tariffs/products if they are not in the codebase — mark (уточнить у PM).

Reference

• references/test-extraction.md — parsing tests from the diff
• references/output-formats.md — Markdown and Plain text templates