write-spec

Превращает расплывчатое намерение в бриф и требования REQ-XXX с проверяемыми критериями Given/When/Then. Использовать при новой фиче, изменении поведения доски или уточнении семантики конфликтов — до

SKILL.md

GitHub

write-spec — от намерения к спецификации

Цель: требование, по которому работу принимает машина. Если критерий нельзя превратить в тест — это не критерий.

Входы

  • docs/brief.md — зачем продукт, для кого, что НЕ делаем
  • docs/spec/requirements.md — существующие REQ
  • docs/spec/consistency-model.md — таблица полей и политик разрешения конфликта (§1.4), операции (§3)
  • docs/adr/ — принятые решения, противоречить им нельзя без нового ADR

Шаги

  1. Прочитать входы. Сформулировать намерение одной фразой: кто делает что и какой наблюдаемый результат.
  2. Если не хватает информации — задать пользователю не более 4 вопросов (AskUserQuestion). Обязательно выяснить:
    • какая роль выполняет действие и в какой фазе ретро оно разрешено;
    • что происходит при одновременном действии другого участника;
    • что явно не входит в требование.
  3. Если требование меняет продукт в целом — обновить docs/brief.md.
  4. Записать требование в docs/spec/requirements.md по шаблону ниже. ID — следующий свободный, ID никогда не переиспользуются; удалённое требование помечается ~~удалено~~ с причиной.
  5. Если требование вводит новое поле сущности — добавить строку в таблицу §1.4 consistency-model.md (Kind/Field/Значения/Политика разрешения: «все варианты» для текста или «победитель по метке» для остального). Конфликты между разными полями (например, place и group) не описываются отдельно: в модели каждое поле — своя ячейка со своим MV-регистром, они разрешаются независимо (см. consistency-model.md § 2). Если требование вводит новую сущность или операцию (не просто новое поле существующей) — обновить §3 (операции) и проверить, не нужно ли новое утверждение в §8 (инварианты).
  6. Изменение существующего REQ — запись в ## Changelog внизу файла: дата, REQ, что и почему.
  7. Итог: список новых/изменённых 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), а не реализацию.
  • Не придумывать поведение за пользователя: неясное — в раздел ## Открытые вопросы спецификации.