KIRO Spec Generator (Python)

Что делает этот Skill

Генерирует полную KIRO Specification Triad — три взаимосвязанных markdown файла, которые формируют комплексную спецификацию функции:

•requirements.md - ЧТО делать (User Stories + Acceptance Criteria)
•design.md - КАК делать (Architecture, Components, Interfaces)
•tasks.md - В КАКОМ ПОРЯДКЕ (TDD Red-Green-Refactor iterations)

Технологический стек

•Язык: Python 3.10+
•Тестирование: pytest + pytest-bdd (Gherkin сценарии)
•Async: asyncio, asyncpg, aiohttp
•Браузер: Playwright Python
•БД: PostgreSQL
•Контейнеры: Docker Compose, testcontainers-python
•Модели данных: dataclass или Pydantic

Предварительные требования

•Целевая директория: .kiro/specs/<spec-name>/
•Чёткое понимание функции для спецификации
•Знание связанных систем/компонентов

Быстрый старт

Создание спецификации

bash

# 1. Создать директорию спецификации
mkdir -p .kiro/specs/<feature-name>

# 2. Сгенерировать три файла (Claude создаст их)
# Просто опишите вашу функцию, и этот skill создаст:
# - requirements.md
# - design.md
# - tasks.md

Примеры промптов

Агент понимает естественный русский язык:

code

"нужны спеки для парсера каталога"
"сделай спецификацию для системы tracking"
"хочу документацию по API интеграции"
"давай напишем требования для агента"

🔄 Интерактивный Workflow (4 ОБЯЗАТЕЛЬНЫХ СТОПА!)

КРИТИЧНО: Агент ОБЯЗАН останавливаться и ждать подтверждения на КАЖДОМ этапе!

Поток работы

code

1. Пользователь: "мне нужны спеки для фичи X" (естественный язык)

2. Агент: ЭТАП ИССЛЕДОВАНИЯ
   - Исследует проект (паттерны, структуру)
   - Показывает находки
   - СТОП #1 → "Готов приступить к генерации requirements.md?"

3. Пользователь: "да, давай"

4. Агент: ЭТАП REQUIREMENTS
   - Создаёт requirements.md
   - СТОП #2 → "Готов requirements.md. Посмотри, всё ли ок? Можно к design.md?"

5. Пользователь: "ок" / "поправь вот это..."

6. Агент: ЭТАП DESIGN
   - Создаёт design.md
   - СТОП #3 → "Готов design.md. Проверь архитектуру. Можно к tasks.md?"

7. Пользователь: "давай"

8. Агент: ЭТАП TASKS
   - Создаёт tasks.md
   - СТОП #4 → "Все спеки готовы! Проверь финальный результат."

СТОП #1: После исследования проекта

code

Агент: "📋 Исследовал проект:
- Нашёл conftest.py с 5 fixtures
- Паттерн тестов: pytest-bdd + async
- Fixtures: db_pool, browser, parser_context
- Feature файлы: 3 в tests/features/

Готов приступить к генерации requirements.md?"

СТОП #2: После создания requirements.md

⚠️ ОБЯЗАТЕЛЬНО запустить валидацию:

bash

python .claude/skills/kiro-spec-generator-python/scripts/validate_kiro_spec.py \
  .kiro/specs/{SPEC_NAME}/ --format short

code

Агент: "✅ Создал requirements.md
- 12 требований с User Stories
- 47 Acceptance Criteria в формате WHEN/SHALL
- Секция "Существующая реализация" с fixtures

🔍 **Результат валидации:**
📋 requirements.md
  ✅ Cross-Reference Header found
  ✅ REQ-ID format: 12 requirements
  ⚠️ WARNING: NFR section missing

Посмотри файл. Исправить warnings? Можно к design.md?"

СТОП #3: После создания design.md

⚠️ ОБЯЗАТЕЛЬНО запустить валидацию:

bash

python .claude/skills/kiro-spec-generator-python/scripts/validate_kiro_spec.py \
  .kiro/specs/{SPEC_NAME}/ --format short

code

Агент: "✅ Создал design.md
- Component diagram
- Sequence diagram для happy path
- 6 компонентов с интерфейсами
- Risk Register

🔍 **Результат валидации:**
🏗️ design.md
  ✅ Cross-Reference Header found
  ✅ Component anchors: 6 found
  ✅ Risk Register present

Проверь архитектуру. Можно к tasks.md?"

СТОП #4: После создания tasks.md (ФИНАЛЬНАЯ ВАЛИДАЦИЯ)

🚨 КРИТИЧНО: Запустить ПОЛНУЮ валидацию с cross-file проверками:

bash

python .claude/skills/kiro-spec-generator-python/scripts/validate_kiro_spec.py \
  .kiro/specs/{SPEC_NAME}/ --format full

code

Агент: "✅ Создал tasks.md
- 5 TDD итераций
- 23 задачи с чекбоксами
- Red-Green-Refactor структура

🔍 **ФИНАЛЬНАЯ ВАЛИДАЦИЯ (--format full):**

📋 requirements.md
  ✅ Cross-Reference Header found
  ✅ REQ-ID format: 12 requirements
  ✅ Stakeholders + RACI present
  ✅ NFR section present

🏗️ design.md
  ✅ Cross-Reference Header found
  ✅ Component anchors: 6 found
  ✅ Risk Register present

✅ tasks.md
  ✅ Cross-Reference Header with STOP-rule found
  ✅ Iterations: 5 found
  ✅ Task anchors: 23 found
  ✅ 📋 REQ links present
  ✅ 🏗️ DESIGN links present

🔗 cross-file
  ✅ All internal anchors resolved
  ✅ REQ-ID consistency OK

─────────────────────────────────
SUMMARY: 0 errors, 0 warnings, 2 info
─────────────────────────────────

Все спеки готовы и валидация пройдена! ✅"

❌ Если валидация показала ERRORS:

•Агент ОБЯЗАН исправить ошибки ПЕРЕД показом результата пользователю
•После исправления — запустить валидацию повторно
•Показать пользователю только после 0 errors

Правила Workflow

•❌ НИКОГДА не создавать несколько файлов за один проход
•❌ НИКОГДА не переходить к следующему этапу без явного "ок" / "да" / "давай"
•❌ НИКОГДА не показывать результат пользователю без запуска валидации
•✅ ВСЕГДА запускать валидационный скрипт после создания КАЖДОГО файла
•✅ ВСЕГДА показывать результат валидации пользователю
•✅ ВСЕГДА исправлять ERRORS перед показом результата
•✅ ВСЕГДА показывать краткое резюме что сделано
•✅ При правках — показывать что изменилось

