write-spec
Превращает расплывчатое намерение в бриф и требования REQ-XXX с проверяемыми критериями Given/When/Then. Использовать при новой фиче, изменении поведения доски или уточнении семантики конфликтов — до
SKILL.md.claude/skills/write-spec/SKILL.md
GitHubwrite-spec — от намерения к спецификации
Цель: требование, по которому работу принимает машина. Если критерий нельзя превратить в тест — это не критерий.
Входы
docs/brief.md— зачем продукт, для кого, что НЕ делаемdocs/spec/requirements.md— существующие REQdocs/spec/consistency-model.md— таблица полей и политик разрешения конфликта (§1.4), операции (§3)docs/adr/— принятые решения, противоречить им нельзя без нового ADR
Шаги
- Прочитать входы. Сформулировать намерение одной фразой: кто делает что и какой наблюдаемый результат.
- Если не хватает информации — задать пользователю не более 4 вопросов (AskUserQuestion). Обязательно выяснить:
- какая роль выполняет действие и в какой фазе ретро оно разрешено;
- что происходит при одновременном действии другого участника;
- что явно не входит в требование.
- Если требование меняет продукт в целом — обновить
docs/brief.md. - Записать требование в
docs/spec/requirements.mdпо шаблону ниже. ID — следующий свободный, ID никогда не переиспользуются; удалённое требование помечается~~удалено~~с причиной. - Если требование вводит новое поле сущности — добавить строку в таблицу §1.4
consistency-model.md(Kind/Field/Значения/Политика разрешения: «все варианты» для текста или «победитель по метке» для остального). Конфликты между разными полями (например,placeиgroup) не описываются отдельно: в модели каждое поле — своя ячейка со своим MV-регистром, они разрешаются независимо (см.consistency-model.md§ 2). Если требование вводит новую сущность или операцию (не просто новое поле существующей) — обновить §3 (операции) и проверить, не нужно ли новое утверждение в §8 (инварианты). - Изменение существующего REQ — запись в
## Changelogвнизу файла: дата, REQ, что и почему. - Итог: список новых/изменённых REQ и предложение запустить
/spec-to-tasks.
Шаблон
### REQ-012: Одновременное перемещение одного стикера
- **Зачем:** brief § Групповая работа
- **Роли / фазы:** participant, facilitator / group
- **Критерии приёмки:**
1. Given стикер S в колонке A, When участник U1 перемещает S в B, а U2 одновременно в C,
Then у всех участников S находится в одной и той же колонке, выбранной по max(lamport, actorId).
2. Given тот же сценарий, Then проигравшее перемещение присутствует в истории стикера.
- **Конкурентность:** consistency-model.md § 1.4 (поле `place`, победитель по метке), § 8 (I2.3)
- **Не входит:** анимация перемещения у других участников
Правила
- Запрещены непроверяемые слова без числа: «быстро», «удобно», «корректно», «сразу». Вместо «сразу» — «не позднее 500 мс в симуляторе без задержек».
- Критерий описывает наблюдаемое поведение (API, DOM, состояние после
materialize), а не реализацию. - Не придумывать поведение за пользователя: неясное — в раздел
## Открытые вопросыспецификации.