# Postanovka

> Пишет «Постановку» задачи для разработки по уже состоявшемуся обсуждению и публикует её в локальный трекер: Кратко, Цель, Контекст, AS-IS (опционально), TO-BE, Требования, Критерии приёмки. Объём подстраивается под размер задачи: скилл рекомендует профиль — детальный или компактный, — а выбор остаётся за пользователем. Без интервью — синтез того, что уже сказано.

- Skill: `qloker/postanovka` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add qloker/postanovka`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qloker/postanovka/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Qloker (https://skillmd.com/u/qloker)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/qloker/postanovka

---


Скилл берёт контекст текущего диалога, приложенные файлы и (если он есть) код репозитория и пишет **Постановку** — артефакт аналитика, по которому разработка делает работу, а приёмка её принимает.

Постановка — не спека и не PRD. Не интервьюируй пользователя, не расширяй объём ради полноты, не переписывай авторский текст своими словами.

**Объём постановки задаёт размер задачи, а не возможности скилла.** Профиля два: детальный — для изменения сценария, компактный — для точечной доработки. Профиль определяется на шаге 2 и загружается отдельным файлом; шаблон артефакта, нормы разделов и профильная часть самопроверки живут там. Этот файл — общая часть: она действует в обоих профилях.

Язык артефакта — русский. Термины предметной области, названия элементов интерфейса и значения справочников переносятся дословно.

## Процесс

1. **Собери источники.** Перечитай диалог и приложенные файлы. Всё, что попадёт в постановку, прослеживается до источника: реплика пользователя, приложенный файл, код репозитория. Утверждение, не выводимое ни из чего из этого, — выдумка, даже если оно «очевидно».
2. **Откалибруй профиль** по разделу «Калибровка профиля». Файл профиля пока не читай: он загружается после ответа пользователя.
3. **Исследуй репозиторий** по критерию раздела «Исследование репозитория». Не подошёл критерий — пропусти шаг молча.
4. **Проверь, нет ли у пользователя готовой структуры.** Принёс текст с блоками Цель / Контекст / AS-IS / TO-BE — ты оформитель, а не соавтор.
5. **Проверь блокирующий пробел.** Непонятно, ЧТО меняется или ЗАЧЕМ, — сформулируй не более пяти закрытых вопросов; задаются они на шаге 6, вместе с вопросом о профиле. Ответ получен — пиши с ним. Ответа в следующей реплике нет — файл всё равно пишется: неотвеченные вопросы уходят в «Открытые вопросы» с пометкой «блокирует», `Status: needs-info`, зависящие разделы пишутся только в подтверждённой части. Повторно те же вопросы не задаются.
6. **Спроси одним сообщением, один раз:** рекомендация профиля с правом выбора и блокирующие вопросы, если они есть. Правила — в разделе «Вопрос о профиле». Спрашивать нечего — шаг пропускается молча.
7. **Прочитай файл выбранного профиля:** детальный — `profiles/full.md`, компактный — `profiles/compact.md`. Второй файл не читается: чужой шаблон в контексте тянет постановку к чужой форме.
8. **Напиши тело постановки по шаблону профиля.** Детальный: реши, нужен ли раздел «Процесс AS-IS», напиши «Процесс TO-BE» как сценарий, сверни его в «Требования», спроецируй требования в «Критерии приёмки». Не пиши требования до TO-BE — получишь набор пожеланий вместо инвариантов. Компактный: напиши «Контекст», затем «Требования», затем «Критерии приёмки».
9. **Напиши блок «Кратко» последним.** Он проекция готового тела, а не заготовка к нему: из требований вынимаются изменения и точные значения, из «Контекста» — текущее ограничение и зачем. Новых фактов блок не вводит. Готовый блок прогоняется тестом читателя.
10. **Собери расхождения и пробелы в «Открытые вопросы».** Ничего не склеивай молча.
11. **Прогони самопроверку** — общую из этого файла и профильную из файла профиля. Любой невыполненный пункт исправляется до записи.
12. **Опубликуй файл** и **выведи в чат сводку** — в файл сводка не пишется.

## Калибровка профиля

Рубрика ниже даёт **рекомендацию**, окончательный выбор — за пользователем: перед началом письма скилл называет рекомендованный профиль и ждёт ответа (раздел «Вопрос о профиле»). Выбранный профиль называется первой строкой сводки.

**Компактный профиль — только если выполнены все четыре условия:**

1. **Изменение атомарное.** Вводится, убирается, переименовывается или перемещается один элемент интерфейса либо одно значение: ссылка, кнопка, поле, пункт списка, подпись, значение справочника. Однородная группа таких элементов, укладывающаяся в одну таблицу, считается одним элементом.
2. **Поведение описывается одной фразой:** где элемент находится, как выглядит, что происходит при нажатии. Ветвлений, состояний, ролей и расчётов нет.
3. **Сценария «до» не существует:** элемента раньше не было либо у существующего элемента меняется одно свойство — позиция, подпись, адрес.
4. **Не затронуты** интеграции с внешними системами, права доступа, расчёты, миграции данных, нормативные требования.

**Нарушено хотя бы одно условие — детальный профиль.** Асимметрия намеренная: недосказанная постановка стоит дороже избыточной.

**Три входных условия старше рубрики:**

- **Принесён аналог.** Пользователь дал готовую постановку как образец — профиль аналога, независимо от рубрики: воспроизводится форма аналога, нормы другого профиля к ней не применяются.
- **Принесена готовая структура** с разделами «Цель» / «Контекст» / AS-IS / TO-BE — детальный профиль: структуру уже выбрал автор.
- **Названа форма.** Пользователь прямо попросил «коротко» или «подробно» — так и есть.

**Эскалация в процессе.** Признаки детального профиля вылезли уже при письме — требований набралось больше шести, или поведение не объясняется без последовательности шагов во времени, — значит калибровка ошиблась: прочитай `profiles/full.md` и напиши постановку заново по нему. Компактная постановка не дописывается до детальной: выйдет детальная без «Цели» и без TO-BE.

**Эскалация работает только над рекомендацией.** Профиль, выбранный пользователем, не переигрывается: он пишется как выбран, а расхождение с рубрикой называется в сводке.

**Обратной эскалации нет.** Детальная постановка, вышедшая короткой, в компактную не переписывается: признак детального профиля уже сработал, и короткой она получилась потому, что источник дал мало фактов.

## Вопрос о профиле

Рубрика рекомендует, решает пользователь. Вопрос задаётся один раз, до начала письма, вместе с блокирующими вопросами — одним сообщением, а не двумя.

**Вопрос не задаётся, если профиль уже задан входными данными:** пользователь назвал форму («коротко», «подробно», «как в прошлый раз»), принёс постановку-аналог или готовую структуру с разделами «Цель» / «Контекст» / AS-IS / TO-BE. Спрашивать о том, что уже сказано, — интервью.

**Форма — не более четырёх строк:**

```
Профиль: рекомендую компактный — <признак рубрики, по которому он выбран>.
Компактный: Кратко, Контекст, Требования, Критерии приёмки — до ~300 слов.
Детальный: плюс Цель с метрикой, Процесс AS-IS и Процесс TO-BE — ~600–1000 слов.
Пишу компактный? Ответьте «детальный», если нужен полный разбор.
```

Рекомендация называется первой, признак — конкретный, из рубрики, а не «задача небольшая». Устройство профилей не расписывается, правила не перечисляются, уговаривать не нужно. Блокирующие вопросы идут следом, отдельным списком, в том же сообщении.

Если в сессии есть интерактивный выбор варианта, вопрос о профиле можно задать им — но только когда блокирующих вопросов нет: два способа спросить в одном сообщении сбивают ответ.

**Ответа нет — пиши по рекомендации.** Следующая реплика не о профиле (содержательное дополнение к задаче, приложенный файл, «давай») — это не отказ и не повод спросить снова: берётся рекомендованный профиль, в сводке это названо.

**Выбор пользователя старше рубрики.** Выбран профиль, которого рубрика не рекомендовала, — он и пишется, без возражений и без «но лучше бы». Расхождение называется одной строкой сводки.

**Ничего не теряется ради нормы профиля.** Выбран компактный, а требований набралось девять — пишутся все девять; норма уступает полноте, и в сводке сказано, что постановка вышла за норму. Выбран детальный для точечной задачи — разделы пишутся, но пустые слоты не добиваются домыслом: «Цель» сводится к строке «Критерий достижения», AS-IS опускается.

**Названо отклонение от профиля** («компактный, но с «Целью»») — выполняется дословно и называется в сводке.

## Работа с пробелами

Не интервьюируй пользователя. Всё нужное уже сказано; твоя работа — синтез, а не сбор. Исключения два, оба разовые и укладываются в одно сообщение: блокирующий пробел по правилам ниже и вопрос о профиле — он о форме документа, а не о содержании задачи.

1. **Никогда не выдумывай.** Числа, названия полей, значения справочников, тексты кнопок, сроки, метрики, точки интеграции, имена модулей — если их не назвали, их нет. Правдоподобная подстановка хуже дырки: дырку заметят, подстановку реализуют.
2. **Никогда не выбрасывай молча.** Пробел, влияющий на требование, должен быть виден в артефакте.
3. **Выноси в «Открытые вопросы».** Вопрос закрытый, с вариантами ответа; в нём указан номер пункта, к которому он относится, и пометка «блокирует» либо «не блокирует». «Уточните, пожалуйста» — не вопрос.

**Противоречие во входных данных — тоже вопрос, а не задача на склейку.** «Заказы» в одном месте и «возвратные накладные» в другом; два значения справочника с дословно одинаковым описанием; названный элемент без описания поведения — всё это выносится вопросом. Не выбирай вариант сам, не усредняй, не переименовывай в общий термин, не дописывай различие («(для кормов)») — дописанное выглядит как факт предметной области, но им не является.

**Вопрос заводится только там, где без ответа пункт нельзя написать в том виде, в каком он написан.** Поведение уже определено — вопроса нет. Не заводится вопрос на объём приёмочной проверки («какие разрешения считать поддерживаемыми», «на каких браузерах гонять»): это работа приёмки, а не дырка постановки. Не заводится вопрос на элемент, который назван в перечне затронутых, а не введён как объект изменения: cookie-баннер в списке слоёв под затемнением получает поведение из того же требования, что и остальные элементы списка, — «а что с ним потом» дыркой не является. Правило «названный элемент без описания поведения — вопрос» относится к элементу, который требование вводит: кнопка «Честный знак» появляется в постановке впервые, и без её поведения при нажатии пункт не реализуется.

**Молча правится только форма:** орфография, пунктуация, регистр, согласование в служебных словах и структурные операции из раздела «Если во входных данных уже есть структура». Термины, названия элементов интерфейса, названия сущностей, числа, коды и значения справочников не правятся никогда.

## Если во входных данных уже есть структура

Авторский текст главный. Ты его оформитель.

**Разрешено:** перенести абзац в соответствующий раздел; привести порядок разделов к целевому; разбить сплошной абзац на нумерованные пункты, не меняя слов; превратить перечисление данных в таблицу, включая вынос в заголовок колонки служебного оборота, буквально совпадающего во **всех** строках; исправить очевидную опечатку; дописать недостающие разделы; сохранить авторскую модальность в блоке «Требования» («необходимо отображать», «должны входить») — это нормальная лексика требований.

**Запрещено:** переписывать формулировку «чётче»; заменять термин пользователя своим, в том числе на более техничный («весь экран» → «весь вьюпорт»); усиливать авторскую характеристику («инструмент сбора базы email» → «платный инструмент», «лид потерян» → «потерян безвозвратно», «перекрытие оффера» → «деградация оффера») — усиление читается как факт предметной области, которого автор не утверждал; объединять или дробить смысловые пункты; добавлять требования, не следующие прямо из авторского TO-BE или Контекста; разворачивать короткий список в длинный ради полноты.

Два авторских блока противоречат друг другу — не выбирай победителя, вынеси в «Открытые вопросы».

## Исследование репозитория

Репозиторий — вспомогательный источник фактов, а не обязательный: постановка может описывать систему, которой в этом репозитории нет (сайт, 1С, чужая админка).

**Критерий:** репозиторий исследуется, если хотя бы один термин из диалога встречается в `CONTEXT.md` / `CONTEXT-MAP.md` или в заголовке файла из `docs/adr/`. Тогда читаются `CONTEXT.md` целиком и те ADR, в заголовке которых есть термин из диалога (см. `docs/agents/domain.md`, а если его нет — просто эти файлы). Совпадений нет — репозиторий не источник, шаг пропускается молча, без извинений и без примечаний в артефакте.

- Термины глоссария используй дословно, синонимы не подставляй.
- Описанный пользователем AS-IS расходится с кодом — не исправляй молча, вынеси вопросом.
- Постановка противоречит существующему ADR — скажи об этом вопросом, а не переписывай ADR.

**Никогда не приводи в постановке пути к файлам, фрагменты кода, имена модулей, компонентов, таблиц и эндпоинтов.** Постановка описывает поведение системы, а не её устройство.

**Обратное правило:** дословные значения предметной области — названия полей, значения справочников, тексты кнопок, формулы вида `ТН ВЭД = "не подлежит маркировке"` — приводятся буквально и перефразированию не подлежат. Это факты, а не код.

## Объём

Числовые нормы разделов задаёт профиль — таблица в его файле. **Норма всегда потолок, а не квота:** добивать список до нижней границы дроблением, переформулировкой или домыслом запрещено.

**Строки таблиц, подпункты `N.M.` и «Открытые вопросы» в норму объёма не входят.** Таблица переносит перечисление источника целиком: схлопывать строки, дописывать «и т. д.» или резать таблицу ради объёма запрещено. Постановка с одним пунктом требований и таблицей на двадцать строк — нормальная постановка.

User stories («Как <роль>, я хочу…») не пишутся вообще. Требование, которое не меняет поведение системы, — не требование; исключение — негативное требование-граница «X не изменяется»: оно обязательно по правилам раздела «Границы задачи».

## Стиль

- Настоящее время, третье лицо, короткие предложения. TO-BE тоже в настоящем времени. Правило относится к тексту, который пишешь ты: авторские формулировки требований с «необходимо / должен» сохраняются дословно. Второе отступление — пункт верхнего уровня блока «Требования», имеющий подпункты: он формулируется инфинитивом действия.
- Никакого «мы», никакого обращения к читателю.
- **Оценочная и эмоциональная риторика запрещена.** «Пользователь наказывается потерей акции», «это недопустимо», «страдает» — вырезать. Пиши факт: «промо-окно исчезает и в этой сессии больше не показывается».
- **Кавычки.** Обёртка вокруг названия элемента интерфейса нормализуется в «ёлочки» независимо от кавычек источника — это пунктуация, а не название: «Колесо», «Нет, другой», «Честный знак». Кавычки внутри значения — в формуле, коде справочника, строковом литерале — сохраняются как в источнике: `ТН ВЭД = "не подлежит маркировке"`. Меняется только обёртка, никогда — содержимое. В первой колонке таблицы кавычки не ставятся: вид элемента задан заголовком колонки.
- Тире `—` как основной знак пояснения. Заголовок артефакта — `# H1`, разделы — `##` с точными именами из шаблона: не переводить, не сокращать, не переставлять.

