json-normalizer

name	JSON Normalizer
description	Normalizes arbitrary text (requirements, tasks, descriptions) into a strict compact JSON format suitable for LLM pipeline processing. Use when you need to extract structured data from natural language: BRD, FRD, backlogs, Jira tasks, technical descriptions. Outputs only raw JSON with structure {data, errors, meta}, no surrounding text.

JSON Normalizer

Скилл преобразует произвольный текст (требования, задачи, описания) в строгий компактный JSON-формат для передачи между этапами LLM pipeline. Применяется к BRD/FRD документам, backlog задачам, Jira/Confluence тикетам и техническим описаниям.

Контракт вывода

Выводить ТОЛЬКО JSON — никакого текста до, после или вместо JSON. Никаких пояснений, заголовков, markdown-обёрток. Только JSON-объект.

Фиксированная структура ответа:

{
  "data": {},
  "errors": [],
  "meta": {
    "confidence": 0.0
  }
}

Разрешённые ключи в data

Использовать только эти ключи — никаких произвольных полей:

• br — бизнес-требования (business requirements), массив строк
• fr — функциональные требования (functional requirements), массив строк
• uc — use cases, массив кортежей [id, description, priority], где priority: "HIGH" | "MEDIUM" | "LOW"
• ent — сущности (entities), массив строк
• tasks — задачи, массив кортежей [id, description, priority]

Включать только те ключи, для которых в тексте есть данные. Пустые массивы не включать.

Правила структуры

1. Максимум 2 уровня вложенности в data
2. Использовать массивы вместо объектов там, где возможно
3. Короткие строки — без описательных абзацев, только суть
4. Нет дублей — одинаковые сущности или требования не повторять
5. Текст на языке оригинала входных данных

Правило UNKNOWN

Если данных недостаточно для заполнения поля — использовать строку "UNKNOWN". Никогда не угадывать и не домысливать значения.

Примеры применения:

• Время ответа не указано → "response time < UNKNOWN"
• Приоритет задачи не указан → "UNKNOWN" в поле priority
• ID не задан явно → генерировать короткий snake_case идентификатор из контекста

Правила заполнения errors

Массив строковых кодов. Включать код, если в тексте выявлена соответствующая проблема:

• "missing_kpi" — не указаны измеримые показатели (KPI, метрики)
• "missing_latency_definition" — не указано допустимое время ответа системы
• "ambiguous_requirement" — требование сформулировано неоднозначно или противоречиво
• "missing_actor" — не указан субъект действия (кто выполняет операцию)
• "missing_acceptance_criteria" — нет критериев приёмки
• "duplicate_detected" — обнаружены дублирующиеся требования во входных данных

Если проблем не обнаружено — оставлять пустой массив [].

Правила заполнения confidence

Числовое значение от 0.0 до 1.0 в поле meta.confidence:

• 0.0–0.3 — низкая: много неопределённостей, текст неполный или противоречивый
• 0.4–0.7 — средняя: основные данные присутствуют, но есть пробелы
• 0.8–1.0 — высокая: данные чёткие, полные, без существенных неопределённостей

Алгоритм нормализации

1. Прочитать входной текст целиком
2. Определить тип документа (BRD, задача, описание, тикет и т.д.)
3. Извлечь сущности по категориям: бизнес-требования, функциональные требования, use cases, задачи
4. Заполнить только те ключи data, для которых найдены данные
5. Выявить проблемы качества — заполнить errors
6. Оценить полноту и однозначность — выставить confidence
7. Вывести JSON без форматирования (компактный), без обёрток

Примеры

Пример 1: Use cases из описания

Вход:

Нужно чтобы пользователь мог искать документы и получать ответы

Выход:

{"data":{"uc":[["search_docs","поиск документов","HIGH"],["qa","ответы на вопросы","HIGH"]]},"errors":[],"meta":{"confidence":0.6}}

Пример 2: Неполное функциональное требование

Вход:

Система должна работать быстро и поддерживать фильтры

Выход:

{"data":{"fr":["поддержка фильтрации","время отклика системы < UNKNOWN"]},"errors":["missing_latency_definition"],"meta":{"confidence":0.5}}

Пример 3: Задачи из Jira

Вход:

PROJ-42: Добавить кнопку экспорта в PDF
Priority: Medium
Assignee: не назначен

Выход:

{"data":{"tasks":[["PROJ-42","добавить кнопку экспорта в PDF","MEDIUM"]]},"errors":[],"meta":{"confidence":0.85}}

Пример 4: BRD с несколькими категориями

Вход:

Платформа должна позволять менеджерам формировать отчёты по продажам.
Требуется интеграция с CRM. Время отклика — не более 2 секунд.
Пользователь должен иметь возможность экспортировать данные в Excel.

Выход:

{"data":{"br":["менеджеры формируют отчёты по продажам"],"fr":["интеграция с CRM","время отклика < 2s","экспорт данных в Excel"],"ent":["менеджер","отчёт","CRM"]},"errors":[],"meta":{"confidence":0.85}}

Пример 5: Размытое требование с несколькими ошибками

Вход:

Система должна масштабироваться и обеспечивать высокую доступность при нагрузке

Выход:

{"data":{"fr":["масштабируемость системы","высокая доступность"]},"errors":["missing_sla_definition","missing_load_metrics","ambiguous_requirement"],"meta":{"confidence":0.3}}

Критические ограничения

• Никогда не выводить текст вне JSON-объекта
• Никогда не оборачивать вывод в markdown-блоки (json ... )
• Никогда не добавлять пояснения до или после JSON
• Никогда не изменять структуру верхнего уровня (data, errors, meta обязательны)
• Никогда не добавлять ключи в data, кроме разрешённых (br, fr, uc, ent, tasks)
• При любой неопределённости использовать "UNKNOWN", не домысливать

Назначение в pipeline

Скилл является базовым слоем нормализации для:

• Multi-agent систем (передача структурированных данных между агентами)
• RAG pipeline (индексация требований)
• Автоматизации аналитики требований