---
name: compact-cto-reporting
description: Короткое owner-закрытие для Alex: всегда только `Summary` и `Следующий шаг`. Без техжаргона и лишних деталей.
---

# Compact Reporting (Owner-Friendly)

## Когда использовать

- Нужно сдать отчёт после заметной работы
- Нужен короткий и понятный статус для owner
- Нужно зафиксировать: что сделано и что дальше

## Когда НЕ использовать

- Обычный диалог и короткие ответы
- Уточнения и быстрые проверки
- Ситуации, где формальный отчёт не нужен

## Policy Editing Trigger

Если пользователь меняет сам формат отчёта, лимиты, шаблон или правила этого skill:
- сначала переключись в режим `policy editing`, а не `compact reporting`;
- запрещено подставлять лимиты и формулировки от себя;
- сначала измерь пример/источник пользователя, затем зафиксируй уже готовое число и его происхождение.

## Источник текущего формата

- Source: сообщение пользователя от 2026-04-18: `Мне нужно очень сжато всегда писать summary и следующий шаг.`
- Update 2026-05-20: `Измени скилл, чтобы ты сам описал сжато, определи размер символов и следующий шаг мне не надо писать пока у тебя деплой не закончил.`
- Update 2026-07-02: `Мне по твоим ответам вообще непонятно. Ты что-то делаешь сейчас или ждать тебя нужно?` + `Сделай только робота и человека.` → строка «Следующий шаг» ОБЯЗАНА начинаться с эмодзи чьего хода: `🤖` (работаю я) или `🙋🏻‍♂️` (нужен Алекс). Выбран вариант 1 (эмодзи в начале строки), только эти два символа.
- Update 2026-07-02 (вечер): реальный кейс — задача полностью сдана в git внешнему деву (issue назначен, ждать/мониторить нечего ни мне, ни Алексу), но правило выше знало только 2 состояния → написалось `🤖 нет, задача полностью в гите — жду дева` (сам себе противоречит: `🤖` заявляет активную работу, а «нет»/«жду» это отрицает). Источник (дословно): `надо скилл написать что если нет больше задач и мы все выполнили то ставь галку зеленую эмодзи`. Measurement: «зелёная галка эмодзи» = стандартный ✅ (U+2705, единственный общеупотребимый эмодзи под это описание, рендерится зелёным во всех клиентах). Derivation: введён 3-й маркер `✅` — состояние «эта задача/тред закрыты и сданы, следующего действия прямо сейчас не требуется НИ от меня, НИ от Алекса» (передано деву/во внешнюю очередь и т.п.). Отличие от `🤖`: `🤖` = я сам продолжаю действовать/отчитаюсь по завершении фонового процесса; `✅` = действовать дальше в моменте некому, это финал именно этого куска работы.
- Update 2026-07-06 (№2): «что делать конкретно пиши всегда… я не должен никуда лазить чтобы понять что и где. максимум копи паст должен сделать. след шаг всегда должен быть полным по контексту» → **«Следующий шаг» с ходом 🙋🏻‍♂️ обязан быть САМОДОСТАТОЧНЫМ: если от Алекса нужно действие — в ТЕЛЕ ответа (прямо над закрытием) даётся готовый copy-paste блок команд / кликабельная ссылка / дословный текст, а строка «Следующий шаг» ссылается на него («выполни блок выше»)**. Запрещено: «см. п.1 из карты», «активируй X» без команды, отсылки к файлам/докам, которые Алексу пришлось бы открывать. Тест: может ли Алекс выполнить шаг с телефона одним копипастом/кликом? Нет → шаг не сдан. (Это применение feedback_no_command_fragments + feedback_commands_must_be_clickable_bash к строке закрытия.)
- Update 2026-07-06: обнаружено — целая сессия (2026-07-05/06) закрывалась без эмодзи-маркера хода вообще, хотя правило от 2026-07-02 уже требовало его. Причина: `compact-format.sh` хук проверял только наличие слов `Summary:`/`Следующий шаг:`, саму эмодзи-логику не проверял никогда — Claude полагался на хук как на полный enforcement, хук был неполным. Источник (дословно): «Ты мне хук давай настрой нормально, блядь, чтобы такой херни больше не было.» + «Номера пиаров нормально писать и комменты, чтобы как айдишники я мог имя апеллировать, например, во взаимодействии с девами». Measurement: (1) хук должен механически проверять эмодзи-маркер, не полагаться на память модели; (2) номера PR/issue — НЕ жаргон, разрешены явно (см. §Язык отчёта). Derivation: (1) `install-compact-format-hook.sh` дополнен content-check v3 — блокирует, если «Следующий шаг» не начинается ровно с 🤖/🙋🏻‍♂️/✅ (Python-проверка на маркер, не только regex по словам); установка руками Алекса (`bash platform/scripts/ops/install-compact-format-hook.sh`), т.к. `~/.claude/hooks/*` правит только он. (2) §Язык отчёта дополнен явным исключением для PR/issue/comment-номеров.
- Measurement:
  - пользователь явно назвал 2 обязательных поля: `summary` и `следующий шаг`
  - лимит символов Claude определяет сам: Summary ≤ 160 символов (≈2 строки телефонного экрана)
  - `Следующий шаг` пишется ТОЛЬКО когда все фоновые задачи (deploy, Codex, CI) завершены