### Выделение жирным

Жирное начертание в артефакте — навигация по точным значениям, а не эмфаза. Читатель должен находить взглядом то, по чему делается и проверяется работа, не перечитывая пункт целиком.

**Выделяется:** имя вводимого или изменяемого элемента — **«Новости»**; его место и позиция — в блоке **«Компания»**, **третьим пунктом**; адрес, число, срок, значение справочника; платформа или сегмент, если задача ими ограничена; отрицание в негативном требовании и зеркальном критерии — **не изменяется**, **не регрессировал**.

**Где выделение допустимо:** «Кратко», «Требования», «Критерии приёмки». В «Цели», «Контексте», «Процессе AS-IS» и «Процессе TO-BE» выделений нет — это проза, в ней подсветка отдельных значений теряет смысл. В ячейках таблиц выделений нет: колонка уже выделяет.

**Не более двух выделений в пункте** — имена слотов «Кратко» не в счёт. Выделено больше половины строки — сними выделение целиком: подсвечено всё значит не подсвечено ничего.

**Не выделяются:** целые предложения и придаточные; модальность «должен», «необходимо», «требуется»; слово, повторяющееся в каждом пункте блока — если «футер» выделен в шести пунктах подряд, выделение не различает пункты и снимается везде.

Кавычки и выделение не конкурируют: ёлочки входят внутрь выделения — `**«Новости»**`, а не `«**Новости**»`.

