answer-simple

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 (фиксирован)

Если черновик — утверждение/ответ с проблемами

Переформулировано: <BYTE-FAITHFUL версия в формате микроистории если применимо, иначе короткая faithful версия>

Найдено проблем:
- <Конкретная проблема 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 "внутренний код <match> без расшифровки".

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/<encoded-cwd>/memory/feedback_no-jargon-questions-to-user.md — historical context (пользовательский фидбек который привёл к созданию extension)
• Stop hook: wired in .claude-plugin/hooks.json; tool at tools/answer-simple/
• 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)