weekly-review

name

weekly-review

description

Провести недельное ревью задач в `tasks.md` — спланировать неделю, разгрузить секцию `# Week:`, разобрать долго висящие задачи с переносом вниз по лестнице Week → Week+ → tasks-future → ideas, проаудитить проекты в `projects.md`, разобрать входящие рабочей почты на предмет зависших задач. Используй, когда пользователь пишет /weekly-review, «спланируй неделю», «недельное ревью задач», «разгрузи задачи», «наведи порядок в tasks», «что переносим на потом» — обычно в воскресенье вечером или понедельник утром, в паре с weekly-report.

weekly-review

Парный скилл к weekly-report: тот смотрит назад (что сделано), этот — вперёд (что делать на неделе). Цель — чтобы # Week: был реалистичным планом на неделю, а не складом всего подряд.

Скилл read-only по умолчанию: собирает факты, классифицирует и предлагает план и переносы. Меняет tasks.md и другие файлы только после явного подтверждения пользователя через AskUserQuestion.

Пути vault

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

Шаги

1. Собрать данные

1. Прочитай tasks.md: открытые задачи секций # Week: и # Week+ с датами ➕ YYYY-MM-DD и подпунктами. Прочитай projects.md — список активных проектов (нужен для шага 4).
2. Возьми сегодняшнюю дату из окружения. Период — 7 дней, заканчивающихся днём report_day (ключ в .claude/vault-config.md; ключа нет — воскресенье, как в weekly-report). Какую неделю планируем: сегодня один из первых 4 дней периода — ревью текущего периода (того, что заканчивается ближайшим report_day); один из последних 3 дней, включая сам report_day, — план следующего периода. В разборе явно назови период.
3. Прочитай дневные логи за прошедшие 7 дней — по заголовкам ## видно, какие задачи реально двигались. Логи лежат в Log/YYYY/MM/YYYY-MM-DD.md; если 7 дней пересекают границу месяца — смотри обе папки месяцев.
4. Возьми контекст прошлой недели из самого свежего недельного отчёта — путь и способ поиска в ключе weekly_report файла .claude/vault-config.md (отчёт делает weekly-report).
5. Прочитай tasks-recurring.md, блок «По датам» (строки вида - 13 число: …) — это дела с фиксированным числом месяца. Разбор по ним — в шаге 4.5. Блок «Месячный обзор» не трогай, он за monthly-review.
6. Первая неделя месяца: если сегодня 1–7 число и месячного итога за прошедший месяц нет (путь — ключ monthly_report из .claude/vault-config.md) — в конце разбора предложи выполнить месячный обзор monthly-review (сначала заверши недельное ревью, месячный — отдельным шагом по согласию пользователя).

2. Оценить темп и размер плана

Темп = число задач верхнего уровня, закрытых за последние 7 дней (по датам ✅ в tasks.md; отчёт — вторичный источник, при расхождении верь ✅-датам). Реалистичный план недели ≈ темпу; если данных нет — ориентир 5–8 задач в # Week:. Всё сверх плана — кандидаты на перенос.

Посчитай и приток: задачи верхнего уровня с ➕ за те же 7 дней (во всём tasks.md). Если в .claude/vault-config.md задан ключ dashboard, готовая строка вида «7 дней: +N / ✅ M» может уже лежать в этой заметке — тогда возьми её оттуда, а не пересчитывай. Если приток больше темпа — Week превращается в заведомо невыполнимый список; скажи это явно числами («пришло +9, закрыто 6») и предложи переносить вниз агрессивнее, чем обычно.

3. Классифицировать открытые задачи Week

Для каждой открытой задачи в # Week: (любой чекбокс, кроме - [x]; правило — в obsidian-vault, «Закрытость чекбокса») определи, в порядке приоритета признаков (движение главнее даты):