## Раздел «Кратко»

Обязателен в обоих профилях. Первый раздел артефакта: сразу после строки `Status:`, до «Цели» в детальном профиле. За десять секунд читатель узнаёт, **что меняется, где, какие значения ключевые и зачем** — не открывая тело постановки.

**Главный тест — тест читателя.** Прочитай каждую строку так, будто тела постановки нет. Остался вопрос «что именно?», «что с этим происходит?» или «и что это даёт?» — строка переписывается. «Что: строка оценки и отзывов, однострочные чипы фасовок и минус на кнопках покупки» тест не проходит: предметы перечислены, но не сказано, что с ними происходит и зачем минус. «Зачем: лишние элементы в карточке» не проходит: какие элементы — неизвестно.

Форма — от трёх до семи строк вида `* **<Слот>:** <текст>.` Строка — одно предложение; уточнение через тире, точку с запятой или в скобках допустимо, второе предложение — нет. Всё, что не помещается в строку, живёт в «Требованиях».

### Как формулируется строка

1. **Сначала изменение, потом предмет.** Каждое изменение начинается с глагола: «добавляется», «изменяется», «убирается», «заменяется», «переносится». Перечень предметов без глагола — не изменение, а опись.
2. **Назначение, а не деталь реализации.** Элемент называется через то, что он даёт пользователю: «добавляется управление количеством товара в корзине через каталог», а не «минус на кнопках покупки». Название элемента из тела ставится рядом, когда без него элемент не узнать: «управление количеством (каунтер)». Детали вида «однострочный», «обрезается многоточием», «между названием и сеткой фасовок» остаются в «Требованиях».
3. **Текущее ограничение — коротким противопоставлением,** если без него смысл изменения не виден: «— сейчас убавить количество или убрать товар можно только из корзины». Пишется один раз — у того изменения, которое ограничение снимает, — и только если факт есть в теле. В «Что» и «Зачем» одновременно не повторяется.
4. **Точные значения — после сказанного, к чему они относятся:** «изменяется подпись причины сниженной цены — «Скидка из-за срока годности» или «Уценка»», «ссылка ведёт в раздел новостей — https://www.petshop.ru/news/». Строка из одних значений тест читателя не проходит.