- Derivation:
  - формат закрытия = ровно 2 строки
  - `Summary` = 1 строка, максимум 160 символов
  - `Следующий шаг` = 1 строка — только после подтверждения завершения деплоя/фоновой задачи
- Persistence:
  - это правило хранится здесь и в `/Users/alex/Projects/AGENTS.md`

## ⭐ КАНОН ЗАКРЫТИЯ, проходящий ВСЕ гейты одним блоком (2026-07-17)

Закрытие сессии проверяет ОДИН Stop-хук `session-close-dispatcher.sh` — он гоняет все
закрывающие гейты (формат, пруф, ссылки, фиксация, дашборд) за один проход и выдаёт ОДНО
сообщение со всеми провалами сразу. Раньше это были 6 отдельных хуков, блокировавших по
одному → одно и то же переписывалось по 10 раз (жалоба Алекса 17.07). Каскада больше нет.

**Единственный правильный блок закрытия (НЕ дублировать его блоком Готово/Деплой/Дальше!):**

```text
<тело: если заявляешь «готово/задеплоено» — ПРУФ здесь же (HTTP-код реального пути / вывод команды до-после / скрин залогиненного экрана)>

Summary: <≤34 слова; статус ЯВНО: локально / в репо / на проде; что НЕ сделано>
Следующий шаг: <🤖|🙋🏻‍♂️|✅> <одно действие + [ссылка](url) или `команда` в бэктиках; или «—» если делать нечего>
```

Почему один блок достаточен (проверено): `session-summary-nextstep-gate` принимает строку
«Следующий шаг:» наравне с «Дальше:» — ему нужна лишь кликабельная ссылка. Поэтому отдельный
блок «Готово/Деплой/Дальше» из CLAUDE.md НЕ нужен, если Summary даёт статус, а «Следующий шаг»
содержит ссылку/команду. Дублировать оба = та самая «фигня по 10 раз».

**5 правил, чтобы блок прошёл все гейты сразу:**
1. Один блок Summary+Следующий шаг. Не приклеивай второй блок с тем же смыслом.
2. «Следующий шаг» начинается ровно с 🤖 / 🙋🏻‍♂️ / ✅ (маркер хода) и содержит ссылку ИЛИ команду.
3. Заявляешь «готово/работает/задеплоено» → пруф в ЭТОМ ЖЕ сообщении (не localhost — реальный путь).
4. Пути к файлам — только markdown `[текст](путь)`, не голым текстом.
5. «Готово по дашборду/таблице» пиши ТОЛЬКО с Dashboard Gate JSON; иначе не пиши PASS/готово про дашборд.