• В работе — есть движение за 7 дней или добавлена ≤14 дней назад. Остаётся. Движение — это: заголовок в дневных логах, недавние правки связанных нот (wikilinks из подпунктов; проверь git status / mtime), свежие подпункты.
• Долгожитель — движения нет и ➕ старше 14 дней. Указывай возраст в днях; чем старше, тем настойчивее предлагай перенос. Требует решения: делать на этой неделе / перенести вниз / удалить. Проверь формулировку: если это результат или проект без первого действия («Обработать кухню», «Написать ТЗ») — задача часто висит из-за формулировки, а не приоритета; вместе с переносом предложи переформулировку в конкретное первое действие (глагол + объект) или вынос первого шага отдельной задачей (decompose).
• Возраст неизвестен — нет ➕ и нет движения. Покажи отдельно; возраст можно уточнить по git log -S для tasks.md (даёт нижнюю границу), но не выдумывай дату.

Секцию # Week+ пройди по верхам: кандидаты в tasks-future.md — задачи с ➕ старше месяца без движения. Задачи без ➕ в кандидаты автоматически не записывай — пометь «возраст неизвестен», реши вместе с пользователем.

4. Обзор проектов

Если projects.md в vault нет — весь этот раздел пропусти молча: это штатная ситуация для vault без проектов, а не ошибка конфигурации.

Прочитай projects.md: верхнеуровневый - [ ] — проект, его подчекбоксы — план, обычные подбуллеты — справка. По Дорофееву сущности не перемешиваются: план проекта живёт в projects.md, а в списке задач — только ближайшая задача проекта (у неё есть обратная ссылка - Проект: [[projects]] (...)). Для каждого открытого проекта проверь:

• Есть ли следующая задача в tasks.md? Первая открытая подзадача плана должна лежать в # Week: (или # Week+) как обычная задача — ищи по совпадению текста (и по обратной ссылке - Проект: [[projects]]). Проект без следующей задачи в списке застрял по определению (даже если он «ждёт» — тогда следующая задача звучит как «проверить/дождаться X»). Предложи завести её.
• Двигался ли за 7 дней? — ✅-даты подзадач плана, заголовки дневных логов. Стоящий проект покажи с датой последнего ✅.
• Актуален ли ещё? Замороженный/отпавший проект предложи перенести целиком в tasks-future.md или в snoozed с датой 📅 (через snoozed-task), если это «вернуться позже, когда созреет».

Обратное выделение — скрытые проекты. Просмотри Week/Week+: задача с несколькими подзадачами-этапами или связка из нескольких задач вокруг одного результата — это проект, живущий в списке задач (пользователь мог пропустить). Предложи вынести его в projects.md целиком, оставив в tasks.md только ближайшую задачу (с обратной ссылкой - Проект: [[projects]] (...)).

4.5. Периодические задачи «По датам»

Для каждой строки блока «По датам» из tasks-recurring.md вычисли ближайшую дату срабатывания — это число месяца (напр. «17 число» → 17-е ближайшего месяца, где 17-е ещё не прошло относительно сегодня). Затем сопоставь с окнами относительно планируемой недели (той, что определена в шаге 1):

• Срабатывает в планируемую неделю → выведи в разбор (шаг 5) в блок «Периодические на этой неделе» и предложи как действие добавить в # Week: (через AskUserQuestion, шаг 6). С датой срабатывания.
• Срабатывает в неделю сразу после планируемой (планируемая + 1) → добавь в # Week+ автоматически, без вопроса, строкой - [ ] <дело> 📅 YYYY-MM-DD (дата срабатывания). Это единственное исключение из «read-only по умолчанию» — его пользователь разрешил явно. В финале перечисли, что добавил.
• Срабатывает позже (через 2+ недели) — не трогай, это подхватит следующее ревью (и дашборд из ключа dashboard в .claude/vault-config.md, если он показывает периодические — см. легенду tasks-recurring.md).

Правила:

• Дедуп: если дело уже есть в tasks.md (Week или Week+) по совпадению текста — не добавляй повторно.
• Дату срабатывания не выдумывай за пределами правила «ближайшее число месяца»; если формат строки неясен — покажи в разборе и спроси, автоматически не добавляй.
• Блок «Месячный обзор» из того же файла игнорируй — он за monthly-review.

5. Показать разбор и предложение

Выведи компактный разбор:

Ревью недели 2026-07-20 — 2026-07-26.

План на неделю (оставить в Week, по приоритету):
  1. <задача> — двигалась вчера
  2. <задача> — дедлайн/внешнее ожидание

Долгожители (решить судьбу):
  • <задача> ➕ 2026-06-28 (висит 20 дней, движения нет) → предлагаю Week+
  • <задача> ➕ 2026-07-05 (13 дней) → предлагаю tasks-future