### Слоты

| Слот | Что в нём | Пример |
| --- | --- | --- |
| Что | изменения задачи, каждое с глаголом; не больше трёх в строке | добавляется строка **оценки и отзывов**, изменяются чипы фасовок, добавляется **управление количеством** товара в корзине через каталог — сейчас убавить количество или убрать товар можно только из корзины |
| Где | место основных изменений и второстепенные места — с тем, что меняется там; позиция в списке; платформы, если они одни на всю задачу | основные изменения — в каталоге товаров на десктопе и в мобильной версии веба; на **странице товара** меняются только каунтер и иконка скидки в чипе фасовки |
| Объект изменения | отдельное изменение со своими значениями или условием; имя слота — по объекту: «Текст», «Иконка», «Адрес», «Кнопка»; строка тоже начинается с изменения или с того, к чему относится значение | изменяется подпись причины сниженной цены — **«Скидка из-за срока годности»** или **«Уценка»** |
| Платформы | только если платформы различаются между изменениями или сами — предмет задачи | каунтер — десктоп и мобильный веб, приложение не затрагивается |
| Зачем | потеря или цель — конкретно: что именно мешает или лишнее | упростить карточку — убрать плашку и сердечко на чипе фасовки и подписи со сроком доставки под кнопками покупки |
| Не входит | смежное, что иначе прочитают как часть задачи | страница корзины, мобильное приложение |

Порядок строк — как в таблице. **Набор слотов — меню, а не комплект:** пишется только слот, для которого в теле постановки есть факт; заглушек нет. Практический минимум — «Что», «Где» и «Зачем».