Установка диспетчера (руками Алекса, `~/.claude` — его): `bash platform/scripts/ops/install-session-close-dispatcher.sh`.

## Pre-flight (применять до написания тела ответа)

Если ответ будет > 400 символов — **сначала напиши строки `Summary` и `Следующий шаг`**, потом тело.
Это гарантирует, что формат не забудется в конце длинного ответа.

Stop hook блокирует ответ без этих строк (3-й+ повтор нарушения, 2026-05-20).

**Handoff-код-блок НЕ заменяет Summary+Следующий шаг (3-й+ повтор нарушения 2026-05-22):**
Даже когда всё тело ответа — это handoff-код-блок (formат B из veda-spec-execution), строки Summary и Следующий шаг ОБЯЗАТЕЛЬНЫ.
Порядок всегда: Summary → Следующий шаг → код-блок.
Чистый код-блок без двух строк закрытия = нарушение, хук заблокирует.

## Главный принцип

Пиши так, чтобы закрытие читалось за несколько секунд и сразу отвечало на 2 вопроса:
- что по факту сделано;
- что дальше.

## Обязательный формат

Всегда только 2 строки, в таком порядке:

```text
Summary: ...
Следующий шаг: ...
```

Правила:
- `Summary:` 1 строка, максимум 160 символов — Claude определяет формулировку сам, сжато
- `Следующий шаг:` 1 строка, ровно один конкретный шаг по сессии/проекту
- **ЭМОДЗИ ЧЬЕГО ХОДА (обязателен, 2026-07-02; дополнен 2026-07-02 вечер):** строка «Следующий шаг» начинается ровно с одного из ТРЁХ маркеров (только эти три, никаких других маркеров/слов перед ними):
  - `Следующий шаг: 🤖 <что именно крутится/что делаю>` = работа идёт на моей стороне (фон-агент, деплой, CI, длинная задача). Алексу ничего делать не нужно, отчитаюсь сам, когда процесс завершится.
  - `Следующий шаг: 🙋🏻‍♂️ <конкретный вопрос или команда>` = работа СТОИТ до ответа Алекса (выбор варианта, команда на деплой, недостающие данные). Формулировка = что именно нужно от него, одним предложением.
  - `Следующий шаг: ✅ <что именно сделано и сдано>` = ВСЁ по этой задаче/треду выполнено и сдано, действовать дальше прямо сейчас некому — ни мне (нет фонового процесса), ни Алексу (нет вопроса/команды). Типовой случай: задача целиком ушла деву в git/во внешнюю очередь, мониторить нечего. НЕ подменять `🤖`, если по факту я жду фоновый процесс, который сам себя доложит (это остаётся `🤖`) — `✅` только когда ждать реально нечего.
  - Смешивать нельзя. Если фон работает И параллельно есть вопрос — ставь `🙋🏻‍♂️` (его ответ критичнее), фон упомянуть в Summary.
- **АБСОЛЮТНОЕ ПРАВИЛО про фоновые процессы (4-й+ повтор нарушения 2026-05-20):**
  - Пока идёт деплой / Codex / CI / ScheduleWakeup / любой `run_in_background` или Monitor — `Следующий шаг` **ЗАПРЕЩЕНО** писать любым другим способом кроме ровно одной строки:
    `Следующий шаг: Deploy идёт, следующий шаг после завершения.`
  - **ЗАПРЕЩЕНО** писать предсказание «что я сделаю после завершения деплоя» (типа «после деплоя сделаю screenshot»). Это вводит owner-а в заблуждение — выглядит как финальный отчёт, хотя работа не закончена. Owner читает «Следующий шаг» как «я уже всё сделал».
  - Только после явного подтверждения завершения (notification о background task done + проверка exit_code/output) — можно писать штатный `Следующий шаг` с реальным действием.
