Controlled Skill Routing

Обзор

Сводка reusable lesson routing

Мы построили небольшой механизм обслуживания skills для Codex: переносимые уроки из реальной работы можно продвигать в глобальные инструкции, не превращая их в проектные заметки.

Центральный элемент - $update-all. Он не должен хранить domain knowledge сам по себе. Его задача - анализировать завершённую conversation или project session, находить reusable lessons и маршрутизировать их к правильному family updater skill. Затем каждый family updater сам решает, нужно ли что-то менять.

Это важно, потому что active project work часто даёт смесь разных типов knowledge. Без routing layer всё это легко смешивается. Цель $update-all - предотвратить это: помогать Codex учиться на повторяющейся работе, сохраняя global skills clean, reusable and safe.

• реальный reusable failure mode
• stack-specific workflow improvement
• project-only implementation detail
• private business rule
• one-off workaround
• existing lesson already covered well enough

The core rule

Default to no changes

Главное правило: по умолчанию ничего не менять. $update-all не должен обновлять skills только потому, что работа завершилась. Обновление оправдано лишь тогда, когда сессия дала урок, который с высокой вероятностью поможет будущим несвязанным проектам.

Когда после фильтра ничего не остаётся, $update-all должен явно сообщить, что updater не выбран и файлы не изменены.

• project-specific implementation details
• company-specific business logic
• private URLs, credentials, tokens, domains or payloads
• isolated hacks that do not generalize
• cosmetic wording preferences
• duplicate lessons already covered by existing skills

Family updater skills

Durable ownership model

Вместо одного giant global memory skill используются отдельные family updater skills. Каждый владеет широкой технической областью и следует паттерну $n8n-skill-update.

Текущие registered updater families включают:

• $n8n-skill-update
• $amocrm-update
• $frontend-skill-update
• $react-next-skill-update
• $astro-static-site-skill-update
• $django-skill-update
• $database-skill-update
• $deployment-skill-update
• $docker-nginx-skill-update
• $webhook-integration-skill-update
• $security-auth-skill-update
• $browser-qa-skill-update
• $document-pdf-skill-update
• $ios-builder

Registry boundary

Broad maintainers only

В registry должны попадать только broad family updater or maintainer skills. Focused subskills остаются внутри своих families и не добавляются в global registry.

Например, browser-qa-localhost, deployment-vps-systemd, static-site-seo или vite-react-build - полезные focused skills, но они должны referenced by their family updater, not by $update-all directly.

How routing works

Candidate lesson classification flow

$update-all сначала анализирует завершённую работу и извлекает candidate lessons. Затем каждый surviving lesson отправляется самому специфичному family updater.

Примеры маршрутизации:

• MongoDB, MySQL, SQL migrations, query integrity -> $database-skill-update
• React, Next.js, Vite, TypeScript build behavior -> $react-next-skill-update
• general UI layout, responsive behavior, visual polish -> $frontend-skill-update
• browser screenshots, Playwright checks, console logs -> $browser-qa-skill-update
• VPS rollout, systemd, Nginx, production smoke checks -> $deployment-skill-update
• Docker Compose, Nginx proxying, TLS/container topology -> $docker-nginx-skill-update
• webhooks, provider callbacks, payload normalization -> $webhook-integration-skill-update
• tokens, auth, signatures, secrets, CORS/CSRF -> $security-auth-skill-update

Specific ownership

Specific beats broad

Specific ownership beats broad ownership. React/Vite build lesson должен идти в $react-next-skill-update, а не в более общий $frontend-skill-update. Docker/Nginx proxy lesson должен идти в $docker-nginx-skill-update, а не в broader deployment updater.

Multiple updaters можно использовать только когда lessons genuinely independent. One lesson should not be duplicated across several families.

Inside a family updater

Updater decision model

Каждый family updater следует одной базовой decision model:

• no update needed
• update one existing skill
• create one new focused subskill
• update itself if its family map or routing rules changed

Updater ownership

$update-all только маршрутизирует