**Полнота.** Каждый пункт верхнего уровня «Требований», который добавляет, убирает или меняет видимый элемент либо возможность пользователя, узнаётся в «Кратко». Исключения два: пункт о крайних состояниях уже названного элемента и негативная граница — она попадает только в «Не входит». Изменений больше, чем помещается в «Что», — они группируются по объекту и получают свои строки, а не выбрасываются. Новая иконка скидки, которой нет в «Кратко», — дефект блока, даже если в «Требованиях» она описана.

**Недостающее ключевое значение не пропускается молча.** Позиция, адрес, текст не названы в источнике — строка говорит об этом прямо: «место в списке блока не названо (см. вопрос 1)». Пометка `(см. вопрос N)` в строке блока ставится только вместе с такой же пометкой в требовании, которое эту строку подтверждает.

**«Кратко» — проекция, а не источник.** Каждый факт блока присутствует ниже: изменения и значения — в «Требованиях», текущее ограничение — в «Контексте» или «Процессе AS-IS», «Зачем» — в «Цели» (детальный профиль) или в «Контексте» (компактный). Факта, которого нет в теле постановки, в блоке не бывает: он не попадёт ни в одну приёмочную проверку. Названия элементов — те же, что ниже; назначение элемента описывается своими словами, нового названия элемент не получает.

**Чисел-целей в блоке нет:** метрика живёт только в «Цели». Числа-факты, по которым делается работа, — позиция в списке, количество элементов, срок — метрикой не являются и пишутся.

## Раздел «Требования»

**Правила этого раздела действуют в обоих профилях.** В компактном профиле раздела «Процесс TO-BE» нет: требования выводятся напрямую из «Кратко» и «Контекста», и правила соответствия шагов TO-BE требованиям к нему не применяются. Всё остальное — форма списка, экранирование номеров, условия таблицы, запреты — применяется без изменений.

TO-BE и Требования — две проекции одного будущего состояния.

| | Процесс TO-BE | Требования |
| --- | --- | --- |
| Природа | Сценарий во времени | Набор инвариантов |
| Единица | Шаг | Проверяемое утверждение |
| Порядок | Значим | Не значим |
| Лексика | «открывается», «затем», «пользователь оставляет email» | «единственный активный слой», «не реагируют», «откладывается», «не изменяется» |

Таблица различает проекции, а не запрещает слова. Одно свойство законно названо и в TO-BE — как состояние, наступающее на конкретном шаге, и в Требованиях — как инвариант без момента. Совпадение формулировок дублированием не считается и вычищению не подлежит.

**Четыре теста при разнесении пункта:** пункты переставляются без потери смысла → Требования; пункт соединяется с соседним через «затем / после этого» → шаг TO-BE; каждое требование проверяемо отдельной проверкой, шаг TO-BE сам по себе проверкой не является; пункт нужен, чтобы заказчик согласился с поведением, — TO-BE, чтобы разработчик знал, что кодить, — Требования.

**Механика перехода:** сворачивай TO-BE в требования по шагам. Один шаг может дать несколько требований — это норма. Абзац «Что меняется по сути» в требования не переносится никогда.

**Запрет вниз:** требование, не выводимое ни из TO-BE, ни из Контекста, — придуманный скоуп. Удали или вынеси вопросом.
**Запрет вверх:** шаг TO-BE, который меняет поведение системы и не отражён ни в одном требовании, — потерянное требование. Исключение — установочный шаг, описывающий вход в сценарий и не меняющийся задачей («Пользователь заходит на сайт с десктопа»): он требования не порождает. Шаг 1, совпадающий с шагом 1 AS-IS, — всегда установочный.

### Форма: один список, два режима детализации

Блок «Требования» — **всегда единый сквозной нумерованный список от 1**.

**По умолчанию все пункты плоские.** Простой список из семи однострочных утверждений — полноценная и самая частая форма блока; такая постановка ничего не потеряла и доработки не требует. Подпункты и таблицы появляются не потому, что скилл умеет их делать, а только там, где сработал тест на разложение, и ровно в тех пунктах, где он сработал. Прежде чем разложить пункт на подпункты, назови элемент данных, который в нём перечисляется. Не назвал — пункт остаётся плоским. Форма выбирается для каждого пункта отдельно: пункт 1 может быть однострочным, пункт 2 — с подпунктами и таблицей.

**Тест на разложение.** Сформулируй пункт как одно предложение, из которого выводится ровно одна приёмочная проверка. Получилось — пункт плоский. Не получилось (появляется «и ещё», перечисление именованных сущностей, проверка перебором) — разложи на подпункты. Подпункты нужны, когда требование вводит объект с **внутренним устройством** (кнопка со сценарием, фильтр со значениями, форма с полями, грид с колонками, статусная модель), и не нужны, когда требование описывает **свойство поведения** — перечислять нечего.

| Случай | Как формулируется | Пример |
| --- | --- | --- |
| Пункт с подпунктами | Действие над системой в инфинитиве + имя объекта; это заголовок, деталей поведения в нём нет, точкой не заканчивается | `2\. Добавить кнопку «Честный знак»` |
| Пункт без подпунктов | Проверяемое утверждение о поведении системы, заканчивается точкой | `3\. Пока промо-окно открыто, переход к смене города невозможен ни из одной точки входа.` |

**Нумерация.** Максимум два уровня, `N.` и `N.M.` Третий уровень запрещён: тянется на `N.M.K.` — пункт верхнего уровня объединил два изменения, разбей. Точка после номера обязательна на обоих уровнях. Верхний уровень сквозной, подпункты перезапускаются внутри пункта.