- `не нужен` / `nothing` / «всё закрыто» БЕЗ конкретики — ЗАПРЕЩЕНО. Если задача/тред реально закрыты — используй `✅ <что именно сдано>` (см. эмодзи выше), не голую фразу без содержания.
- если шаг очевиден и безопасен — выполняется, а в строке фиксируется уже следующий после него

## Приоритет формата (критично)

- Для owner-отчётов этот skill — SSOT по формату.
- Если в других инструкциях, спеках или промптах встречается другой формат, по умолчанию игнорируй его и используй только этот.
- Исключение: пользователь в текущем сообщении явно требует другой формат. Тогда сначала обнови SSOT через policy editing и только после этого применяй новый шаблон.

## Обязательная прозрачность статуса

В строке `Summary` всегда явно указывать:
- где сделано: `локально` / `в репо` / `на проде`
- что не сделано из этого трека (например: `на прод не выкачено`)

Запрещено оставлять статус неявным.

## Локальные ссылки (критично)

- Нельзя давать локальную ссылку без проверки доступности.
- Перед ответом агент обязан:
  1) проверить, запущен ли локальный сервер;
  2) если не запущен — запустить сам;
  3) проверить ответ по ссылке (например, `HTTP 200/30x`), и только после этого отправлять ссылку пользователю.
- Если сервер не удалось поднять, вместо ссылки дать короткий факт о причине и что уже проверено.

## Язык отчёта (критично)

- Запрещён техжаргон и внутренние термины, если без них можно обойтись
- Разрешённые термины: `фронтенд`, `бэкенд`, `база данных`, `API`
- Писать `репо` вместо `репозиторий`
- Не использовать названия внутренних функций/классов/файлов в отчёте по умолчанию
- Не вставлять англоязычные сокращения и аббревиатуры без необходимости
- Не писать «если хочешь», «могу сделать», когда шаг уже очевиден
- **Исключение (2026-07-06):** номера PR/issue/комментариев (`#163`, `PR#64`) РАЗРЕШЕНЫ и ожидаются — это не жаргон, а ID, по которым Алекс апеллирует к девам. Источник (дословно): «Номера пиаров нормально писать и комменты, чтобы как айдишники я мог имя апеллировать, например, во взаимодействии с девами». Запрет на жаргон остаётся для имён функций/файлов/классов/команд (`grep`, `agent.py`, `assert_allowed()`) — они по-прежнему не нужны Алексу.

## Содержимое пунктов

- `Summary`: только завершённое, простыми словами, без списков, максимум 34 слова
- `Следующий шаг`: один конкретный шаг по сессии/проекту. НИКОГДА `не нужен`.
- Если пользователь меняет правило формата, сначала обнови SSOT, потом применяй новый формат.

### Правило для строки "Следующий шаг" (критично)

**Главный принцип:** Следующий шаг отвечает на вопрос «что по сессии надо делать дальше». Сессия — это поток задач (BACKLOG, P0/P1, доделки, верификация, связанные треки). Всегда есть следующий шаг — найди его.

**Иерархия источников (читать сверху вниз, остановиться на первом подходящем):**

1. **Незакрытый хвост текущей задачи**: нет push/deploy/верификации на проде, не дёрнул endpoint, не сделал screenshot. → Шаг = закрыть хвост.
2. **Асинхронный процесс в фоне** (Codex `--background`, `run_in_background: true`, `ScheduleWakeup`, `CronCreate`, ожидание человека, долгий деплой). → Шаг = что именно сделаю когда процесс завершится.
3. **Acceptance criteria с отложенной проверкой** (через N дней/недель проверить метрику, ROMI, конверсию). → Шаг = поставить wakeup/cron на дату или назвать дату ручной проверки.
4. **Связанный трек из той же спеки/BACKLOG**: если закрыл #3, есть ли #1/#2 рядом? → Шаг = следующий fix из того же P0-блока.
5. **Глобальный BACKLOG-приоритет**: открой `platform/specs/BACKLOG-*.md`, возьми верхний P0/P1, который не блокирован. → Шаг = название задачи + первое действие.
6. **Decision Router → MEMORY.md**: если по теме есть открытый ROADMAP/SPEC/HANDOFF — указать его как продолжение.

