feat(plugin): команды /222a-report и /222a-progress

This commit is contained in:
Alex 2026-05-22 19:22:01 +02:00
parent 006f3c0082
commit 7e3d7cdf43
2 changed files with 67 additions and 0 deletions

View File

@ -0,0 +1,38 @@
---
description: Сравнение текущего аудита с предыдущим (что починили, что появилось)
argument-hint: "[audit_run_id]"
---
Пользователь хочет понять прогресс между аудитами. Аргумент: `$ARGUMENTS`
## Шаги
1. **Определить audit_run_id:**
- Если аргумент задан — используй его.
- Если пустой — возьми последний completed аудит через `list_audits`.
2. **Прочитать контекст:**
- Вызови `get_audit_context` для `audit_run_id`.
- Посмотри секцию `progress_since_previous` в ответе.
3. **Если `progress_since_previous` доступна (быстрый путь):**
- Используй её для краткой сводки «что починили / что органически появилось».
- Покажи `top_resolved_pages` и `top_appeared_pages` если есть.
- **ВАЖНО — data-source disambiguation:**
- `appeared_issues_count` — органические (реальные новые проблемы)
- `appeared_due_to_new_data_source_count` / `top_appeared_due_to_new_data_source` — это **не деградация сайта**, это новый источник данных (например, подключили GSC и появились старые CTR-проблемы)
- `resolved_issues_count` — органические починки
- `resolved_due_to_data_source_unavailable_count` / `top_resolved_due_to_data_source_unavailable` — это **не реальные починки**, это отвалившийся источник данных. НЕ показывай как progress.
- **ВАЖНО — флэйковость perf:**
- Perf-issues (cls/inp/page_weight) у границ lab-thresholds могут мигать. Они помечены `is_flaky=true` и попадают в отдельные счётчики `appeared_flaky_count`, `resolved_flaky_count`, `changed_flaky_count`, `top_flaky_issues`.
- Не показывай их как progress/regression — это измерительный шум.
- **Site-level issues:**
- ya.*, seo.duplicate_*, tech.crawled_not_in_sitemap, seo.url_*, content.near_duplicate, seo.hreflang_*, seo.indexed_not_crawled — живут в отдельных счётчиках `site_appeared_issues_count`/`site_resolved_issues_count`/`site_changed_issues_count` с теми же data-source оговорками.
- Подавай их как audit-wide изменения, не per-URL.
4. **Если нужен drill-down:**
- Вызови `compare_audits` для детального сравнения.
- Issue `changed` bucket = изменения severity. `unchanged` = persistent проблемы с тем же severity.
5. **Сохранить артефакт:**
- Если есть `mcp.write` и сравнение полезное — вызови `save_audit_artifact` с типом `progress_comparison`, `source="claude-code"`.

View File

@ -0,0 +1,29 @@
---
description: Собрать client report из готовых артефактов аудита
argument-hint: "[audit_run_id]"
---
Пользователь хочет собрать отчёт для клиента. Аргумент: `$ARGUMENTS`
## Шаги
1. **Определить audit_run_id:**
- Если аргумент задан — используй его.
- Если пустой — возьми последний completed аудит через `list_audits`.
2. **Проверить состояние workspace:**
- Вызови `get_audit_workspace_summary` с этим `audit_run_id`.
- Посмотри `client_ready_count` и список `client_ready` артефактов.
- Если `client_ready_count` = 0 — сообщи «нет готовых для клиента артефактов. Сначала запустите `/222a-audit` и сохраните executive_summary, или попросите менеджера подготовить материалы». Не продолжай.
3. **Инспектировать артефакты:**
- Вызови `list_audit_artifacts` для просмотра доступных артефактов.
- Если есть только executive_summary без специалистских материалов (recommendations, work_plan, progress_comparison) — спроси пользователя, делать ли отчёт только из executive_summary или подождать остальное.
4. **Создать client report:**
- Вызови `create_client_report` с `audit_run_id`.
- Покажи пользователю получившийся client_report.
5. **Сохранить артефакт:**
- Если есть `mcp.write` — вызови `save_audit_artifact` с типом `client_report`, `source="claude-code"`, телом отчёта.
- Не перезаписывай существующий client_report — если он уже есть, передай `parent_artifact_id` для версии.