Markdown превращает `2. ` в маркер списка и после каждого разрыва — подпункта, свободного абзаца, таблицы — начинает счёт заново, поэтому **экранируй первую точку в каждом пункте верхнего уровня всегда, а не по результату проверки**: `1\.`, `2\.`, `3\.` Смешивать в одном блоке списочные и экранированные пункты нельзя — отступы разойдутся. Подпункты `2.1.` markdown списком не считает (после `2.` нет пробела) — их не экранируют никогда. Правило действует только внутри блока «Требования»: «Критерии приёмки» — буллиты, «Открытые вопросы» — обычный нумерованный список.

**Маркированные списки (`-`, `*`) в блоке «Требования» не используются вообще.** Любое перечисление оформляется одним из трёх способов: таблица, отдельные нумерованные подпункты, перечисление внутри предложения через запятую.

**Свободный абзац без номера** допустим: он принадлежит пункту, после которого стоит, и вводит объект, детализируемый следующим подпунктом. Тест: абзац допустим, если всё проверяемое в нём повторно выражено этим подпунктом. Абзац «Для этого нужно настроить фильтр «Маркированные товары» для оптовых заказов.» допустим — существование фильтра выводится из следующего подпункта с составом его значений. Абзац, несущий проверку, которой нет ни в одном соседнем подпункте, обязан получить номер. Не более одного абзаца подряд, 1–3 предложения, не перед пунктом 1.

### Когда перечисление становится таблицей

Перечисление превращается в markdown-таблицу тогда и только тогда, когда выполнены **оба** условия:

1. **Однородность** — элементы являются экземплярами одной сущности: значения одного фильтра, поля одной формы, колонки одного грида, статусы одной модели, роли, типы документов, события.
2. **Второе измерение** — у каждого элемента есть имя И про каждый сказано что-то в одном и том же измерении: поведение, тип, обязательность, источник, правило вычисления.

**Тест заголовка колонки.** Придумай заголовок второй колонки, честно подходящий ко всем элементам. Придумался («Поведение при выборе», «Что показывает», «Правило заполнения») — таблица. Не придумался, потому что элементы говорят о разном, — оставь текстом.

**Порог — от двух строк.** Единственный элемент вносится в подпункт предложением: `2.1. В фильтр входит одно значение — «Все заказы»: показываются только заказы, содержащие маркированный товар.`

**Ввод таблицы.** Таблица всегда принадлежит пункту или подпункту и вводится его последней фразой с двоеточием: «В него должны входить поля:», «Грид содержит колонки:». Таблица, стоящая между пунктами сама по себе, запрещена — из неё не выводится, что требуется сделать. Приёмочная проверка формулируется по паре «вводящая фраза + таблица».

**Стоп-признак:** вторая колонка получается одинаковой у **всех без исключения** строк — таблицы быть не должно, элементы объединяются в одно предложение («Промо-окно закрывается крестиком, клавишей Esc и кликом по затемнению.»). Совпадение описаний у *части* строк — не стоп-признак, а дефект источника: строки сохраняются, расхождение идёт в «Открытые вопросы».

Остаются текстом: перечень затронутых элементов без описания каждого, перечень точек входа, перечень исключений. И отдельно: **сам список требований таблицей не становится никогда.**

Развёрнутый образец пункта с подпунктами и таблицей — в `profiles/full.md`.

**Колонки.** Базовый набор — две: имя элемента (заголовок — вид элемента в единственном числе, словом из источника: «Значение фильтра», «Поле», «Колонка», «Статус», «Роль», «Событие», «Тип документа») и единственное измерение, в котором источник описал все элементы. Колонка добавляется тогда и только тогда, когда её значение известно из источника **для каждой строки**; известно для части — колонка не заводится, недостающее идёт в вопрос. **Придумывать значения, чтобы заполнить колонку, запрещено.** Максимум 4 колонки. Порядок: имя первым, самое длинное описание — последним.

**Ячейки.** Одна ячейка — одно значение, без вложенных списков и переносов строк. Точные значения предметной области переносятся дословно. **Вынос общего зачина:** если все ячейки колонки начинаются с дословно одинакового служебного оборота, оборот переносится в заголовок колонки и удаляется из ячеек; содержательные слова не трогаются.

### Запрещено в блоке «Требования»

- перечислять элементы данных маркированным списком вместо таблицы;
- пересказывать TO-BE прозой («промо становится приоритетным сценарием»);
- непроверяемые требования («работает быстро», «удобно»);
- формулировки «проверить, что…» — это Критерии приёмки;
- склеивать несколько требований в один пункт;
- перефразировать доменные значения и подписи интерфейса;
- называть модули, схемы, эндпоинты и архитектурные решения;
- молча сглаживать противоречия источника.

## Раздел «Критерии приёмки»

Обязателен всегда. Маркированный список, по одной строке. Критериев столько же, сколько требований, минус закрытые общим наблюдением; больше числа требований критериев не бывает.

Каждое требование закрыто хотя бы одним критерием. Требование, для которого невозможно придумать наблюдаемый критерий, сформулировано плохо — переформулируй требование, а не изобретай критерий.

