code-quality — Ветки A+, B, C: подгруппы, частичный анализ, субъективный обзор
Часть skill'а code-quality. Условия запуска, развилка по размеру, формат вывода и жёсткие правила — в SKILL.md; полный канон ветки A — в
references/detailed-canon.md. Этот файл читается целиком при соответствующей ветке.
Ветка A+ — разбиение на подгруппы
Условие: 3000–12000 LOC, естественное деление на 2–4 группы ≤3000 LOC каждая.
Предложение разбиения
Перед запуском анализа вывести структуру разбиения с обоснованием:
Предлагаю разбить <target> (X LOC) на N групп:
- Группа 1 — <название> (Y₁ LOC): <состав, обоснование>
- Группа 2 — <название> (Y₂ LOC): <состав, обоснование>
- Группа 3 — <название> (Y₃ LOC): <состав, обоснование>
Сумма: Y₁+Y₂+Y₃ = X ✓ (все < 3000)
Каждая группа = отдельный полный анализ по канону (ветка A).
Итоговые баллы — среднее по всем группам, флаги — объединение с дедупом.
Подтвердить?
Дождаться подтверждения. Без подтверждения — не запускать.
Критерий «естественности» деления:
- группы соответствуют разным зонам ответственности (ядро vs контракты vs реализации; разные типы данных; разные бэкенды);
- классы одной зоны ответственности не разрезаются между группами (если
ManagerXв G1,MetadataXиStateXтоже в G1); - базовые классы и контракты идут в более раннюю группу, реализации — в более позднюю.
Если группы неровные (одна 2900, другие по 100) — деление искусственное, лучше ветка B.
Параллельный запуск
Agent (subagent_type=general-purpose, model=sonnet) × N
prompt: «Полный анализ группы по канону code-quality
(references/detailed-canon.md):
файлы [...], шаги 0–5, формат вывода — структурированный markdown
с разделами Инвентарь / Формулы / Pre-check / Архитектурные маркеры
/ Red / Yellow / Итог»
run_in_background: true
Каждый агент должен вернуть по канону detailed-canon.md полный отчёт со всеми категориями и обнаруженными маркерами. Никаких сокращений.
Сведение результатов
Усреднение баллов по категориям
Документируемость = avg(D₁, D₂, …, Dₙ)
Масштабируемость = avg(S₁, S₂, …, Sₙ)
Поддерживаемость = avg(M₁, M₂, …, Mₙ)
Производительность = avg(P₁, P₂, …, Pₙ)
Базовый = (D/10 + S/10 + M/10 + P/20) / 3.5 × 10
Дедуп архитектурных маркеров
Маркер идентифицируется типом (Ложная точка расширения, Кустовая обязательность, Смешение Model/View, Fat Interface, Перегруженность настроек, Discoverability), не конкретным проявлением.
- Если один и тот же тип маркера найден в G1, G2, G3 — это 1 маркер в
arch, но в отчёте перечислить все проявления. - Если в одной группе
Fat Interface— этоIActor, в другой —ITextPrinterActor, это всё равно 1 маркер «Fat Interface», просто с двумя проявлениями. - Никакой systemic-поправки нет: повторение типа в нескольких группах счётчик не умножает.
Дедуп red-флагов
Аналогично — по типу (cyclo>20, DIT>5, Fat Interface, new в Update, GetComponent в кадре, >30 полей в endpoint, async void). Без мультипликации за повтор.
Yellow-флаги
Объединение всех проявлений по группам без дедупа (информационно). В множитель не идут.
Итоговая формула
Итог = Базовый × 0.5^arch_dedup × 0.9^red_dedup
Где arch_dedup, red_dedup — счётчики после дедупа по типам.
Формат вывода
[Ветка A+] Сводная оценка <target>
- LOC: <total>
- Группы: G1 (Y₁), G2 (Y₂), G3 (Y₃)
- Применимость канона: полная (по подгруппам)
## Усреднённые баллы
| Категория | G1 | G2 | … | Среднее |
| ... |
## Объединённые арх. маркеры (дедуп)
| # | Маркер | Где зафиксирован |
| 1 | Ложная точка расширения | G1: …; G2: …; G3: … |
| ... |
## Объединённые red-флаги (дедуп)
…
## Объединённые yellow-флаги
…
## Итог
- Множитель: 0.5^arch × 0.9^red = …
- Базовый: X
- Итог: X
- Интерпретация: <по шкале>
## Диагностический сигнал
<если разрыв Базовый ↔ Итог большой — комментарий>
Ветка B — частичный анализ (с предупреждением)
Условие: 3000–10000 LOC.
Перед началом ОБЯЗАТЕЛЬНО вывести:
⚠️ Предупреждение: объём кода превышает порог детального анализа (>3000 LOC). Количественные метрики (формулы 1.x–4.x) применимы, но архитектурные маркеры могут быть пропущены —
async void, ложная расширяемость, Fat Interface требуют построчного чтения, которое на этом объёме неполное. Оценка достоверна по формулам; маркеры — выборочно.
Затем:
- Применить формулы количественно (detailed-canon.md — все категории 1.x–4.x).
- Маркеры архитектурных проблем — прогнать выборочно через grep'ы (detailed-canon.md: pre-check 3.3 + быстрые grep'ы 3.6):
async voidв публичных методах.- Интерфейсы с >15 членами.
- Цепочки
as ConcreteType. - Прямые вызовы
GetService<Concrete>минуя интерфейс.
- Red-flag чек-лист (detailed-canon.md) — только grep-проверяемые пункты.
- Итоговую формулу (detailed-canon.md, 3.7) применять, в выводе явно маркировать «оценка частичная, маркеры могут быть пропущены».
Делегирование: все grep-прогоны и подсчёты — через дешёвого агента (
Exploreилиgeneral-purposeсmodel=haiku). Основной контекст агрегирует только числа.
Ветка C — субъективный обзор (с предупреждением)
Условие: >10000 LOC.
Перед началом ОБЯЗАТЕЛЬНО вывести:
❌ Предупреждение: объём кода (X LOC) превышает порог применимости канона. На этом объёме LLM скатывается в каталогизацию вместо анализа: пропускает
async void, ложную расширяемость, Fat Interface, скрытые контракты. Корректная оценка по формулам невозможна в одну сессию.Доступно только субъективное мнение об архитектуре — без чисел, без формул, без баллов. Это НЕ оценка качества по канону.
Для корректной оценки — разбить скоуп на отдельные пакеты ≤3000 LOC и оценивать каждый по очереди.
Затем спросить:
«Продолжить с субъективным обзором (с явной маркировкой что это мнение, не оценка), или предпочтёте разбить на пакеты для детального анализа?»
Если пользователь выбрал субъективный обзор:
- Не выводить никаких числовых оценок по формулам канона.
- Дать качественные наблюдения по архитектуре с явной шапкой «Субъективный обзор, не оценка по формулам».
- Опционально перечислить grep-обнаруживаемые красные флаги (с пометкой что это не полная картина) — через дешёвого агента (быстрые grep'ы, detailed-canon.md).
- Финальный вывод — рекомендация какие подсистемы стоит оценить детально по канону отдельно.