**Запрещённые формулировки:** `не нужен`, `nothing`, `всё закрыто`, `жду указаний`, `на твоё усмотрение`, `можно отдыхать`, пустая строка.

**Примеры правильно:**
- ✅ `Следующий шаг: 🤖 через 14 дней (23.05) проверю Воронка → Платный, что Direct/VK Ads имеют orders>0; если нет — fix #1.`
- ✅ `Следующий шаг: 🤖 беру P0 #1 из BACKLOG — /Воронка 3 таблицы CJM.`
- ✅ `Следующий шаг: 🤖 деплой идёт, отчитаюсь по завершении.` (активный фоновый процесс)
- ✅ `Следующий шаг: 🙋🏻‍♂️ дай команду на деплой (фронт+бэк готовы, смержены).`
- ✅ `Следующий шаг: 🙋🏻‍♂️ выбери вариант схемы A или B.`
- ✅ `Следующий шаг: ✅ задача #117 полностью сдана деву в git, назначена, следить не нужно.`

**Примеры неправильно:**
- ❌ `Следующий шаг: дождаться агентов → ревью PR → доложить.` (нет эмодзи 🤖/🙋🏻‍♂️ — owner не понимает, идёт ли работа или он должен отвечать)
- ❌ `Следующий шаг: по нотификации агента — ревью его PR.` (то же: непонятно чей ход)
- ❌ `Следующий шаг: 🤖 жду фикс билдера, потом мержу и 🙋🏻‍♂️ спрошу про деплой.` (два эмодзи в одной строке; выбери один — тот, чей ход СЕЙЧАС)
- ❌ `Следующий шаг: не нужен.`
- ❌ `Следующий шаг: жду указаний.`
- ❌ `Следующий шаг: на твоё усмотрение.`
- ❌ `Следующий шаг: после деплоя сделаю preview_screenshot.` (предсказывает действие после async — owner думает что работа сделана)
- ❌ `Следующий шаг: после wakeup в 17:25 снять логи и задеплоить.` (то же самое, owner вводится в заблуждение)
- ❌ `Следующий шаг: дождаться Codex, потом проверить pm2.` (то же самое)

## Красные флаги

- Нет строки `Summary:`
- Нет строки `Следующий шаг:`
- Строка «Следующий шаг» не начинается с `🤖`, `🙋🏻‍♂️` или `✅` (owner не понимает, чей ход)
- `🤖` использован там, где по факту ждать/мониторить нечего (должен быть `✅`) — вводит owner-а в заблуждение, что идёт активная работа
- Много технических деталей и непонятных слов
- Несколько «следующих шагов» вместо одного
- `не нужен` / `nothing` / «всё закрыто» / «жду указаний» — запрещено всегда, не только при async-процессе

## Шаблон

```text
Summary: ...
Следующий шаг: ...
```

## Примеры

**Готово (но шаг по сессии всё равно есть):**

Summary: На проде экран со статусами писем и повторной отправкой. Ручной контроль больше не нужен.
Следующий шаг: через 7 дней проверить delivery-rate, если <95% — взять P0 #2 из BACKLOG-email.

**Не готово:**

Summary: Экран добавлен в репо, но на прод не выкачен.
Следующий шаг: задеплоить на sales.myveda.ru.

**Полностью сдано, следить не нужно ни мне, ни Алексу:**

Summary: Задача по сравнению моделей плана полностью описана и сдана деву в git-задаче.
Следующий шаг: ✅ задача #117 в гите у дева, назначена, мониторить не нужно.

**Красный флаг (так быть НЕ должно):**

Summary: Кнопка добавлена.
Следующий шаг: задеплоить, проверить, написать отчёт команде.
^ Нельзя: summary слишком пустой, нет статуса `локально/в репо/на проде`, и перечислено несколько следующих шагов.