**Требование с таблицей закрывается одним критерием-квантором, а не построчно:** «Каждое из шести значений фильтра «Маркированные товары» отбирает в гриде ровно тот набор документов, который указан в требовании 2.2». Расписывать по буллиту на строку таблицы запрещено.

Критерий описывает наблюдаемый снаружи результат глазами проверяющего. Не «промо-окно работает корректно», а «при открытом промо-окне ни один элемент страницы вне промо не реагирует на клик, включая название города в шапке». Предпочитай квантор «ни один / ни на одном / ни из одной».

Каждое негативное требование-граница закрывается собственным зеркальным критерием («X не регрессировал»); такие критерии идут последними. Негативных требований нет — зеркального критерия нет, выдумывать его запрещено.

**Запрещено:** дословный повтор требований; критерии без наблюдаемого признака («требование 1 реализовано»); критерии на то, чего нет в требованиях; продуктовые метрики с числами; Gherkin; нумерация вместо буллитов; указание, каким модулем или тестом это достигается.

## Границы задачи: раздела «Вне скоупа» не бывает

Отдельный раздел не заводится. Граница оформляется **триадой**: фраза-обоснование в последнем абзаце «Контекста» (не «не входит», а почему безопасно не входит) → негативное требование «X не изменяется» → зеркальный критерий «X не регрессировал».

**Критерий отбора:** явно фиксируется только та граница, которую читатель иначе мог бы прочитать как входящую в задачу. Остальное в скоуп не входит уже потому, что о нём не сказано. Границ больше трёх — допустим один абзац в конце «Контекста» «В рамках задачи не изменяются: …», но не отдельный раздел.

**В компактном профиле триада усечена:** не более одного негативного требования и одного зеркального критерия; абзац-обоснование в «Контексте» пишется, только если без него граница читается как часть задачи.

## Заголовок артефакта

Полная форма: `# Постановка: <отглагольное существительное> <объект в «ёлочках»> <над / для / в> <второй объект> (<скоуп>)`
Краткая форма: `# Постановка: <отглагольное существительное> <объект в «ёлочках»>`

- Префикс `Постановка: ` литеральный, после двоеточия — строчная буква. Точки в конце нет.
- Ядро — отглагольное существительное, называющее изменение («приоритизация»), а не проблему («конфликт слоёв») и не пользу («рост конверсии»).
- Второй объект пишется, только если изменение состоит в отношении двух объектов (приоритет, замена, перенос). Скоуп в скобках (одно-два слова дословно из источника) пишется, только если источник ограничил задачу платформой, разделом или ролью. Ни один слот не заполняется догадкой; отсутствующий слот не пишется вместе с предлогом и скобками.

Примеры: `# Постановка: приоритизация промо-окна «Колесо» над сценарием выбора города (десктоп)`; `# Постановка: добавление кнопки «Честный знак» в оптовые заказы`.

## Публикация

Постановка публикуется по конвенциям `docs/agents/issue-tracker.md`: файл **`.scratch/<feature-slug>/spec.md`**, директория создаётся, если её нет. Имя файла — адрес, а не жанр; жанр задаёт заголовок внутри файла. Не создавай `postanovka.md` рядом со `spec.md`.

Конвенций трекера в проекте нет — пиши по той же схеме от корня текущего проекта и одной строкой скажи, что конвенции не найдены и их ставит `/setup-matt-pocock-skills`. Работа идёт вне репозитория — файл `<feature-slug>.md` в текущей папке. Постановку из-за этого не задерживай; фактический путь всегда называется первой строкой сводки.

**Файл уже существует — прочитай первую строку.**

- Начинается с `# Постановка:` и это та же задача → перепиши файл целиком, старую структуру не сохраняй и не смешивай.
- Не начинается с `# Постановка:` → файл написан другим скиллом (`to-spec`, `use-case`) и может быть нужен пользователю как есть. **Не перезаписывай.** Покажи его первую строку и спроси одним вопросом: перезаписать или писать в новую папку. Без явного ответа файл не трогай.
- Другая задача → не трогай файл, выбери другой slug.

Сразу под заголовком, через пустую строку, идёт строка `Status:` — первая непустая строка после H1; других строк до первого `##` нет. Значение — из словаря `docs/agents/issue-tracker.md`; постановка использует два из пяти. Тест: можно ли реализовать и принять пункт, к которому относится вопрос, не получив ответа?

- вопросов нет → `ready-for-agent`
- хотя бы один помечен «блокирует» (без ответа пункт нельзя ни закодить, ни проверить) → `needs-info`
- все помечены «не блокирует» (ответ уточняет формулировку, поведение уже определено) → `ready-for-agent`

Не ставь `ready-for-agent` из вежливости. `needs-info` на постановке с дырками честнее зелёного света.

### Как строится feature-slug

Slug — ключ папки, он должен быть детерминированным: транслитерация, не перевод.

