diff --git a/plugins/222a-seo-audit/skills/222a-seo-audit/SKILL.md b/plugins/222a-seo-audit/skills/222a-seo-audit/SKILL.md index 91ee813..5a65f48 100644 --- a/plugins/222a-seo-audit/skills/222a-seo-audit/SKILL.md +++ b/plugins/222a-seo-audit/skills/222a-seo-audit/SKILL.md @@ -31,7 +31,7 @@ Use the 222A MCP server for SEO audit context instead of scraping local database - To explain progress between two completed audits, call `compare_audits` and save useful conclusions as `progress_comparison` when write access exists. Treat the issue `changed` bucket as severity changes; same-severity persistent issues are in `unchanged`. - When monitoring an audit, poll politely, avoid tight loops, and always keep `audit_run_id` visible so the user can resume later. - List resources to discover available audits: `resources/list`. -- Read `audit://{audit_run_id}/context` or call `get_audit_context` before analysis. +- Read `audit://{audit_run_id}/context` or call `get_audit_context` before analysis. On large projects (issues_total > ~3000) prefer `get_audit_context(audit_run_id, mode="compact")` for orientation — it omits the heavy `issues[]` array, adds `issues_summary` aggregations + `drill_down_hints`, and trims `progress_since_previous.top_*` to 5. Drill down via `get_top_priorities`, `get_executive_summary`, `get_issue_clusters`, or `get_issue_pages` per the hints. - Read `audit://{audit_run_id}/workspace-summary` or call `get_audit_workspace_summary` when deciding whether to create/update a manager synthesis or client report. Use `workspace.progress_since_previous` for a quick progress note when available. - Read `audit://{audit_run_id}/analyses` before writing, to avoid duplicating prior conclusions. - Save durable, manager-facing output with `save_audit_artifact` unless the user explicitly says not to save it. diff --git a/plugins/222a-seo-audit/skills/222a-seo-audit/references/mcp-contract.md b/plugins/222a-seo-audit/skills/222a-seo-audit/references/mcp-contract.md index 1d1706d..e582222 100644 --- a/plugins/222a-seo-audit/skills/222a-seo-audit/references/mcp-contract.md +++ b/plugins/222a-seo-audit/skills/222a-seo-audit/references/mcp-contract.md @@ -241,6 +241,17 @@ Input: Output includes the same safe context as `audit://123/context` in `structuredContent`. When a previous completed audit exists for the same project, `progress_since_previous` summarizes the adjacent diff: previous/current audit ids and finish times, resolved and organically appeared issue counts, issues attributed to newly connected data sources, issues attributed to data sources that became unavailable, improved/worsened severity counts, flaky perf counts (`appeared_flaky_count`, `resolved_flaky_count`, `changed_flaky_count`, `top_flaky_issues`), site-level issue counts (`site_appeared_issues_count`, `site_resolved_issues_count`, `site_changed_issues_count`, `top_site_appeared_issues`, `top_site_resolved_issues`, `top_site_changed_issues`, plus parallel `site_appeared_due_to_new_data_source_count` / `site_resolved_due_to_data_source_unavailable_count` and `top_site_*` variants), page deltas, `top_resolved_pages`, `top_appeared_pages`, HTTP status recovery/regression counts, score/page-crawl deltas, and top safe issue samples. `appeared_issues_count` is organic; explain `appeared_due_to_new_data_source_count` and `top_appeared_due_to_new_data_source` separately as new evidence, not automatic site degradation. `resolved_issues_count` is organic; explain `resolved_due_to_data_source_unavailable_count` and `top_resolved_due_to_data_source_unavailable` separately as false-positive resolutions caused by a previously connected source going offline, not real fixes. Flaky perf issues are kept out of `appeared`/`resolved`/`changed` buckets and routed to `appeared_flaky`/`resolved_flaky`/`changed_flaky` instead — these are measurement noise around lab thresholds, not real progress or regression. Site-level issues (ya.*, seo.duplicate_*, tech.crawled_not_in_sitemap, seo.url_*, content.near_duplicate, seo.hreflang_*, seo.indexed_not_crawled) are tracked separately in the `site_issues` bucket — they affect many URLs at once, not single pages. Use this for a quick manager answer about what was fixed since the last audit; call `compare_audits` for full drill-down (`compare_audits` payload includes both `issues` and `site_issues` buckets). +**Optional параметр `mode` (контракт 1.51.0+):** + +- `mode: "full"` (default) — полный payload, включая массив `issues[]` со всеми обогащениями per-issue (priority, fix_effort, quick_win, remediation_summary, data_freshness, acknowledged). +- `mode: "compact"` — orientation/triage режим без длинного `issues[]`: + - Опускается ключ `issues`. + - Добавляется `issues_summary` с агрегатами `{total, by_severity, by_category, by_priority_bucket}` (присутствует в обоих режимах). + - Массивы `progress_since_previous.top_*` обрезаются до 5 элементов (counts остаются полные). В full режиме теперь возвращается до 10 элементов. + - Добавляется `drill_down_hints` со списком тулов для углубления: `get_top_priorities`, `get_executive_summary`, `get_issue_clusters`, `get_issue_pages`, `compare_audits`. + +Использовать compact на больших проектах (issues_total > ~3000), где full уходит за лимит токенов AI-клиента. + ### `get_issue_pages` Requires `mcp.read`.