🧠 Умное распознавание промптов (БЕЗ SLASH-КОМАНД!)

Агент сам понимает намерение из естественного русского языка.

Создание спеков

code

"нужны спеки для парсера"
"сделай спецификацию для API"
"хочу документацию по tracking"
"давай напишем требования для агента"
"надо задокументировать фичу X"

Чтение и анализ

code

"что там в спеках?"
"покажи текущие требования"
"какой статус по задачам?"
"сколько осталось?"
"что уже сделано?"
"прочитай design"

Редактирование

code

"обнови requirements"
"добавь требование про валидацию"
"поправь в design секцию архитектуры"
"убери лишнее из tasks"
"измени формулировку"
"дополни спеки"

Трекинг прогресса

code

"сделал первый пункт"
"закончил с fixtures"
"итерация 2 готова"
"можно закрыть задачу про..."
"отметь выполненным"

Распознавание контекста

code

"продолжай" → следующий этап workflow
"всё ок" / "ок" / "да" → подтверждение
"давай дальше" → переход к следующему файлу
"стоп" / "подожди" → пауза

🔍 Умный поиск и отметка задач

При отметке задач агент использует умный поиск с подтверждением:

Шаг 1: Поиск по ключевым словам

code

Пользователь: "закончил с db_pool fixture"
Агент ищет в tasks.md задачи содержащие "db_pool", "fixture", "database"

Шаг 2: Показать найденное

code

Агент: "Нашёл подходящие задачи:
1. [ ] 1.3 Настроить db_pool fixture для тестов
2. [ ] 2.4 Реализовать проверку через database

Какую отметить выполненной?"

Шаг 3: Подтверждение

code

Пользователь: "первую"
Агент: "✅ Отметил '1.3 Настроить db_pool fixture' как выполненную"

Правила поиска

•✅ ВСЕГДА показывать найденные задачи перед изменением
•✅ ВСЕГДА спрашивать подтверждение
•✅ Если найдено несколько - дать выбор
•❌ НИКОГДА не менять задачу без подтверждения

🧪 BDD/TDD/DDD База знаний

Этот skill знает паттерны Python/pytest-bdd проектов и ОБЯЗАН их учитывать при генерации.

Структура тестов проекта

code

project/
├── src/                           # Исходный код
│   ├── parser/
│   ├── database/
│   └── ...
├── tests/
│   ├── conftest.py                # Общие fixtures
│   ├── features/                  # Gherkin сценарии
│   │   └── *.feature
│   ├── step_defs/                 # Step Definitions
│   │   └── test_*_steps.py
│   └── fixtures/                  # Дополнительные fixtures
│       └── *.py
└── docker-compose.yml             # Тестовая инфраструктура

Паттерны .feature файлов

•Язык: # language: ru (опционально)
•Теги: @PAR @E2E @REQ-PAR-001 @critical
•Background: инфраструктурная подготовка
•Сценарии: Happy path + Edge cases + Error cases

Паттерны Step Definitions (pytest-bdd)

python

# tests/step_defs/test_parser_steps.py
import pytest
from pytest_bdd import given, when, then, scenario, parsers

@pytest.fixture
def parser_context():
    return {"items": [], "page": None}

@given("страница каталога загружена")
def page_loaded(browser, parser_context):
    parser_context["page"] = browser.goto("https://example.com")

@when("парсер извлекает товары")
def parse_items(parser_context, catalog_parser):
    parser_context["items"] = catalog_parser.parse(parser_context["page"])

@then(parsers.parse("найдено более {count:d} товаров"))
def check_items_count(parser_context, count):
    assert len(parser_context["items"]) > count

Паттерны Fixtures (conftest.py)

python

# tests/conftest.py
import pytest
import asyncio
from asyncpg import create_pool

@pytest.fixture(scope="session")
def event_loop():
    loop = asyncio.get_event_loop_policy().new_event_loop()
    yield loop
    loop.close()

@pytest.fixture(scope="session")
async def db_pool():
    pool = await create_pool(dsn="postgresql://...")
    yield pool
    await pool.close()

@pytest.fixture
async def db(db_pool):
    async with db_pool.acquire() as conn:
        async with conn.transaction():
            yield conn
            # Автоматический rollback после теста

Паттерны Browser Fixtures (Playwright)

python

@pytest.fixture(scope="session")
def browser():
    from playwright.sync_api import sync_playwright
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        yield browser
        browser.close()

@pytest.fixture
def page(browser):
    page = browser.new_page()
    yield page
    page.close()

Паттерны Contexts (Состояние между шагами)

В pytest-bdd состояние передаётся через fixtures. Основные паттерны:

python

# tests/conftest.py

@pytest.fixture
def scenario_context():
    """Состояние текущего сценария (аналог ScenarioContext в Reqnroll)"""
    return {}

@pytest.fixture(scope="module")
def domain_context():
    """Состояние домена между сценариями (аналог {Domain}TestContext)"""
    return {
        "items": [],
        "responses": [],
        "last_error": None
    }

@pytest.fixture(scope="session")
def infrastructure_context(db_pool, browser):
    """Инфраструктурный контекст для всех тестов"""
    return {
        "db": db_pool,
        "browser": browser,
        "base_url": "http://localhost:8000"
    }

Использование в step definitions:

python

@given("пользователь авторизован")
def user_logged_in(scenario_context, browser):
    scenario_context["user"] = {"id": 1, "name": "test"}
    scenario_context["session"] = browser.new_context()

@when("пользователь делает запрос")
def make_request(scenario_context):
    # Используем данные из предыдущего шага
    user = scenario_context["user"]
    scenario_context["response"] = api.get(f"/users/{user['id']}")

@then("ответ содержит данные пользователя")
def check_response(scenario_context):
    assert scenario_context["response"]["name"] == scenario_context["user"]["name"]

Паттерны Hooks (pytest hooks)

Hooks управляют lifecycle тестов. В pytest это делается через специальные функции:

python

# tests/conftest.py

def pytest_configure(config):
    """Глобальная инициализация перед всеми тестами"""
    # Регистрация кастомных маркеров
    config.addinivalue_line("markers", "PAR: Parser tests")
    config.addinivalue_line("markers", "DB: Database tests")

@pytest.hookimpl(tryfirst=True)
def pytest_runtest_setup(item):
    """Перед каждым тестом"""
    # Seed data, cleanup, etc.
    pass