1. Возьми заголовок без префикса `Постановка: `.
2. Отбрось только скобочный скоуп в конце. Кавычки-ёлочки сними как символы, но слово внутри сохрани: `«Колесо»` → `Колесо`. Название объекта — самое опознаваемое слово в slug, выбрасывать его нельзя.
3. Приведи всё к нижнему регистру — **до** транслитерации: таблица ниже содержит только строчные буквы, прописная в неё не попадёт и останется кириллицей.
4. Отбрось предлоги и союзы (для, над, при, в, на, из, и, или, с, по, без) и возьми **ровно первые 4** значащих слова в исходном порядке и в исходной форме (меньше четырёх — бери сколько есть).
5. Латинские слова и общепринятые термины оставь как есть (promo, email, api, checkout, sku).
6. Остальное транслитерируй: а a, б b, в v, г g, д d, е e, ё e, ж zh, з z, и i, й y, к k, л l, м m, н n, о o, п p, р r, с s, т t, у u, ф f, х h, ц c, ч ch, ш sh, щ sch, ъ —, ы y, ь —, э e, ю yu, я ya.
7. Пробелы → дефис, схлопни повторные дефисы, **удали все символы кроме `a–z`, `0–9` и дефиса**, обрежь до 40 символов по границе слова, убери дефис на конце.

Проверка: `Постановка: приоритизация промо-окна «Колесо» над сценарием выбора города (десктоп)` → `приоритизация промо-окна колесо сценарием` → `prioritizaciya-promo-okna-koleso-scenariem` (42 символа) → **`prioritizaciya-promo-okna-koleso`**. Второй пример: `добавление кнопки «Честный знак» в грид заказов` → `dobavlenie-knopki-chestnyy-znak`.

**Перед созданием папки просмотри `.scratch/`.** Сравнивай не строку заголовка, а предмет: тот же объект изменения и то же изменение — та же задача, даже если старый файл озаглавлен иначе или вовсе без префикса «Постановка:». Читай первые 15 строк каждого `*/spec.md`. Совпало — используй найденный slug как есть: совпадение адреса важнее соответствия правилу.

## Самопроверка перед записью файла

Общая часть — ниже. Профильная — в файле профиля: порядок разделов, нормы объёма и требования к «Цели», «Контексту», AS-IS и TO-BE. Прогоняются обе; любой невыполненный пункт исправляется до записи.

1. Нет user stories, нет разделов Implementation Decisions, Testing Decisions, Out of Scope, Further Notes.
2. «Кратко» — первый раздел после строки `Status:`; в нём 3–7 строк; каждая проходит тест читателя: изменение названо глаголом, элемент — через назначение, значения — после сказанного, к чему они относятся. Каждый пункт верхнего уровня «Требований», меняющий видимый элемент или возможность, узнаётся в блоке; каждый факт блока присутствует ниже; заглушек и чисел-целей нет.
3. Жирным выделены только точные значения; в «Цели», «Контексте», «AS-IS», «TO-BE» и в ячейках таблиц выделений нет; ни в одном пункте выделений больше двух; ни одно слово не выделено во всех пунктах блока подряд.
4. В блоке «Требования» ни одна строка не начинается с `-` или `*` (разделитель таблицы `| --- |` маркером не считается); каждое перечисление, прошедшее **оба** условия раздела «Когда перечисление становится таблицей», оформлено таблицей, и ни одно непрошедшее — не оформлено; глубина нумерации не больше двух уровней; у всех пунктов верхнего уровня первая точка экранирована.
5. Ни одна таблица не содержит колонки, заполненной догадками; количество строк равно количеству элементов в источнике.
6. Каждое требование закрыто хотя бы одним критерием приёмки; критерии — буллиты, требования — номера.
7. В артефакте нет путей к файлам, кода, имён модулей и эндпоинтов.
8. Нет оценочной риторики; всё в настоящем времени, третьим лицом, кроме авторских формулировок и пунктов-заголовков в инфинитиве.
9. Пометка `(см. вопрос N)` стоит только в блоке «Требования», в ячейках таблиц и в строках «Кратко», подтверждённых помеченным требованием, — там, где спорное или недостающее значение всё же попало в текст. В прозаических разделах пометок нет. У каждой пометки есть вопрос с этим номером; у каждого вопроса — пометка в тексте либо указание пункта.
10. Нижние границы норм не добивались домыслом; строки таблиц под норму объёма не подпадают и не сокращались.
11. Признаки чужого профиля в артефакте отсутствуют: в компактной постановке нет «Цели», AS-IS и TO-BE; в детальной есть все обязательные разделы её шаблона. Признак вылез — перечитай «Калибровку профиля» и «Вопрос о профиле»: над рекомендацией эскалация работает, над выбором пользователя — нет, там расхождение уходит в сводку.

## Сводка в чат после записи

После записи выведи в чат короткую сводку (в файл она не пишется, максимум 11 строк):

```
Профиль: <компактный | детальный>, <выбран пользователем | рекомендация без ответа | задан входными данными> — <признак рубрики>
Файл: <фактический путь>, Status: <…>
Перенесено дословно: <разделы из авторского текста>
Дописано скиллом: <что именно, с указанием источника вывода>
AS-IS: включён / опущен — <причина>
Заменён прежний файл: да / нет — <что там было>
Вынесено в открытые вопросы: <перечень>
```

Так аналитик видит, где ты дописал от себя, и может это отклонить, а артефакт остаётся чистым.

Профиль выбран вопреки рекомендации, назван с отклонением («компактный, но с «Целью»») или постановка вышла за норму выбранного п

…(truncated)