Updater должен предпочитать update existing skill. Он создаёт new focused subskill только когда lesson narrow, recurring, reusable and not already covered.

Например, если сессия дала реальный reusable MongoDB lesson, $update-all должен route it to $database-skill-update. Затем database updater решает: ничего не делать, обновить existing database skill или создать focused skill вроде database-mongodb.

$update-all сам не должен создавать database-mongodb. Он только routes the lesson to the right owner.

Unowned stack triage

Handling new reusable domains

Мы добавили explicit logic для новых stacks or tools, которые не названы в registry.

Ключевое правило: new stack is not automatically a new family. Сначала $update-all проверяет, принадлежит ли lesson существующей broad family.

• MongoDB belongs under database
• S3 or object storage often belongs under deployment
• image/media rendering often belongs under frontend
• Stripe callbacks often belong under webhook integration, with security only if there is an independent signature/auth lesson

Unowned family reporting

No silent updater creation

Если stack был только небольшим implementation detail и не дал reusable lesson, update не должен происходить.

Если stack дал reusable lesson, но никакая existing family clearly owns it, $update-all не должен silently create a new updater. Он должен report the unowned lesson and recommend a candidate updater name.

Skill creator integration

Family updater registration rules

Мы также обновили $skill-creator, чтобы будущие family updater skills регистрировались корректно.

Когда Codex создаёт или переименовывает skill, whose primary job is maintaining a named family over time, $skill-creator должен проверить $update-all и добавить одну compact registry entry.

Он должен регистрировать только skills, которые являются:

• family updater or maintainer skills
• durable across future projects
• distinct from existing updater families
• capable of choosing between no update, updating one existing skill, creating one focused subskill, or refreshing their own family map

What not to register

Implementation skills stay outside registry

$skill-creator не должен регистрировать normal implementation skills, one-off project skills, focused subskills inside a family или skills, которые merely mention update, upgrade, migration or generation but do not maintain a family.

Это значит, что если позже появится new durable area вроде Acumatica ERP, future $acumatica-skill-update можно cleanly add to $update-all. Но обычный Acumatica implementation helper не должен попадать в registry.

Audit results

Global skill registry verification

После active work мы audited global skills directory, чтобы проверить, корректно ли работает $update-all.

Важный результат: $update-all не зарегистрировал focused subskills или project skills. Его registry по-прежнему содержал только broad updater/maintainer skills.

Были reviewed several new focused skills:

• browser-qa-console-logs
• browser-qa-localhost
• deployment-vps-systemd
• static-site-seo
• vite-react-build
• ios-list-thread-details

Audit cleanup

Project-shaped wording removed

Большинство focused skills были cleanly generalized. Они описывали reusable workflows, а не private project details.

Главная найденная проблема была в iOS family. $ios-builder содержал phrase For this workspace specifically, из-за чего global updater выглядел привязанным к одному workspace. Мы исправили wording и generalized surrounding section.

Также мы softened project-shaped wording в ios-list-thread-details, заменив узкие фразы вроде CRM-like dialogs, React + Tauri + WebView и dialog switch на более broad terms: contact-heavy apps, hybrid WebView apps, thread switching и reusable mobile pane patterns.

• static-site-seo теперь использует more neutral static-export examples
• vite-react-build теперь использует /old-subpath/ and /legacy-prefix/ вместо project-shaped /design/ example

Current status

Controlled learning loop state

Архитектура сейчас в хорошем состоянии.

$update-all работает как manual command. Он не должен запускаться автоматически в конце каждой сессии. Пользователь вызывает его явно, когда хочет, чтобы Codex проанализировал завершённую работу и решил, justified ли any global skill updates.

Текущая модель:

• user manually calls $update-all
• $update-all analyzes the session
• weak or project-only lessons are rejected
• reusable lessons are routed to the right family updater
• family updaters decide whether to change anything
• focused subskills stay inside their family, not in the global registry
• new family updaters require explicit user confirmation
• useful patterns can be preserved, but project details do not leak into global skills by default