def pytest_runtest_teardown(item):
    """После каждого теста"""
    # Cleanup resources
    pass

def pytest_sessionfinish(session, exitstatus):
    """После всех тестов"""
    # Final cleanup, reports
    pass

# Для pytest-bdd специфичные hooks
@pytest.fixture(autouse=True)
def cleanup_after_scenario(request, db):
    """Cleanup после каждого сценария"""
    yield
    # Rollback или truncate
    db.execute("ROLLBACK")

При генерации спеков

ОБЯЗАТЕЛЬНО перед созданием requirements.md:

•Найти существующие .feature файлы
•Изучить паттерны Step Definitions
•Проверить какие Fixtures уже есть в conftest.py
•Найти существующие Hooks (pytest hooks, cleanup fixtures)
•Понять структуру Contexts (как передаётся состояние)
•ПОКАЗАТЬ находки пользователю
•СПРОСИТЬ готов ли к генерации

📋 Исследование проекта перед генерацией (РАСШИРЕННОЕ)

КРИТИЧНО: Перед созданием спецификаций агент ОБЯЗАН провести глубокое исследование проекта. Это предотвращает дублирование кода и позволяет переиспользовать существующую инфраструктуру.

Чеклист исследования (ОБЯЗАТЕЛЬНЫЙ)

Агент ОБЯЗАН выполнить ВСЕ пункты и показать результаты пользователю:

1️⃣ Тестовая инфраструктура (Fixtures)

Что искать: conftest.py, fixtures/*.py, @pytest.fixture

Зачем: Fixtures — основа тестовой инфраструктуры. Они управляют внешними зависимостями (Docker, БД, браузер). Создание дубликатов fixtures — критическая ошибка.

Как использовать в спеках:

•В requirements.md → секция "Тестовая инфраструктура" в глоссарии
•В design.md → компонент Fixtures в Architecture diagram
•В tasks.md → пометка "REUSE" вместо "CREATE"

Что показать:

code

📦 Fixtures (ВСЕ найденные):
| Файл | Fixture | Scope | Назначение | Статус |
|------|---------|-------|------------|--------|
| conftest.py | db_pool | session | PostgreSQL connection pool | ✅ ГОТОВ |
| conftest.py | browser | session | Playwright browser | ✅ ГОТОВ |
| conftest.py | page | function | Browser page | ✅ ГОТОВ |
| fixtures/parser.py | catalog_parser | function | Parser instance | ✅ ГОТОВ |

2️⃣ Step Definitions (Given/When/Then)

Что искать: test_*_steps.py, step_defs/*.py

Зачем: Step definitions часто УЖЕ РЕАЛИЗОВАНЫ для смежных фич. Переиспользование экономит время и обеспечивает консистентность.

Как использовать в спеках:

•В requirements.md → секция "Уже реализованные Steps" с таблицей
•В design.md → компонент с пометкой "✅ РЕАЛИЗОВАНО (N строк)"
•В tasks.md → задачи помечаются "SKIP" если step уже есть

Что показать:

code

🔧 Step Definitions:
| Файл | Строк | Домен | Статус |
|------|-------|-------|--------|
| test_parser_steps.py | 150 | Parser | ✅ ГОТОВ |
| test_db_steps.py | 80 | Database | ✅ Переиспользовать |
| test_api_steps.py | 200 | API | ✅ Переиспользовать |

ВАЖНО: Для каждого Steps файла с >50 строк — показать список реализованных Given/When/Then!

3️⃣ Hooks (Setup/Teardown)

Что искать: conftest.py (функции pytest_*, @pytest.fixture(autouse=True))

Зачем: Hooks управляют lifecycle тестов. Они содержат критическую логику инициализации (seed data, cleanup, markers).

Как использовать в спеках:

•В requirements.md → глоссарий "Hooks (реализованы)"
•В design.md → секция "Test Lifecycle"
•В tasks.md → указание какой Hook использовать

Что показать:

code

🪝 Hooks:
| Функция/Fixture | Файл | Назначение |
|-----------------|------|------------|
| pytest_configure | conftest.py | Регистрация маркеров |
| cleanup_after_scenario | conftest.py | Rollback после теста |
| seed_test_data | conftest.py | Начальные данные |

4️⃣ Feature файлы (Gherkin)

Что искать: *.feature в директории тестов

Зачем: Существующие features показывают принятые паттерны (теги, язык, структура).

Как использовать в спеках:

•В tasks.md → копировать структуру из существующих features
•Теги, язык, Background — всё должно быть консистентно

Что показать:

code

📁 Feature файлы:
| Файл | Сценариев | Теги | Background |
|------|-----------|------|------------|
| parser.feature | 5 | @PAR @E2E | Given db готова And browser запущен |
| api.feature | 3 | @API @integration | Given server running |

5️⃣ Background Steps (Shared Setup)

Что искать: Background секции в .feature файлах, shared fixtures

Зачем: Background steps выполняются перед КАЖДЫМ сценарием. Их переиспользование критично для консистентности.

Что показать:

code

📋 Background Steps (готовые):
- Given база данных запущена
- And браузер инициализирован
- And парсер настроен

6️⃣ Существующие модули (Reuse Candidates)

Что искать: src/**/*.py, классы и функции в основном проекте

Зачем: Бизнес-логика часто уже реализована. Расширение существующих модулей лучше создания новых.

Как использовать в спеках:

•В requirements.md → "Переиспользование кода"
•В design.md → "REUSE" vs "NEW" в компонентах
•В tasks.md → "расширить" вместо "создать"

Формат вывода исследования (ОБЯЗАТЕЛЬНЫЙ)

code

## 📋 Результаты исследования проекта

### 📦 Тестовая инфраструктура

**Fixtures (все):**
| Файл | Fixture | Scope | Назначение | Статус |
|------|---------|-------|------------|--------|
| ... | ... | ... | ... | ✅ ГОТОВ / ⏳ TODO |

**🪝 Hooks:**
| Функция/Fixture | Файл | Назначение |
|-----------------|------|------------|
| pytest_configure | conftest.py | Маркеры |
| cleanup_after_scenario | conftest.py | Rollback |

**Background Steps (готовые):**
- Given ...
- And ...

### 🔧 Step Definitions

| Файл | Строк | Статус | Реализованные шаги |
|------|-------|--------|-------------------|
| test_xxx_steps.py | 150 | ✅ ГОТОВ | @given("..."), @when("...") |