Возраст неизвестен (нет ➕, движения нет):
  • <задача> — в tasks.md минимум с 2026-06-24 (git)

Week+ → tasks-future (➕ старше месяца, движения нет):
  • <задача>

Проекты ([[projects]]):
  ✓ <проект> — двигался (✅ 12.07), следующая задача в Week: «<...>»
  ⚠ <проект> — нет следующей задачи в tasks.md → предлагаю завести «<первая открытая подзадача>»
  💤 <проект> — стоит с ✅ 16.06, актуален? → snoozed/future

Скрытые проекты в Week:
  • <задача-связка> → вынести в projects.md, в Week оставить «<ближайший шаг>»

Периодические «По датам»:
  • <дело> 📅 2026-07-23 — срабатывает на этой неделе → предлагаю в Week
  • <дело> 📅 2026-07-29 — через неделю → добавил в Week+ автоматически

Темп: закрыто за последние 7 дней N (пришло +K), в плане оставляю M.

Порядок приоритета предлагай по смыслу: внешние дедлайны и ожидания чужого ответа выше, «когда-нибудь посмотреть» ниже. По каждому долгожителю дай конкретное предложение (Week+ / tasks-future / ideas / удалить), но решение — за пользователем.

6. Применить по подтверждению

1. Спроси действия через AskUserQuestion с multiSelect: true — один вопрос, где каждое предложенное из разбора действие — отдельная опция (пользователь отмечает галочками те, что применить). Опцию «Другое / свой вариант» добавлять не нужно — AskUserQuestion даёт её сам.
   • Одна опция = одно конкретное действие: «<задача>» → Week+, «<задача>» → tasks-future, Завести задачу проекта «<...>», Переформулировать «<A>» → «<B>», Пересортировать Week и т.п. В label — коротко (задача + цель), в description — детали (возраст, откуда-куда).
   • Опций в одном вопросе максимум 4. Если предложенных действий больше — сгруппируй близкие в одну опцию (например, «3 висяка Week+ → tasks-future» с перечислением в description) или задай несколько вопросов в одном вызове AskUserQuestion (до 4 вопросов), разбив по типу: переносы вниз / переформулировки / проекты.
   • Применяй ровно то, что пользователь отметил. Неотмеченное не трогай. Если выбрал «Другое» — следуй его тексту.
2. Перенос вниз делай, как в этом vault: задача переносится целиком с подпунктами, даты ➕ и ссылки/wikilinks сохраняются.
   • в # Week+ — в конец секции, перед строкой-легендой (ключ tasks_legend в .claude/vault-config.md; ключа нет — просто не трогай строку, начинающуюся с > Активные задачи);
   • в tasks-future.md — в подходящую существующую секцию, новые секции не создавать без нужды;
   • в ideas.md — в конец файла.
3. Пересортировка Week — только подтверждённый порядок открытых задач; закрытые - [x] остаются верхним блоком как есть.
4. Заголовки # Week: / # Week+ и строку-легенду не трогай. Закрытые задачи не удаляй — их чистит weekly-report.

7. Пересмотр «Что дальше» из отчёта → задачи

Пройдись по пунктам раздела ## Что дальше самого свежего отчёта (того, что найден на шаге 1.4; можно по нескольким последним, если пользователь просит) и предложи завести из них задачи в tasks.md.

1. Собери пункты Что дальше, которые выглядят как задача — конкретное закрываемое действие (Сделать..., Поправить..., Написать..., Перенести...). Отсеивай общие наблюдения, статусы и «подумать вообще».
2. Дедуп по tasks.md: если такая открытая задача уже есть (без учёта регистра, по ключевым словам) — не предлагай.
3. По кандидатам задай AskUserQuestion (multiSelect: true) — один вопрос на всю пачку, каждый пункт — опция.
4. Отмеченные добавляй по правилам new-task (позиция по умолчанию — см. new-task, - [ ], дата ➕ YYYY-MM-DD = сегодня, подпункты табом; ссылки из пункта — подбуллетами).
5. Это предложение, не автодействие: добавляй только отмеченное. Кандидатов нет — тихо пропусти.

8. Разбор входящих почты → задачи

