Обкатка скилла tasks на выдуманном проекте — консольные крестики-нолики на JavaScript, каталог заведён с нуля тем же скриптом. Форма вылезла раньше содержания, и правки все про неё. Заголовок отвечает на вопрос типа записи, и форм три: цель — утверждение о возможности, задача — глагол в неопределённой форме (допускается «не» перед ним), идея — назывное, без обещания. Причина не стилистическая: описательный заголовок называет состояние, а из состояния не видно, чего от работы ждут — «Ничья объявляется, пока клетки есть» одинаково читается как жалоба и как задание. Отсюда же разница индексов: роадмап — список возможностей, беклог — список работ, и перепутанные формы делают каждый похожим на другой. Механизировано ровно то, что механизируется: check считает заголовки, где первое слово не на -ть/-ти/-чь, и печатает число в блоке здоровья. Замечанием на файл нельзя — эвристика грубая, а на 97 записях двух живых проектов это поток одинаковых строк, после которого пропускают весь блок. Годность формулировки судит отдельный агент task-wording, а не чек-лист в скилле: сейчас формулировку пишет и проверяет один агент в одном контексте, а самопроверка текста слабее всего там, где формулировка казалась удачной при написании. Он ничего не правит — возвращает готовые формулировки, и заголовок с «зачем» показываются человеку, потому что по ним задачу выбирают. Ничего из того, что ловит tasks.py check, он не трогает намеренно: это был бы второй дом для правила. Заголовки секций — с прописной, после заголовка пустая строка, во всех индексах. Канонические имена стали Готово | Запланировано | Направления | Разработка (англ. Done | Planned | Directions | Tooling), сверка везде по нижнему регистру, так что старые индексы читаются по-прежнему. Отбивка живёт на записи, а не на вставке: через Plan.index проходит каждая правка индекса, а мест вставки три. Имя секции принадлежит заголовку индекса, файл на неё только ссылается. Это разрешает единственную неоднозначность починки — расхождение в одном регистре правится в пользу заголовка. Без него переезд на канон оставил бы «Готово» в роадмапе и «готово» в каждом файле цели, и свести это было бы некому. Регистр правится только у канонических секций: имена секций беклога выбирает проект. Обкатка нашла два дефекта, которых не находили ни линтеры, ни свои проверки. Вставка в пустую секцию съедала отбивку перед следующим заголовком — пропуск пустых строк теперь идёт только до первой непустой. Мета, разорванная пустой строкой, теряла поля молча: check видел лишь следствие («без рода работы») и советовал edit --kind, который дописывал второе такое же поле. Поле меты в теле стало ошибкой с названной причиной, и --fix её намеренно не чинит — какое из двух значений верное, знает человек. DECISIONS тема 20 (ЕЕЕ–ККК, следствия 82–85), changelog канона v3 пополнен двумя пунктами и двумя шагами переезда, TODO — два шага для healthlog и jellybit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
8.2 KiB
name, description
| name | description |
|---|---|
| init | Завести новый проект — сессия вопросов и ответов по свободному описанию замысла, из которой рождается первичная документация по канону av-dev: паспорт, CLAUDE.md с инвариантами и командами, модель угроз с периметром, первые цели в роадмапе и скелет остальных документов. Использовать, когда начинают новый проект с нуля, когда есть только текст «что мне нужно и почему» и надо превратить его в рабочую документацию, когда просят провести стартовое интервью по брифу. Проект, где документация уже как-то ведётся, переводит скилл canon. |
Заведение нового проекта
Вход — свободный текст «что мне нужно и почему». Выход — канон документов, с которого дальше работают все остальные скиллы.
Определение канона — канон. Читается до
первого вопроса: интервью идёт по слотам канона, а не по вкусу. Что класть в
каждый файл — скелеты; своей формы заглушки
не выдумывай, docs.py узнаёт только плейсхолдер оттуда.
Что init физически не может произвести
В новом репозитории нет кода, а architecture.md, database.md,
conventions/ и research/ выводятся из него. Их сочинение на старте — это
проектирование вперёд реальности, и оно протухнет раньше первой задачи.
Поэтому init заполняет то, что человек знает до первой строки кода:
| Заполняется | Остаётся скелетом с честной строкой |
|---|---|
passport.md |
architecture.md |
CLAUDE.md |
database.md |
security.md |
conventions/ |
docs/tasks/ROADMAP.md — первые цели |
research/, adr/ |
docs/.pm.json |
review.md — журнал пуст, настройка появится с первым ревью |
Честная строка информативна, а не «TBD»: «архитектуры пока нет: кода нет, заводится первой задачей». Проход читает её как факт.
Порядок интервью — зависимость, а не удобство
Каждый блок опирается на ответ предыдущего; переставлять нельзя.
- Цель и потребители. Ради чего это; кто пользуется — список закрытый, и он определяет, что считать нужным, а что интересным.
- Чем это НЕ является и мера успеха. Граница домена — критерий, по которому архитектурный проход потом судит о переносе понятия. Мера — по чему поймём, что удалось.
- Периметр и недоверенный вход. Открыт наружу или контур доверенный; что приходит извне и каким каналом; что чувствительнее чего. Контур ещё не развёрнут — назови оба периметра, целевой и сегодняшний.
- Стек, хранилище, необратимое. Чем пишем и почему; где данные; что в этом проекте нельзя откатить — деплой, выкладка наружу, перезапись данных.
- Чем краснеет гейт. Какие проверки обязательны; что красит безусловно; чего в гейте намеренно не будет и кто тогда это гоняет.
- Первые цели. Возможности приложения, а не задачи: три-пять целей в
Запланировано, каждая — ответ на «что приложение будет уметь», с обоснованием очереди прозой.
Как вести
- Не больше трёх вопросов за итерацию (
AskUserQuestion), рекомендация первым вариантом. Между итерациями применяй уже решённое. - Сперва вычитай ответы из брифа. Вопрос, ответ на который в тексте уже есть, задавать не надо — покажи своё прочтение и спроси, верно ли.
- Не выдумывай четыре вещи: периметр, что необратимо, измеренные числа и адресата дорогой проверки. Их из замысла не вывести. Не сказано — пиши «неизвестно» с пометкой, что ждёт ответа.
- Развилка замысла — человеку, механика — сама. Имена файлов, слаги, порядок строк не выносятся.
Порядок работы
- Прочитай бриф целиком. Выпиши, на какие блоки интервью ответ уже есть.
- Проведи интервью итерациями по ≤3 вопроса.
- Заведи
docs/.pm.jsonс текущей версией канона. - Напиши заполняемые документы. Бриф переезжает в
passport.mdи отдельным файлом не остаётся: два дома для одного замысла разойдутся на первом же уточнении. - Заведи скелет остальных по скелетам — каждый с честной строкой.
- Каталог задач и первые цели — вызови скилл
av-dev-pm:tasks: он владеет форматом целей и задач. docs.py checkиз скиллаcanon— до отсутствия дрейфа. Замечания о незаполненных плейсхолдерах остаются: их закрывает неinit, а работа.- Покажи человеку, что получилось, и отдельным списком — что выведено из брифа, что предположено, что осталось неизвестным. Правят по этим строкам.
Что дальше
- Содержимое канона по ходу разработки ведёт скилл
docs. - Раскладку проверяет
canon check. - Первую задачу берёт пайплайн проекта;
architecture.mdиconventions/наполняются его шагом синка, а не заранее.
Чего этот скилл не делает
- Не проектирует систему. Архитектура выводится из кода, а не наоборот.
- Не пишет код и не заводит сборку.
- Не переводит существующий проект — это
canon adopt. Признак: в репозитории уже есть документация или беклог в какой-то раскладке. - Не решает за человека, что важно: цель, границы и периметр — его ответы.