### 📁 Feature файлы

| Файл | Сценариев | Паттерн |
|------|-----------|---------|
| parser.feature | 5 | Background + async |

### 🔄 Модули для переиспользования

| Модуль | Назначение | Действие |
|--------|------------|----------|
| src/parser/catalog.py | Парсинг каталога | РАСШИРИТЬ |
| src/database/repository.py | SQL операции | REUSE |

---

**Готов приступить к генерации requirements.md?**

Правила исследования

•❌ НИКОГДА не пропускать этап исследования
•❌ НИКОГДА не показывать только часть fixtures/steps
•✅ ВСЕГДА показывать ВСЕ найденные файлы с количеством строк
•✅ ВСЕГДА указывать статус (ГОТОВ / TODO / REUSE)
•✅ ВСЕГДА показывать реализованные Given/When/Then для крупных Steps файлов
•✅ При наличии >100 строк в Steps файле — обязательно прочитать и показать ключевые методы

🤖 Автоматическое сканирование инфраструктуры

Для ускорения этапа исследования доступен скрипт автоматического сканирования:

bash

python .claude/skills/kiro-spec-generator-python/scripts/scan_test_infrastructure.py \
  <путь_к_проекту>

Пример:

bash

python .claude/skills/kiro-spec-generator-python/scripts/scan_test_infrastructure.py \
  /path/to/my-parser

Что находит скрипт:

•📦 Все fixtures из conftest.py и fixtures/*.py
•🔧 Все step definitions с подсчётом строк и извлечением @given/@when/@then
•🪝 Все pytest hooks (pytest_* функции, @pytest.fixture(autouse=True))
•📁 Все .feature файлы с Background steps и количеством сценариев
•🔄 Модули из src/ для переиспользования

Форматы вывода:

•--format markdown (по умолчанию) — готовый markdown для СТОП #1
•--format json — JSON для программной обработки

Рекомендуемый workflow:

•Запустить скрипт для получения базового отчёта
•Прочитать крупные Steps файлы (>50 строк) для деталей
•Дополнить отчёт вручную если нужно
•Показать результат пользователю на СТОП #1

🔗 Связывание файлов (Cross-Reference & Traceability)

КРИТИЧНО: Все три файла спецификации ДОЛЖНЫ быть связаны между собой для ограничения галлюцинаций и допущений агента-исполнителя. Не должно быть дубликровния одной и той же информации и противоречий

Два уровня связывания

Уровень 1: Cross-Reference Header (в начале каждого файла)

Каждый файл спецификации ОБЯЗАН содержать секцию связей сразу после заголовка:

В requirements.md:

markdown

## 📎 Связанные документы

| Файл | Роль | Когда обращаться |
|------|------|------------------|
| [design.md](./design.md) | КАК реализовать | При вопросах об архитектуре |
| [tasks.md](./tasks.md) | В КАКОМ ПОРЯДКЕ | При планировании работы |

> ⚠️ **ИСТОЧНИК ИСТИНЫ**: Этот файл определяет ЧТО делать.
> Любая реализация ДОЛЖНА соответствовать требованиям отсюда.

В design.md:

markdown

## 📎 Связанные документы

| Файл | Роль | Когда обращаться |
|------|------|------------------|
| [requirements.md](./requirements.md) | ЧТО реализовать | При проверке соответствия требованиям |
| [tasks.md](./tasks.md) | В КАКОМ ПОРЯДКЕ | При планировании работы |

> ⚠️ **АРХИТЕКТУРНЫЕ ОГРАНИЧЕНИЯ**: Компоненты и интерфейсы из этого файла ФИКСИРОВАНЫ.
> Изменения архитектуры требуют согласования.

В tasks.md:

markdown

## 📎 Связанные документы

| Файл | Роль | ⚠️ ОБЯЗАТЕЛЬНО |
|------|------|----------------|
| [requirements.md](./requirements.md) | ЧТО реализовать | Читать ПЕРЕД каждой задачей |
| [design.md](./design.md) | КАК реализовать | Сверять архитектуру при реализации |

> 🛑 **СТОП-ПРАВИЛО**: НЕ НАЧИНАЙ задачу, пока не прочитал:
> 1. Соответствующие Requirements (REQ-X.Y)
> 2. Связанные компоненты в Design (DESIGN-ComponentName)

Уровень 2: Inline Traceability Tags (в каждой задаче)

Каждая задача в tasks.md ОБЯЗАНА содержать ссылки на требования и дизайн:

markdown

### 🔴 RED (Test)
- [ ] 1.1 Написать тест парсинга каталога {#task-11}
  - **📋 REQ**: [REQ-PAR-001](./requirements.md#req-par-001), [REQ-PAR-002](./requirements.md#req-par-002)
  - **🏗️ DESIGN**: [CatalogParser](./design.md#1-catalog-parser), [Parse Sequence](./design.md#sequence-parse)
  - **⚠️ ОГРАНИЧЕНИЯ**:
    - Использовать BeautifulSoup (см. design.md)
    - Селекторы строго по REQ-PAR-001
  - Создать feature файл с тегами @PAR @E2E
  - Добавить Background с инфраструктурой

Якоря для ссылок (Anchor IDs)

В requirements.md — якоря на каждое требование:

markdown

### Требование REQ-PAR-001: Парсинг каталога {#req-par-001}
...
#### Acceptance Criteria {#req-par-001-ac}
1. WHEN страница загружена, THE система SHALL извлечь товары {#req-par-001-1}
2. WHEN товар найден, THE система SHALL сохранить в БД {#req-par-001-2}

В design.md — якоря на компоненты и диаграммы:

markdown

### 1. CatalogParser {#1-catalog-parser}
...
### Sequence Diagram: Parse Flow {#sequence-parse}

Обратные ссылки (Backlinks)

В requirements.md и design.md добавлять ссылки на реализующие задачи:

markdown

### Требование REQ-PAR-001: Парсинг каталога {#req-par-001}

**User Story:** Как пользователь...

**Acceptance Criteria:**
1. WHEN страница загружена...
2. WHEN товар найден...

**🔗 Реализация:**
- [Task 1.1](./tasks.md#task-11) - Тест парсинга
- [Task 1.3](./tasks.md#task-13) - Имплементация CatalogParser

Правила связывания

При создании requirements.md:

•✅ Добавить Cross-Reference Header
•✅ Добавить якоря {#req-domain-nnn} на каждое требование
•✅ Добавить якоря {#req-domain-nnn-m} на каждый AC

При создании design.md:

•✅ Добавить Cross-Reference Header
•✅ Добавить якоря {#n-component-name} на каждый компонент
•✅ Добавить якоря {#sequence-name} на каждую диаграмму
•✅ В Correctness Properties ссылаться на Requirements

При создании tasks.md:

•✅ Добавить Cross-Reference Header со СТОП-правилом
•✅ Каждая задача ОБЯЗАНА иметь секции 📋 REQ и 🏗️ DESIGN
•✅ Каждая задача МОЖЕТ иметь секцию ⚠️ ОГРАНИЧЕНИЯ
•✅ Добавить якоря {#task-xy} на каждую задачу

После создания всех файлов:

•✅ Добавить Backlinks в requirements.md (какие задачи реализуют)
•✅ Добавить Backlinks в design.md (какие задачи используют компонент)

Пример полной связки

requirements.md:

markdown

### Требование REQ-PAR-001: Парсинг каталога {#req-par-001}

**User Story:** Как пользователь, я хочу парсить каталог...

#### Acceptance Criteria {#req-par-001-ac}
1. WHEN страница загружена, THE система SHALL найти все товары {#req-par-001-1}
2. WHEN товар найден, THE система SHALL извлечь title и price {#req-par-001-2}
3. WHEN данные извлечены, THE система SHALL сохранить в БД {#req-par-001-3}

**🔗 Реализация:** [Task 1.1](./tasks.md#task-11), [Task 1.3](./tasks.md#task-13)
**🏗️ Архитектура:** [CatalogParser](./design.md#1-catalog-parser)

design.md:

markdown

### 1. CatalogParser {#1-catalog-parser}

**Validates:** [REQ-PAR-001](./requirements.md#req-par-001), [REQ-PAR-001-1](./requirements.md#req-par-001-1)

**Purpose:** Парсинг страницы каталога через BeautifulSoup

**🔗 Реализация:** [Task 1.3](./tasks.md#task-13), [Task 1.4](./tasks.md#task-14)

tasks.md:

markdown

- [ ] 1.1 Написать E2E тест парсинга каталога {#task-11}
  - **📋 REQ**: [REQ-PAR-001-1](./requirements.md#req-par-001-1), [REQ-PAR-001-2](./requirements.md#req-par-001-2)
  - **🏗️ DESIGN**: [CatalogParser](./design.md#1-catalog-parser), [Parse Sequence](./design.md#sequence-parse)
  - **⚠️ ОГРАНИЧЕНИЯ**:
    - Селекторы строго из design.md
    - BeautifulSoup + lxml backend
  - Создать файл `tests/features/catalog.feature`
  - Добавить сценарий Happy Path

Визуализация связей

code

┌─────────────────────────────────────────────────────────────────────┐
│  requirements.md                                                      │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │ ### REQ-PAR-001 {#req-par-001}                               │   │
│  │ **🔗 Реализация:** [Task 1.1](./tasks.md#task-11)            │   │
│  │ **🏗️ Архитектура:** [CatalogParser](./design.md#1-parser)   │   │
│  └──────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘
                         │                          │
                         ▼                          ▼
┌───────────────────────────────┐    ┌───────────────────────────────┐
│  design.md                    │    │  tasks.md                     │
│  ┌─────────────────────────┐  │    │  ┌─────────────────────────┐  │
│  │ ### CatalogParser       │  │    │  │ - [ ] 1.1 Task {#task-11}│  │
│  │ {#1-catalog-parser}     │  │    │  │ **📋 REQ:** [REQ-PAR-001]│  │
│  │ **Validates:** [REQ-001]│◄─┼────┼──│ **🏗️ DESIGN:** [Parser] │  │
│  │ **🔗 Реализация:**      │──┼────┼─►│ **⚠️ ОГРАНИЧЕНИЯ:**...   │  │
│  │   [Task 1.1, 1.3]       │  │    │  └─────────────────────────┘  │
│  └─────────────────────────┘  │    │                               │
└───────────────────────────────┘    └───────────────────────────────┘

📚 PMBOK/BABOK Интеграция

Skill интегрирует лучшие практики из PMBOK (Project Management Body of Knowledge) и BABOK (Business Analysis Body of Knowledge) для обеспечения полной трассируемости требований от бизнес-потребности до реализации.

Обзор добавленных практик

PMBOK/BABOK концепция	Реализация в KIRO
Requirements Traceability	Теги `@REQ-XXX-NNN` в сценариях и tasks.md
RTM (Traceability Matrix)	Секция в requirements.md
Business Context	Расширенный Feature header в design.md
Definition of Done	Секция в tasks.md
Risk Management	Risk Register + Risk-based сценарии
NFR	Секция Non-Functional Requirements
Stakeholder Management	Stakeholders + RACI Matrix

REQ-ID система (Requirements Identification)

Каждое требование получает уникальный идентификатор.

Формат: REQ-{DOMAIN}-{NNN}

Домен	Код	Пример
Parser	PAR	REQ-PAR-001
Database	DB	REQ-DB-001
API	API	REQ-API-001
Agent	AGT	REQ-AGT-001
Infrastructure	INF	REQ-INF-001

Пример в requirements.md:

markdown

### Требование REQ-PAR-001: Парсинг каталога {#req-par-001}

**User Story:** Как пользователь, я хочу парсить каталог товаров...

#### Acceptance Criteria {#req-par-001-ac}
1. WHEN страница загружена, THE система SHALL найти все товары {#req-par-001-1}
2. WHEN товар найден, THE система SHALL извлечь данные {#req-par-001-2}

**🔗 Реализация:** [Task 1.1](./tasks.md#task-11)
**🧪 Тесты:** catalog.feature:Scenario "Parse catalog page"

Зачем:

•BABOK Requirements Traceability — связь от бизнес-потребности до кода
•Impact Analysis — легко найти что затронет изменение
•Покрытие — видно какие требования покрыты тестами

Requirements Traceability Matrix (RTM)

Таблица трассировки в конце requirements.md:

markdown

## 📊 Requirements Traceability Matrix

| REQ ID | Описание | Design | Task | Test Scenario | Статус |
|--------|----------|--------|------|---------------|--------|
| REQ-PAR-001 | Парсинг каталога | [CatalogParser](./design.md#1-parser) | [1.1](./tasks.md#task-11) | catalog.feature:15 | ✅ |
| REQ-PAR-002 | Сохранение в БД | [Repository](./design.md#2-repo) | [1.3](./tasks.md#task-13) | catalog.feature:42 | 🔄 |
| REQ-DB-001 | Connection pool | [Database](./design.md#3-db) | [2.1](./tasks.md#task-21) | — | ⏳ |

Статусы:

•✅ Реализовано и протестировано
•🔄 В процессе
•⏳ Ожидает
•❌ Заблокировано

Зачем:

•PMBOK Scope Management — baseline для требований
•BABOK Requirements Management — полная трассировка
•Отчётность — быстрый обзор прогресса

Business Context (Бизнес-контекст)

Расширенный формат Feature description в design.md:

gherkin

Feature: Catalog Parser - eBay Integration

  Business Context:
  Парсер должен извлекать товары с eBay для анализа цен
  и мониторинга конкурентов. Данные используются для
  автоматической корректировки ценовой политики.

  Business Value:
  - Автоматизация мониторинга конкурентов
  - Снижение ручной работы на 90%
  - Real-time данные для принятия решений

  Stakeholders:
  - Аналитики (основные пользователи)
  - DevOps (надёжность системы)
  - Product (новые фичи)

  Как аналитик
  Я хочу получать актуальные данные о товарах
  Чтобы принимать решения по ценообразованию

  Acceptance Criteria Owner: Product Team
  Last Updated: 2025-12-10
  Related Requirements: REQ-PAR-001 through REQ-PAR-010

Зачем:

•BABOK Strategy Analysis — понимание бизнес-контекста
•PMBOK Stakeholder Management — идентификация заинтересованных сторон
•Living Documentation — onboarding новых членов команды

Definition of Done (DoD)

Секция в начале tasks.md:

markdown

## ✅ Definition of Done (PMBOK Quality Management)

Задача считается **ВЫПОЛНЕННОЙ** только когда:

### Код:
- [ ] Все unit-тесты проходят (`pytest tests/unit/`)
- [ ] Code review одобрен (или self-review для solo)
- [ ] Нет critical/high багов
- [ ] Код соответствует design.md

### Тесты:
- [ ] pytest-bdd сценарии проходят (`pytest tests/features/`)
- [ ] Покрытие требований из RTM ≥ 90%
- [ ] NFR метрики в пределах нормы (если применимо)

### Документация:
- [ ] Docstrings добавлены для публичных функций
- [ ] Backlinks в requirements.md актуальны
- [ ] Backlinks в design.md актуальны

### Деплой:
- [ ] Docker build проходит
- [ ] Smoke tests пройдены

Зачем:

•PMBOK Quality Management — измеримые критерии качества
•Устраняет разночтения "что значит готово"
•Предотвращает "почти готово" статусы

Risk Register (Реестр рисков)

Секция в design.md:

markdown

## ⚠️ Risk Register (PMBOK Risk Management)

| ID | Риск | Вероятность | Влияние | Митигация | Тест-сценарий |
|----|------|-------------|---------|-----------|---------------|
| RISK-001 | Cloudflare блокировка | Высокая | Высокое | Retry + прокси ротация | @Risk Scenario: Cloudflare block |
| RISK-002 | Изменение HTML структуры | Средняя | Высокое | Мониторинг + алерты | @Risk Scenario: Selector change |
| RISK-003 | Timeout при парсинге | Средняя | Среднее | Увеличение timeout + retry | @Risk Scenario: Page timeout |
| RISK-004 | Дублирование данных | Низкая | Среднее | Upsert + unique constraint | @Risk Scenario: Duplicate insert |

И соответствующие задачи в tasks.md:

markdown

## Итерация RISK: Risk-based Testing

**Цель:** Покрытие идентифицированных рисков тестами

### 🔴 RED (Test)

- [ ] RISK.1 Написать тест для RISK-001 (Cloudflare block) {#task-risk1}
  - **📋 REQ**: [REQ-PAR-001](./requirements.md#req-par-001)
  - **🏗️ DESIGN**: [Risk Register](./design.md#risk-register)
  - **⚠️ РИСК**: RISK-001
  - Сценарий: Given Cloudflare returns 403, Then retry with new proxy
  - Mock: 403 response на первые 3 запроса

- [ ] RISK.2 Написать тест для RISK-002 (Selector change) {#task-risk2}
  - **📋 REQ**: [REQ-PAR-002](./requirements.md#req-par-002)
  - **⚠️ РИСК**: RISK-002
  - Сценарий: Given selector not found, When fallback used, Then data extracted

Зачем:

•PMBOK Risk Management — один из 10 knowledge areas
•Тесты для рисков предотвращают production incidents
•Документирует осознанное тестирование edge cases

Non-Functional Requirements (NFR)

Секция в requirements.md:

markdown

## 🏋️ Non-Functional Requirements (NFR)

### NFR-001: Performance {#nfr-001}
- Парсинг одной страницы < 10s (p95)
- Throughput > 100 страниц/час на воркер

### NFR-002: Reliability {#nfr-002}
- Availability 99% (excluding target site downtime)
- Graceful degradation при блокировках
- Zero data loss для успешно спарсенных данных

### NFR-003: Scalability {#nfr-003}
- Horizontal scaling через Docker replicas
- Stateless workers

И итерация в tasks.md:

markdown

## Итерация NFR: Non-Functional Testing

**Цель:** Валидация нефункциональных требований

### 🔴 RED (Test)

- [ ] NFR.1 Написать performance тест {#task-nfr1}
  - **📋 NFR**: [NFR-001](./requirements.md#nfr-001)
  - locust/k6 сценарий для 10 concurrent workers
  - Assert: p95 < 10s

- [ ] NFR.2 Написать reliability тест {#task-nfr2}
  - **📋 NFR**: [NFR-002](./requirements.md#nfr-002)
  - Chaos test: kill random worker
  - Assert: no data loss, graceful recovery

### 🟢 GREEN (Implementation)

- [ ] NFR.3 Добавить circuit breaker если нужно
- [ ] NFR.4 Настроить health checks

Зачем:

•BABOK Solution Evaluation — метрики качества
•NFR часто забывают, а потом "production не тянет"
•Делает NFR тестируемыми, а не абстрактными

🏷️ Tags (Теги трассировки)

Расширенный формат задач с рекомендуемыми тегами для pytest-bdd:

markdown

- [ ] 1.1 Написать E2E тест парсинга каталога {#task-11}
  - **📋 REQ**: [REQ-PAR-001](./requirements.md#req-par-001), [REQ-PAR-002](./requirements.md#req-par-002)
  - **🏗️ DESIGN**: [CatalogParser](./design.md#1-parser)
  - **⚠️ ОГРАНИЧЕНИЯ**: Использовать BeautifulSoup
  - **🏷️ TAGS**: `@PAR @E2E @REQ-PAR-001 @REQ-PAR-002 @critical`
  - **📊 RTM**: Обновить после завершения

Формат тегов:

•@{Domain} — домен (PAR, DB, API, AGT, INF)
•@{Type} — тип теста (E2E, integration, unit)
•@REQ-XXX-NNN — ссылка на требование
•@critical / @smoke / @regression — приоритет

Использование в pytest:

bash

# Запуск только парсер-тестов
pytest -m "PAR"

# Запуск критических E2E
pytest -m "critical and E2E"

# Запуск по требованию
pytest -m "REQ_PAR_001"  # (дефис → подчёркивание в pytest markers)

Зачем:

•BABOK Requirements Traceability
•При создании .feature разработчик знает какие теги добавить
•Автоматизация: можно фильтровать тесты по требованиям

👥 Stakeholders & RACI Matrix

Секция в requirements.md:

markdown

## 👥 Stakeholders (PMBOK Stakeholder Management)

| Роль | Ответственность | Коммуникация |
|------|-----------------|--------------|
| Developer | Реализация и тестирование | Daily standup |
| QA | Стратегия тестирования | Test plan review |
| DevOps | Инфраструктура, деплой | Deploy readiness |
| Product | Приоритизация требований | Weekly sync |

### RACI Matrix

| Активность | Developer | QA | DevOps | Product |
|------------|-----------|-----|--------|---------|
| Requirements approval | C | C | I | A/R |
| Design decisions | A/R | C | C | I |
| Implementation | A/R | I | I | I |
| Testing | R | A | I | I |
| Deployment | R | C | A | I |

**Легенда:** R=Responsible, A=Accountable, C=Consulted, I=Informed

Зачем:

•PMBOK Communications Management
•Ясно кто за что отвечает
•Снижает "а я не знал" ситуации

Полный паттерн KIRO

Файл 1: requirements.md

Назначение: Определить ЧТО нужно построить

Структура:

markdown

# Документ требований: {Feature Name}

## 📎 Связанные документы
[Cross-Reference Header]

## Введение
[2-3 абзаца описывающих:]
- Обзор системы
- Связь с существующим кодом
- Стратегия переиспользования
- Текущая область и отложенные элементы

## 👥 Stakeholders + RACI Matrix
[PMBOK Stakeholder Management]

## Архитектура системы
[ASCII диаграмма]

## Глоссарий
### Основные термины
### Тестовая инфраструктура

## 📦 Существующая реализация
[Fixtures, Steps, Features из проекта]

## Требования
### Требование REQ-{DOMAIN}-001: {Title} {#req-domain-001}
**User Story:** Как {роль}...
#### Acceptance Criteria {#req-domain-001-ac}
1. WHEN..., THE система SHALL... {#req-domain-001-1}

## 🏋️ Non-Functional Requirements (NFR)

## 📊 Requirements Traceability Matrix

Ключевые паттерны:

•

Формат User Story:

code

Как <роль>, я хочу <действие>, чтобы <результат>

•

Формат Acceptance Criteria (WHEN/SHALL):

code

WHEN <condition>, THE система SHALL <specific action>

•
Нумерация: REQ-{DOMAIN}-{NNN} с AC пронумерованными внутри
•
Примеры: Включать JSON payloads, code snippets где полезно

Файл 2: design.md

Назначение: Определить КАК это построить

Структура:

markdown

# Design Document: {Feature Name}

## 📎 Связанные документы
[Cross-Reference Header]

## Обзор
[Технический подход, принципы]

## 📋 Business Context (BABOK)
[Feature description с Business Value, Stakeholders]

## Архитектура
### Component Diagram
[ASCII диаграмма]

### Sequence Diagram
[ASCII диаграмма]

## Компоненты и интерфейсы
### 1. ComponentName {#1-component-name}
**Validates:** [REQ-XXX-NNN]
**Location:** `path/to/file.py`
**Purpose:** ...
**Key Methods:**
```python
class ComponentClass:
    async def method(self, param: str) -> Result:
        ...

Data Models

python

@dataclass
class DataModel:
    field: str

Обработка ошибок

Стратегия тестирования

Test Pyramid

Приоритет сценариев

Свойства корректности

Testable Correctness Properties

Example-Based Test Cases

⚠️ Risk Register (PMBOK)

План реализации

Зависимости

Критерии успеха

code


**Ключевые паттерны:**

1. **ASCII Диаграммы:** Использовать символы рисования рамок для архитектуры
2. **Примеры кода:** Python с type hints
3. **Correctness Properties:** Анализировать какие AC тестируемы как свойства vs примеры

---

### Файл 3: tasks.md

**Назначение:** Определить ПОСЛЕДОВАТЕЛЬНОСТЬ реализации (TDD/BDD)

**Структура:**

```markdown
# План реализации: {Feature Name}

## 📎 Связанные документы
[Cross-Reference Header со СТОП-правилом]

## ✅ Definition of Done (PMBOK)

## Методология: Red-Green-Refactor

---

## Итерация 1: {Goal}

**Цель:** {Description}

### 🔴 RED (Test)
- [ ] 1.1 Создать feature файл {#task-11}
  - **📋 REQ**: [REQ-XXX-NNN]
  - **🏗️ DESIGN**: [Component]
  - **⚠️ ОГРАНИЧЕНИЯ**: ...
  - **🏷️ TAGS**: `@Domain @E2E @REQ-XXX-NNN`
  - **📊 RTM**: Обновить после завершения

### 🟢 GREEN (Implementation)
- [ ] 1.2 Реализовать минимальный код {#task-12}

### 🔵 REFACTOR
- [ ] 1.3 Улучшить структуру {#task-13}

---

## Итерация NFR: Non-Functional Testing

## Итерация RISK: Risk-based Testing

## Итерация FINAL: Финализация
- [ ] FINAL.1 Полный прогон тестов
- [ ] FINAL.2 Обновить RTM
- [ ] FINAL.3 Проверить backlinks

## Легенда

Ключевые паттерны:

•
Структура итерации:
- •Чёткое описание цели
- •🔴 RED - создание теста
- •🟢 GREEN - реализация
- •🔵 REFACTOR - улучшение
•
Формат чекбокса: - [ ] X.Y Description {#task-xy}
•
Нумерация задач: <iteration>.<task> (например, 1.1, 1.2, 2.1)
•
Inline Traceability: 📋 REQ, 🏗️ DESIGN, ⚠️ ОГРАНИЧЕНИЯ

Interconnection Rules

⚠️ ВАЖНО: Все три файла ОБЯЗАНЫ быть связаны через Cross-Reference Headers и Inline Traceability Tags.

requirements.md → design.md

•Каждый REQ-{DOMAIN}-{NNN} имеет якорь {#req-domain-nnn}
•Каждый AC N.M имеет якорь {#req-domain-nnn-m}
•В design.md компоненты содержат **Validates:** [REQ-XXX-NNN]

requirements.md → tasks.md

•Каждое требование содержит секцию **🔗 Реализация:** [Task X.Y]
•Требования определяют цели итераций

design.md → tasks.md

•Каждый компонент содержит **🔗 Реализация:** [Task X.Y]
•Architecture якоря используются в tasks.md

tasks.md → requirements.md + design.md

•
КАЖДАЯ задача ОБЯЗАНА содержать:
- •**📋 REQ:** [REQ-XXX-NNN] — ссылки на требования
- •**🏗️ DESIGN:** [Component] — ссылки на архитектуру
- •**⚠️ ОГРАНИЧЕНИЯ:** — что нельзя/обязательно (опционально)

Примеры использования

Пример 1: Parser Specification

code

User: "Создай спецификацию для парсера каталога товаров"

Claude генерирует:
.kiro/specs/catalog-parser/
├── requirements.md   # 10+ требований: извлечение данных, пагинация, фильтры
├── design.md         # BeautifulSoup компоненты, sequence диаграммы
└── tasks.md          # 5 TDD итераций с pytest-bdd сценариями

Пример 2: AI Agent Specification

code

User: "Нужны спеки для агента мониторинга цен"

Claude генерирует:
.kiro/specs/price-monitoring-agent/
├── requirements.md   # Отслеживание, алерты, история изменений
├── design.md         # Agent loop, API интеграции, storage
└── tasks.md          # TDD итерации с async fixtures

Пример 3: API Integration Specification

code

User: "Сделай спецификацию для интеграции с внешним API"

Claude генерирует:
.kiro/specs/external-api-integration/
├── requirements.md   # Endpoints, авторизация, rate limiting
├── design.md         # HTTP client, retry logic, data mapping
└── tasks.md          # Mock-based тесты, E2E проверки

Quality Checklist

requirements.md

📦 Секция "Существующая реализация" (ОБЯЗАТЕЛЬНО)

• Перечислены ВСЕ fixtures из conftest.py
• Перечислены ВСЕ hooks (pytest_*, autouse fixtures) с их назначением
• Перечислены существующие feature файлы
• Таблица Step Definitions с количеством строк
• Для крупных Steps файлов (>50 строк) — список @given/@when/@then
• Указан статус каждого компонента (✅ ГОТОВ / ⏳ TODO / REUSE)

design.md

tasks.md

Советы для качественных спецификаций

•Будьте конкретны: Включайте пути к файлам, URL endpoints, конкретные значения
•Используйте диаграммы: ASCII art для архитектуры обязателен
•Ссылайтесь на существующий код: Связывайте с реальными файлами в кодовой базе
•Определяйте термины: Глоссарий предотвращает неоднозначность
•Анализируйте тестируемость: Не все AC тестируемы как свойства
•Упорядочивайте итерации: Сначала зависимости, затем функции
•Включайте примеры: JSON payloads, фрагменты кода, выводы команд

🔍 Автоматическая валидация спецификаций

Обзор

Система включает автоматическую валидацию KIRO спецификаций на соответствие PMBOK/BABOK стандартам:

•Сабагент: ОБЯЗАН запускать валидацию после создания каждого файла

Команда валидации

bash

python .claude/skills/kiro-spec-generator-python/scripts/validate_kiro_spec.py \
  .kiro/specs/{SPEC_NAME}/ --format short

Форматы вывода:

•full — полный отчёт со всеми проверками
•compact — только warnings/errors
•short — минимальный вывод для СТОП-точек

Что валидируется

📋 requirements.md

Проверка	Severity
Cross-Reference Header	ERROR
REQ-ID формат (`REQ-{DOMAIN}-{NNN}`)	ERROR
Якоря требований (`{#req-xxx-nnn}`)	ERROR
Stakeholders + RACI Matrix	WARNING
NFR секция	WARNING
RTM таблица	WARNING
WHEN/SHALL формат AC	WARNING

🏗️ design.md

Проверка	Severity
Cross-Reference Header	ERROR
Component якоря (`{#n-component}`)	ERROR
Business Context	WARNING
Risk Register	WARNING
Validates ссылки на REQ	INFO

✅ tasks.md

Проверка	Severity
Cross-Reference Header со СТОП-правилом	ERROR
Task якоря (`{#task-xy}`)	ERROR
📋 REQ ссылки в каждой задаче	ERROR
🏗️ DESIGN ссылки в каждой задаче	ERROR
Definition of Done	WARNING
Red-Green-Refactor структура	WARNING
🏷️ TAGS	WARNING

🔗 Cross-file валидация

Проверка	Severity
Битые ссылки на якоря	ERROR
REQ-ID консистентность	WARNING
Backlinks	INFO

Интерпретация результатов

Символ	Severity	Действие
✅	OK	Проверка пройдена
⚠️	WARNING	Рекомендация, можно продолжать
❌	ERROR	Критическая ошибка, ИСПРАВИТЬ

Exit Codes

•0 — валидация прошла (могут быть warnings)
•1 — есть errors

Hook интеграция (Claude Code)

Hook автоматически запускается при редактировании .kiro/specs/**/*.md файлов и выводит результат только если есть warnings/errors.

Конфигурация в .claude/settings.json:

json

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit|MultiEdit",
      "hooks": [{
        "type": "command",
        "command": "python .claude/skills/kiro-spec-generator-python/scripts/validate_kiro_spec.py .kiro/specs/ --format compact",
        "timeout": 30,
        "statusMessage": "Validating KIRO spec..."
      }]
    }]
  }
}

Когда срабатывает:

•При любом Write или Edit файла в .kiro/specs/
•Выводит только ошибки и предупреждения (не засоряет output)
•Timeout 30 секунд для больших спецификаций

Created: 2025-12-10 Adapted for: Python / pytest-bdd / asyncio Based on: Original KIRO Spec Generator for C#/Reqnroll