--- name: answer-simple description: > Аудит черновика на жаргон, внутренние коды, multi-select >3 опций и отсутствие микроистории. Триггеры (RU): "проверь черновик", "ревью ответа", "answer simple"; (EN): "audit draft", "check response", "answer-simple draft". Slash invocation `/answer-simple <черновик>` возвращает блоки "Переформулировано:" и "Найдено проблем:". Без аргумента — usage hint. allowed-tools: Read --- # Answer Simple — Draft Audit Skill ## Mission Skill дополняет always-apply правило `clear-questions-to-user.md` явным slash-command интерфейсом для аудита произвольного черновика. Правило работает молча перед каждым ответом агента; skill даёт on-demand аудит когда пользователь хочет явный feedback по конкретному тексту. Skill **не делает** runtime enforcement (Claude Code не имеет hook на финальный agent message). Он анализирует переданный текст и возвращает структурированный отчёт по 4 критериям. ## When invoked Активируйся когда: - Пользователь набирает `/answer-simple <черновик>` в чате - Пользователь говорит "проверь черновик", "ревью ответа", "audit this draft", "сделай audit", "answer-simple", "анализ читабельности" - Пользователь даёт текст и просит оценить читабельность / структуру / отсутствие жаргона ## ОБЯЗАТЕЛЬНЫЕ правила переформулировки ### Правило 1: BYTE-FAITHFUL — никакой выдумки Переформулировка использует **ТОЛЬКО** факты, явно присутствующие в исходном черновике. Запрещено: - Дофантазировать контекст (придумывать "STOP #3 в specs-workflow", "polymorphic FR", "контракт между FR-8 и FR-3", "блокирует переход", "прогон на реальной спеке" если этого нет в источнике) - Изобретать причины / цели / последствия которых нет в источнике - Добавлять детали из общих знаний о домене (даже если они правдоподобны и звучат разумно) - Расшифровывать внутренние коды конкретными значениями если значение не дано в источнике (не угадывай что "FR-12" — это "требование о покрытии вариантов" — это hallucination) - **Менять verb forms** (`добавить` → `добавлю`, `надо` → `требуется`) или сдвигать subject perspective (3rd person → 1st person) — это меняет authorship источника - **Менять quantifiers / precision** (`30 минут` → `примерно 30 минут`, `12 сервисов` → `около 12`) — это добавляет неопределённость которой нет в источнике - **Вводить implicit predicates** (добавлять `появилась`, `возникла`, `было сделано` если в источнике их нет) — это interpretation, не translation - **Семантически переводить file paths / proper nouns** в описательные обороты (`src/config/loader.ts` → "файл загрузчика конфига") — оставлять proper nouns byte-as-is Если в исходнике короткая фраза без контекста — переформулировка тоже короткая. Skill **не дополняет** фразу до полноценной микроистории если фактов для 5 опорных точек нет. **Антипаттерн (как НЕ надо):** Исходник: `"Готово. Обновил FR-12 и подключил VARIANT_COVERAGE category."` ❌ Плохой output (всё выделенное — выдумка): > "Ты просил доработать требование к покрытию вариантов. Я обновил это требование (FR-12) и подключил автоматическую проверку покрытия вариантов (audit category VARIANT_COVERAGE), **которая теперь срабатывает на STOP #3 в specs-workflow**. В результате теперь **при создании spec с polymorphic FR audit заблокирует переход, если матрица вариантов не построена**. Дальше — **прогон на реальной спеке**." Что выдумано: "ты просил доработать" (нет в источнике), "что именно делает категория", "STOP #3", "polymorphic FR", "блокировка перехода", "матрица вариантов", "прогон на реальной спеке". Всё это hallucination. ✅ Правильный output (faithful): > "Готовы изменения: обновлено требование (в проекте называется FR-12) и подключена категория проверок VARIANT_COVERAGE." Только то что явно есть в источнике — изменено требование, подключена категория. Контекста нет — не добавляем. ### Правило 2: Тип черновика — вопрос vs утверждение Перед переформулировкой определи тип источника: - **Утверждение / ответ / отчёт о работе** — переформулируй в формате микроистории (5 опорных точек) если в источнике достаточно фактов для всех 5; иначе — BYTE-FAITHFUL короткая версия - **Вопрос с опциями** — переформулируй как простой вопрос с **≤2 опций** на бытовом языке. НЕ натягивай микроисторию на вопрос. Если в исходнике >2 опций — это сама по себе проблема в "Найдено проблем:", а в "Переформулировано:" покажи как сокращённый вопрос выглядел бы (2 опции максимум, либо свободной формой) - **Однословный ответ** (типа "Готово.") — пропусти переформулировку, в Output отметь что текст слишком короткий для оценки структуры ### Правило 3: Empty invocation Если пользователь набрал `/answer-simple` без аргумента (пустая команда) — вернуть **usage hint** (см. формат ниже). НЕ генерить пустой output или Audit-блоки на пустоту. ### Правило 4: Consistency reformulation ↔ findings Если в "Переформулировано:" skill сам расшифровал термин inline (например, "AJV → валидатор JSON-схем"), finding для этого термина должен звучать **иначе**, чем для нерасшифрованных: - ❌ Self-contradiction: "Внутренний термин AJV без расшифровки" (skill же сам расшифровал — звучит будто не понял) - ✅ Consistent: "Термин AJV — в исходнике автора без объяснения; я добавил inline расшифровку, но в оригинале её нет" Finding описывает состояние **исходника**, не результат работы skill. Если расшифровка от skill — явно отмечай. ### Правило 5: Internal codes vs general technical vocabulary Различай **project-specific internal codes** (flag) и **общеупотребительную engineering лексику** (НЕ flag для технической аудитории). ✅ Flag (project-specific): - `FR-N`, `AC-N`, `Wave-N`, `PLUGIN-N`, `CHK-FR-N-NN`, `Issue [A-Z]`, `@feature1` — project numbering/tags - Имена spec'ов / file slugs если выглядят как placeholder: `foo-bar`, `baz-quux`, `answer-simple` - Custom audit categories / modules / abbreviations известные только в проекте: `VARIANT_COVERAGE`, `MATRIX_COMPLETE`, `gates` (если project-specific) ❌ НЕ flag (общий engineering vocabulary): - `staging`, `prod`, `dev`, `qa`, `prod deploy`, `migration`, `deploy`, `rollback` - `CI`, `CD`, `QPS`, `RPS`, `SLO`, `SLA`, `downtime`, `planned downtime` - `helper`, `validator`, `schema`, `module`, `service`, `component`, `library` - `merge`, `commit`, `PR`, `review`, `branch`, `hotfix` - `JSON`, `YAML`, `regex`, `API`, `SDK`, `CLI`, `JSON schema`, `JSON schema validation` **Здравый смысл**: если термин знаком engineer/dev/ops — НЕ flag. Если нужен domain-specific контекст проекта — flag. **Исключение**: если контекст явно non-technical reader (PM / маркетинг / бизнес) — flag wider vocabulary. ## Output format (фиксирован) ### Если черновик — утверждение/ответ с проблемами ``` Переформулировано: Найдено проблем: - <Конкретная проблема 1 с цитатой из source — категория: жаргон / внутренний код / multi-select / отсутствие связки> - <Конкретная проблема 2 ...> ``` ### Если черновик — вопрос с проблемами ``` Переформулировано: <простой вопрос на бытовом языке + ≤2 опции (или свободной формой)> Найдено проблем: - <как в случае выше> ``` ### Если черновик OK (никаких проблем) ``` Проблем не найдено Пройденные критерии: - Микроистория с 5 опорными точками присутствует (либо: критерий неприменим — текст слишком короткий) - Нет внутренних кодов без расшифровки - Multi-select ≤2 опций (либо отсутствует) - Причинно-следственные связки между предложениями (либо: критерий неприменим) ``` ### Если invocation без аргумента ``` Usage: /answer-simple <ваш черновик> Skill анализирует текст по 4 критериям (микроистория с 5 опорными точками, внутренние коды без расшифровки, multi-select >3 опций, причинно-следственные связки) и возвращает (a) BYTE-FAITHFUL переформулировку и (b) список найденных проблем. Примеры: - /answer-simple "Готово. Обновил FR-12." - /answer-simple "Wave 14 vs Wave 11 — Keep / Swap?" ``` ## 4 критерия проверки ### 1. Микроистория с 5 опорными точками Текст должен иметь narrative shape (см. правило `.claude/rules/answer-simple/clear-questions-to-user.md` step 4): 1. Откуда пришли — что было в прошлом turn / какой контекст 2. Что юзер сказал и что я понял — событие текущего turn 3. Что сделал и почему — действие + обоснование (не просто список изменений) 4. Где сейчас — состояние после действия 5. Что дальше — следующий логический шаг Связки обязательны: "потому что / поэтому / в итоге / дальше / после того как / в результате". **Детектор:** ищу хотя бы 3 из 5 опорных точек + минимум 2 причинно-следственные связки. Если меньше — flag "отсутствует структура микроистории". Если текст слишком короткий (1-2 слова) — критерий неприменим, не flag. ### 2. Внутренние коды без расшифровки Regex-кандидаты на внутренний код: - `Wave\s*\d+` (Wave 14, Wave-14) - `FR-?\d+` (FR-12, FR12) - `AC-?\d+` - `CHK-FR\d+-?\d*` - `Issue [A-Z]\b` (Issue B) - `@feature\d+` (если в prose, не в feature spec) - `PLUGIN\d+` - Уникальные library / API / service names без объяснения (e.g. "OpenRouter", "Reqnroll", "VARIANT_COVERAGE") **Детектор:** для каждого match проверь — есть ли расшифровка в скобках или предыдущем предложении? Если нет — flag "внутренний код `` без расшифровки". ### 3. Multi-select >3 опций Паттерн: вопрос (предложение с `?`) followed by bullet list (`-` / `*` / number) с >3 items, либо текстом с разделителем " / " содержащим >2 элементов. **Детектор:** если найден — flag "multi-select с N опциями (порог 2)". ### 4. Причинно-следственные связки Markers: "потому что", "поэтому", "в итоге", "дальше", "после того как", "из-за этого", "следовательно", "тогда", "в результате". **Детектор:** в тексте длиннее 3 предложений должно быть минимум 2 связки. Меньше — flag "отсутствует причинно-следственная структура". Для коротких текстов (1-3 предложения) — критерий неприменим. ## Example invocation 1 — жаргонный ВОПРОС **User input:** `/answer-simple "Wave 14 (gates+OpenRouter) ПЕРЕД Wave 11 — Keep / Swap / Parallel?"` **Skill output (Правило 2 — это вопрос с 3 опциями; BYTE-FAITHFUL — не додумываем что значат Wave 14/11):** ``` Переформулировано: У нас две большие фичи (в проекте их называют "Wave 14" и "Wave 11"). Что делать первым — Wave 14 или Wave 11? (если хочешь сокращённый вариант — "сделать первой одну из двух, какую?") Найдено проблем: - Внутренний код "Wave 14" без расшифровки — читатель не знает что это - Внутренний код "Wave 11" без расшифровки - Технический термин "gates" без объяснения - Технический термин "OpenRouter" без контекста (что это за сервис) - Multi-select с 3 опциями (Keep / Swap / Parallel) — превышение порога 2; сократи до 2 или дай выбор свободной формой ``` ## Example invocation 2 — короткий ОТЧЁТ с проблемами **User input:** `/answer-simple "Готово. Обновил FR-12 и подключил VARIANT_COVERAGE category."` **Skill output (BYTE-FAITHFUL — короткая faithful версия, не выдумываем "STOP #3" / "матрицу вариантов"):** ``` Переформулировано: Готовы изменения: обновлено требование (в проекте называется FR-12) и подключена категория проверок VARIANT_COVERAGE. Найдено проблем: - Внутренний код "FR-12" без расшифровки — читатель не знает что это за требование - Внутренний код "VARIANT_COVERAGE" без расшифровки — читатель не знает что это за категория - Отсутствует структура микроистории — нет "откуда пришли" (какой запрос), нет "что дальше" - Отсутствуют причинно-следственные связки между двумя изменениями ``` ## Example invocation 3 — чистый черновик **User input:** `/answer-simple "После того как ты сказал переделать правило на шаблон самопроверки, я переписал на 5 шагов — что понял, черновик, самооценка, шаблон ответа, переписать если не прошло. Сейчас правило в .claude/rules/answer-simple/. Дальше — применяю в каждом ответе."` **Skill output:** ``` Проблем не найдено Пройденные критерии: - Микроистория с 5 опорными точками присутствует (откуда: "ты сказал переделать"; что сделал: "переписал на 5 шагов"; где: ".claude/rules/answer-simple/"; дальше: "применяю в каждом ответе") - Нет внутренних кодов без расшифровки - Multi-select отсутствует - Причинно-следственная связка "После того как..." присутствует ``` ## Example invocation 4 — пустой invocation **User input:** `/answer-simple` **Skill output:** ``` Usage: /answer-simple <ваш черновик> Skill анализирует текст по 4 критериям (микроистория с 5 опорными точками, внутренние коды без расшифровки, multi-select >3 опций, причинно-следственные связки) и возвращает (a) BYTE-FAITHFUL переформулировку и (b) список найденных проблем. Примеры: - /answer-simple "Готово. Обновил FR-12." - /answer-simple "Wave 14 vs Wave 11 — Keep / Swap?" ``` ## Связанные артефакты - Always-apply rule: `.claude/rules/answer-simple/clear-questions-to-user.md` — full шаблон самопроверки, описание триггера инцидента, integration с octocode MCP - Memory: `~/.claude/projects//memory/feedback_no-jargon-questions-to-user.md` — historical context (пользовательский фидбек который привёл к созданию extension) - Extension manifest: `extensions/answer-simple/extension.json` - Spec: `.specs/answer-simple/` — full 4-phase spec с FR/NFR/AC/Design/TASKS ## Что skill НЕ делает - НЕ блокирует отправку финального agent message с проблемами (Claude Code не имеет PostUserMessage hook) - НЕ переписывает rule файлы автоматически (read-only через `allowed-tools: Read`) - НЕ отправляет черновик в внешние сервисы (no WebFetch, no network MCP, security NFR-Security в spec) - НЕ модифицирует memory автоматически (read-only) - **НЕ ДОФАНТАЗИРУЕТ контекст в переформулировке — только факты из исходного черновика (Правило 1 BYTE-FAITHFUL)**