Адрес берётся из ключа work_email в .claude/vault-config.md. Ключа нет — весь этот раздел пропусти молча: это штатная ситуация для личного vault, а не ошибка конфигурации.

1. Прочитай inbox тем инструментом, который есть в vault: скилл для работы с почтой, если он установлен, иначе MCP-инструменты почтового провайдера. Если ни того, ни другого нет — пропусти этот раздел. Отбирай письма старше одного дня — свежие не трогай, они ещё в работе.
2. Оставь письма, требующие действия (просьба, вопрос, дело); отсей рассылки, уведомления и явный шум.
3. Дедуп по tasks.md (без учёта регистра, по ключевым словам) — уже заведённое не предлагай.
4. По кандидатам задай AskUserQuestion (multiSelect: true) — список писем (отправитель + суть), один вопрос на всю пачку.
5. Отмеченные добавляй по правилам new-task (позиция по умолчанию — см. new-task, - [ ]). Дата ➕ YYYY-MM-DD = дата письма (когда получено), а не сегодня — так видно, сколько письмо висит. Подбуллетами переноси отправителя и ссылку на письмо.
6. Только чтение и предложение: письма не трогай (не удаляй/не архивируй/не помечай); добавляй только отмеченное. Кандидатов нет — тихо пропусти.

Защита от ошибок

• Ничего не переноси и не сортируй без явного подтверждения — сначала разбор, потом AskUserQuestion. Единственное исключение: периодическая задача «По датам», срабатывающая через неделю после планируемой, добавляется в # Week+ автоматически с датой 📅 (шаг 4.5).
• Не закрывай и не удаляй задачи сам: закрытие — close-task, удаление — только по прямому слову пользователя.
• При переносе не теряй подпункты, ➕-даты, ссылки и wikilinks.
• При выносе скрытого проекта в projects.md переноси весь блок с подпунктами и справкой; в tasks.md оставь ровно одну ближайшую задачу (текст = первая открытая подзадача плана) с обратной ссылкой - Проект: [[projects]] (...).
• Не выдумывай «движение» задачи — опирайся на логи и даты, при сомнении помечай «движение неизвестно».
• Не трогай tasks-snoozed.md — отложенными занимается snoozed-review.
• Не делай git commit автоматически.

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

• weekly-report — отчёт за прошедшую неделю; удобно запускать перед этим скиллом (тот назад/отчёт, этот вперёд/план).
• monthly-review — месячный обзор (итоги месяца, tasks-future, ideas); предлагай его в первую неделю месяца.
• snoozed-review — ревизия отложенных с датой 📅; можно позвать следом.
• new-task — формат строк задач при переносе и заведении, обратная ссылка - Проект: [[projects]].
• close-task — закрытие задач и синхронизация галочек с projects.md.
• decompose — разбить долгожитель-результат на первое действие.
• list-tasks — ежедневный обзор; этот скилл — недельный.

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

1. Разбор показан: план недели, долгожители с предложениями, обзор проектов ([[projects]]), периодические «По датам», темп.
2. До подтверждения файлы не изменены (кроме авто-добавления периодической задачи «через неделю» в Week+, шаг 4.5); остальные действия предложены через AskUserQuestion (multiSelect), одна опция = одно действие.
3. Применено ровно то, что пользователь отметил; неотмеченное не тронуто.
4. После применения: перенесённые задачи ушли целиком (с подпунктами), в # Week: остался согласованный список, легенда и заголовки на месте.
5. Проекты: у каждого открытого проекта есть следующая задача в # Week:/# Week+ (или предложена), стоящие/отпавшие помечены; скрытые проекты предложены к выносу в projects.md.
6. Периодические «По датам»: срабатывающие на планируемой неделе показаны/предложены в Week, срабатывающие через неделю — добавлены в Week+ с 📅 и перечислены в финале; дубли не заведены.
7. В финале — сколько оставлено в Week, сколько перенесено и куда, что добавлено из периодических.
8. Пункты Что дальше из отчёта, похожие на задачи, предложены через AskUserQuestion; в tasks.md добавлено только отмеченное.
9. Входящие почты проверены; из писем старше одного дня предложены задачи через AskUserQuestion (дата ➕ = дата письма); добавлено только отмеченное, письма не тронуты.