weekly-report

name	weekly-report
description	Собрать еженедельный отчёт по работе в файле `Log/Reports/YYYY-MM-DD.md` (один документ на неделю). Используй, когда пользователь пишет /weekly-report, "собери недельный отчёт", "что я сделал за неделю", "создай отчёт за неделю", или просит оформить недельный статус по дневным логам и tasks.md.

weekly-report

Готовишь отчёт за неделю по дневным логам и tasks.md. Пиши по-русски, коротко и фактами, без маркетингового тона и без придумывания результатов.

Парный скилл к weekly-review: этот смотрит назад (что сделано), тот — вперёд (что делать на неделе).

Пути vault

Пути и день недели, которые в разных vault разные, лежат в .claude/vault-config.md (ключи weekly_report, report_day). Прочитай его до того, как определять дату, и дальше используй значения оттуда. Если vault-config.md нет, но есть .claude/vault-paths.md — читай его: это прежнее имя того же файла. Если нет ни того ни другого — fallback: отчёты в Log/Reports/*.md, report_day — воскресенье; скажи об этом в финале.

Результат

Один документ на неделю по ключу weekly_report:

Log/Reports/YYYY-MM-DD.md

YYYY-MM-DD — дата дня report_day отчётной недели (конец периода). Если папки нет — создай её.

Если файл уже есть, обновляй только блок между маркерами:

<!-- weekly-report:start -->
...
<!-- weekly-report:end -->

Если маркеров нет, добавь их и помести весь сгенерированный отчёт внутрь.

Дата и период

• Период отчёта — 7 дней, заканчивающихся днём report_day включительно (для воскресенья это пн–вс, для среды — чт–ср). Имя файла — дата этого report_day.
• Явная дата от пользователя перекрывает всё: бери период, в который она попадает; имя файла — по report_day этого периода.
• Без даты бери текущий период — тот, что заканчивается ближайшим report_day (сегодня, если сегодня и есть report_day).
• Исключение: если сегодня — следующий день после report_day (новый период ещё пустой), бери период, закончившийся вчера.
• Если отчёта за предыдущий период нет вообще (файл не создавался), а текущий период идёт ≤2 дней — собери сначала пропущенный предыдущий и скажи об этом в финале.
• Примеры: при report_day = воскресенье Log/Reports/2026-06-07.md покрывает 2026-06-01–2026-06-07; при report_day = среда Log/Reports/2026-04-29.md покрывает 2026-04-23–2026-04-29.

Источники

Собери факты из локальных файлов, в таком порядке:

1. Дневные логи Log/YYYY/MM/YYYY-MM-DD.md за весь отчётный период. Если период пересекает границу месяца — смотри обе папки месяцев.
2. tasks.md в корне vault: закрытые задачи с датой периода (✅ YYYY-MM-DD) и незакрытые задачи, явно относящиеся к текущей неделе. Файл разбит на секции # Week: (текущая неделя) и # Week+ (неделя+); фокус отчёта — секция # Week:, из # Week+ бери только то, что реально двигалось за период.
3. Список направлений — из frontmatter tasks.md (ключ projects:). По ним строится первый разрез отчёта (см. «Группировка»).
4. Прошлые отчёты по ключу weekly_report — только как стиль и контекст по непрерывным темам, не как место записи.

Если дневного лога за дату нет — просто пропусти дату. Если фактов мало, не растягивай отчёт водой; лучше сделать короткий честный отчёт.

Группировка

Отчёт строится в два разреза. Сначала — направления, потом — хобби / дела.

1. Направления

Бери список из frontmatter tasks.md (projects:). Каждое направление — отдельный пункт верхнего уровня в ## Сделал. Относи факт к направлению по смыслу: ключевые слова в названии направления, wikilinks, упоминания в дневных логах. Направление без фактов за неделю не выводи.

Ключа projects: во frontmatter tasks.md нет — направлений не строим, группируй факты по повторяющимся темам недели, названия выводи из самих фактов, пустых рубрик не создавай.

Факт, который не лёг ни в одно направление, отправляй в «Прочее» (в конец) или в «Хобби / дела», если разрез хобби в этом vault есть.

2. Хобби / дела

Всё, что не попало в направления, раздели на две группы:

• Хобби — для удовольствия и развития: чтение, музыка, фильмы, спорт, учёба «для себя», эксперименты.
• Дела — быт и обязательное: дом, документы, финансы, здоровье, разовые поручения.

Внутри каждой группы можно сделать подпункты по темам, если фактов много. Группу без фактов не выводи — в рабочем vault этот разрез обычно просто не появится.

Мелкие однотипные пункты объединяй в один. Важные ссылки (трекер, документы, внешние URL) сохраняй рядом с соответствующим фактом.

Формат отчёта

Используй такой каркас:

# Еженедельный отчёт YYYY-MM-DD

Период: YYYY-MM-DD — YYYY-MM-DD

<!-- weekly-report:start -->
## Сделал

- <Направление>
	- <суть сделанного>
		- <подробности>
	- <суть сделанного>

- Хобби
	- <суть сделанного>
- Дела
	- <суть сделанного>

## Вопросы / риски
- <вопрос или риск>

## Что дальше
- <следующий шаг>

## Метрики / наблюдения
- <только если есть фактические цифры или наблюдения>

## Закрытые задачи (N за неделю; всего в tasks.md было закрыто DONE, открыто OPEN)
- <формулировка задачи> ✅ YYYY-MM-DD
<!-- weekly-report:end -->

Разделы Вопросы / риски и Что дальше выводи только если есть реальные пункты. Внутри Сделал выводи только направления и группы, где есть факты; пустые не выводи.

Рубрику ## Закрытые задачи включай в отчёт по умолчанию (если за период есть хоть одна закрытая задача). Это запись в отчёт, а не удаление; чистку самого tasks.md делай только после подтверждения (см. ниже).

Форма пунктов Сделал — три уровня

Пункт Сделал — это не одна длинная строка «суть + подробности», а три уровня:

- <Направление>
	- <суть сделанного — одна короткая фраза, глагол + объект>
		- <подробности: даты, цифры, ссылки, wikilinks, нюансы>

Отступы — табами: направление 0, суть 1, подробности 2.

Правила:

• Второй уровень — только суть. Одна фраза, которая читается как строка отчёта сама по себе. Без цифр, URL и «в скобках» — всё это уходит вниз. Дата в скобках допустима, если она часть сути: Разобрал правки Дениса по редизайну (21.07).
• Третий уровень — подробности. Цифры, URL, [[wikilinks]], номера PR, перечисления, наблюдения по ходу. Можно несколькими подпунктами, если детали разнородные.
• Подпункт читается самостоятельно, а не как хвост фразы из родителя.
  • Плохо: Завёл 3 клиентов в backoffice → (группа Continental, инвайты отправлены): Анна Пепс (96)…
  • Хорошо: Завёл 3 клиентов в backoffice → Группа Continental, инвайты со ссылкой отправлены: Анна Пепс (user_id 96), Лев Алексеев (97)…
• Нет подробностей — нет третьего уровня. Короткий факт остаётся одной строкой: Выгрузил из CRM контакты с датами рождения и передал коллеге.

Правило действует только для ## Сделал. Вопросы / риски, Что дальше, Метрики / наблюдения и Закрытые задачи остаются плоскими списками.

Метрики

В Метрики / наблюдения всегда включай баланс потока за период: +N добавлено (➕) / M закрыто (✅) по верхнеуровневым задачам tasks.md. Если добавлено заметно больше, чем закрыто, — отметь одной строкой как риск перегруза # Week: (это же увидит weekly-review).

Остальное в этот раздел попадает только по данным из источников: выдуманных KPI быть не должно. Если фактических цифр нет — оставь только баланс потока.

Стиль

• Пиши от первого лица: Сделал, Добавил, Проверил, Нашёл, Поправил, Настроил.
• Не используй оценочные фразы без фактов: сильно улучшил, важный прогресс, успешно завершил, если в источниках нет конкретики.
• Не раскрывай лишние чувствительные детали из приватных файлов. Ссылки и названия задач оставляй, если они уже были в рабочих логах.
• Если пункт выглядит как задача на будущее, перенеси его в Что дальше, а не в Сделал.
• Если пункт выглядит как блокер или открытый вопрос, перенеси его в Вопросы / риски.

Сводка по закрытым задачам и чистка tasks.md

Шаг 1 (сводка в отчёт) делай по умолчанию, без отдельного вопроса. Шаги 2 и 3 — только после явного подтверждения.

1. Дописать в отчёт сводку по закрытым задачам из tasks.md — компактный список выполненных пунктов (- [x] ... ✅ YYYY-MM-DD). В заголовке рубрики обязательно указать количество закрытых за неделю; рядом в скобках — общие счётчики (закрыто / открыто). Формат — отдельная рубрика в конце блока отчёта:

   ## Закрытые задачи (N за неделю; всего в tasks.md закрыто DONE, открыто OPEN)
   - <формулировка задачи> ✅ YYYY-MM-DD
   

   Счётчики DONE/OPEN считай напрямую по tasks.md — верхнеуровневые - [x] против всего остального (открыта любая строка, кроме - [x]; правило — в obsidian-vault, «Закрытость чекбокса»). Это не требует установленных инструментов и работает на чистой macOS и Windows. Если в vault ведётся files/tasks.json (его генерирует gen-tasks-json.cjs), готовые счётчики done/open лежат и там — прочитай файл как обычный JSON. Продвинутый вариант, если в системе есть jq: jq '{done, open}' files/tasks.json. N — число задач, реально попавших в список за период (обычно меньше done, т.к. в done входят и «хвосты»).

   Брать формулировку как есть, длинные подпункты-детали не тащить. Сначала задачи периода, ниже одной строкой отметить «хвосты» прошлых недель, если они есть.

   Пример:

   ## Закрытые задачи (6 за неделю; всего в tasks.md закрыто 28, открыто 91)
   
   За неделю (01.06–07.06):
   - Проверить, как встроился новый язык перевода ✅ 2026-06-02
   - Сделать бота для поиска по базе клиентов ✅ 2026-06-03
   - Выписать задачи из таблицы ✅ 2026-06-05
   
   Хвосты прошлых недель (закрыты раньше, ещё висят в `tasks.md`): доступ к справочнику, цена на тариф, почтовый алиас и др.
   

   Строку про «хвосты» добавляй, только если в tasks.md есть закрытые задачи с датой ✅ раньше периода. Если их нет — оставляй только список за неделю.

2. Удалить закрытые задачи из tasks.md — чтобы список держал только открытое. Удалять весь блок задачи вместе с её вложенными строками-деталями.

Подтверждение шагов 2 и 3 запрашивай одним вызовом AskUserQuestion (не свободным текстом): отдельный вопрос про удаление закрытых задач из tasks.md (варианты: удалить / оставить) и отдельный вопрос про git commit изменений vault (варианты: закоммитить / не коммитить). Так пользователь отвечает по обоим действиям сразу, а не двумя репликами.

Правила:

• Сводку в отчёт (шаг 1) дописывай сразу. Удаление из tasks.md (шаг 2) и коммит (шаг 3) — только после явного подтверждения (через AskUserQuestion).
• Считать закрытыми задачи верхнего уровня со статусом - [x]. Частично сделанные (открытая задача — любой чекбокс, кроме - [x] — с закрытыми подпунктами; правило — в obsidian-vault, «Закрытость чекбокса») не трогать — задача ещё в работе; такие просто упомянуть в статусе, не удалять.
• В сводку и в удаление по умолчанию включать все закрытые - [x], а не только за период (накопившиеся «хвосты» прошлых недель — это и есть то, что чистим). Если пользователь хочет только период — ограничить датами.
• Перед удалением показать количество: сколько задач уйдёт, сколько останется, сколько частичных пропущено.
• Закрытые подпункты внутри остающейся открытой задачи не вырезать (они показывают прогресс).
• Заголовки секций # Week: / # Week+ и строку-легенду (ключ tasks_legend в .claude/vault-config.md; ключа нет — просто не трогай строку, начинающуюся с > Активные задачи) не удалять при чистке, даже если секция осталась без завершённых задач.

После отчёта — обязательно weekly-review

Отчёт без ревью не закончен: он смотрит назад, а неделю планирует weekly-review. Поэтому последним шагом всегда запускай weekly-review в той же сессии — не спрашивая разрешения и не откладывая на отдельную реплику пользователя.

• Запуск идёт после записи отчёта и после обработки ответов на AskUserQuestion про чистку tasks.md и коммит (иначе ревью будет планировать по неубранному списку).
• Отчёт передаёт в ревью два входа: свежий файл отчёта (weekly_report) и его рубрику ## Что дальше — задачи из неё заводит именно ревью (шаг 7), в weekly-report их создавать не нужно.
• Если чистку tasks.md пользователь отклонил — ревью всё равно запускай, но предупреди его, что в # Week: остались закрытые задачи.
• Не запускай повторно, если weekly-review уже прогонялся в этой сессии после текущего отчёта.
• Единственная причина не запускать — пользователь явно сказал «только отчёт» / «без ревью». Тогда скажи в финале, что ревью пропущено по его просьбе.

Связанные скиллы

• weekly-review — планирование следующей недели, обязательный следующий шаг после отчёта (см. раздел выше). Пункты ## Что дальше в задачи разбирает именно он (шаг 7), здесь их заводить не нужно.
• monthly-review — месячный обзор (итоги месяца по недельным отчётам, projects.md, цели года).
• close-task — закрытие задач и синхронизация галочек с projects.md.
• worklog — дневные логи, из которых собирается этот отчёт.

Проверка перед ответом

Перед завершением проверь:

1. .claude/vault-config.md прочитан; файл создан или обновлён по ключу weekly_report, имя — дата report_day, один документ на неделю.
2. В отчёте есть дата и период (7 дней, заканчивающихся report_day).
3. Маркеры weekly-report:start и weekly-report:end присутствуют.
4. Пункты ## Сделал — три уровня: направление / суть / подробности; ссылки и цифры не остались на уровне сути; у коротких фактов нет пустого третьего уровня.
5. Пустых рубрик и пустых направлений нет.
6. Ссылки из исходных фактов не потерялись.
7. В Метрики / наблюдения есть баланс потока +N ➕ / M ✅.
8. Отчёт читается как краткая сводка, а не как полный дамп дневников.
9. Закрытые задачи из tasks.md без подтверждения не удалены; удаление и коммит предложены одним AskUserQuestion.
10. Если в vault есть files/tasks.json — счётчики пересобраны после чистки tasks.md (правка через shell мимо Write/Edit не поднимает хук gen-tasks-json.cjs; запусти генератор вручную).
11. weekly-review запущен последним шагом — или пользователь явно попросил его пропустить.

В финальном ответе кратко скажи, какой файл создан или обновлён, перечисли основные направления и одним AskUserQuestion предложи: (1) удалить закрытые задачи из tasks.md, (2) закоммитить изменения vault. После ответа на вопросы — запусти weekly-review.