11 rules · 2 of them hold with nothing installed
Which pack answers what, and when.
Installing a skill does not make an agent reach for it. The family writes this block into your agent's own instruction file, so the decision is made before the work starts rather than remembered afterwards. Every rule names the boundary in both directions — a router that swallows everything gets routed around within a week — and every rule names the phrase that declines it.
The table
| Router | Answers | When | Ships in |
|---|---|---|---|
| super-ux | what the interface must do | there is user-facing behaviour | super-ux |
| sheleg-design | how it looks and moves | there is a visual layer | sheleg-design |
| copywriting | how it sounds | text a user of the product will read | super-ux |
| sheleg-dev | what it runs on to charge, track and sign in | money, tracking, sign-in or speed is being wired | sheleg-dev |
| agent-stack | how an agent system is built, judged and metered | the thing being built is an agent | agent-stack |
| seo-llmo | whether a machine will find it | a logged-out reader can see the surface | a standing rule |
| evidence-docs | what proves it | something is stated as true | a standing rule |
| task-pipeline | how the change reaches the repository | the change touches the repository | task-pipeline |
| project-audit | what is actually true of this project right now | the question is the whole project, not one change | task-pipeline |
| make-skill | how the skill itself is built | a skill or plugin changes shape | make-skill |
| agent-sync | who is holding this file | the project has agent coordination on | agent-sync |
Every rule, verbatim
This is the exact text the family writes into your instruction
file — read from lib/routers-registry.js, which is the only place a
router is declared.
/super-ux — what the interface must do
- when: there is user-facing behaviour
- ships in super-ux
- decline it: «без сценариев».
If super-ux is installed, all work on the product and its interface goes through the chain — scenarios and their validation first, the interface second. Not only screens: product decisions, funnels, onboarding, payment steps — anything with a user and a path. docs/ux/scenarios.md is the source of truth for user-facing behaviour; no file → offer /ux before touching UI. A change to user-facing behaviour updates the scenarios in the same change. Checking code against them is /ux-audit, with file:line evidence.
The boundary — "this has a user." NOT through the chain: internal scripts, migrations with no interface, data work, infrastructure. Drawing a scenario for a cron job is how you teach an agent to route around the chain.
Refusal phrase: «без сценариев».
Among the routers: super-ux decides what the interface must do; sheleg-design how it looks; copywriting how it sounds.
/sheleg-design — how it looks and moves
- when: there is a visual layer
- ships in sheleg-design
- decline it: «без дизайна» or «как есть».
If sheleg-design is installed, the visual layer goes through it — tokens and themes, typography and rhythm, motion and its degradation to calm, the brand's visual language, and the Figma seam (tokens as variables, design into code without hand-copied values). A cinematic landing page, a dashboard, an admin panel, an agent's interface — one and the same layer.
The boundary — "HOW it looks is being decided." NOT through it: a purely structural change (what sits where is super-ux), text (copywriting), the backend, internal scripts with no interface. Picking a palette for a log parser is how you teach an agent to route around it.
Refusal phrase: «без дизайна» or «как есть».
Among the routers: super-ux decides what the interface must do; sheleg-design how it looks and moves. The wireframe goes to the first, the visual on top of it to the second.
/copywriting — how it sounds
- when: text a user of the product will read
- ships in super-ux
- decline it: «без бренда» or «черновиком».
If super-ux is installed, any text a user of the product will read is written through copywriting — interface strings, errors, empty states, landing pages, pricing, blog, user-facing changelog, posts, store listings, ads, email. Its first act is to read the brand pack (docs/brand/voice.md, terminology.md, facts.md); no pack → /brand-init before writing, not after.
The boundary — "it ships to a user of the product." NOT through the skill: a commit or PR description, code comments, a README for developers, internal docs, an answer in chat. Running the brandbook over a CHANGELOG line for developers is the fastest way to teach an agent to route around it.
Refusal phrase: «без бренда» or «черновиком». It applies to work that WOULD have crossed the boundary: write directly and say the pack was skipped on request, rather than skipping it silently.
Among the routers: sheleg-design decides how it looks; copywriting how it sounds. Neither waits for the other — both read the scenarios, not each other's output — but where they land on one screen, compare the two before shipping: a label the layout has no room for is right in each and wrong on the screen. A landing page passes both plus task-pipeline; a social post passes copywriting alone and changes no repository.
/sheleg-dev — what it runs on to charge, track and sign in
- when: money, tracking, sign-in or speed is being wired
- ships in sheleg-dev
- decline it: «без интеграций».
If sheleg-dev is installed, the integration layer under a paid product goes through it — taking card money (stripe-billing) or crypto (crypto-payments), the pixels and server-side events that say a purchase happened (ad-tracking), signing a person in (google-signin, google-auth), and the speed of what they land on (frontend-performance). It owns the seams a generated integration gets wrong in ways no screen shows: the webhook is the payment and the redirect only proves a browser; a purchase event fired from the thank-you page cannot know the charge cleared; the same event_id on both sides or the revenue counts twice.
The boundary — "it is being WIRED, not decided." NOT through it: what the paywall must do or which tiers exist (super-ux), how the checkout looks (sheleg-design), the words on it (copywriting), the price itself, which is a business decision nobody's skill makes. Routing a pricing argument here is how you teach an agent to skip it where it actually protects money.
Refusal phrase: «без интеграций».
Among the routers: super-ux decides what the payment step must do; sheleg-dev what it runs on. The paywall goes to the first, the charge behind the button to the second.
/agent-stack — how an agent system is built, judged and metered
- when: the thing being built is an agent
- ships in agent-stack
- decline it: «без агентного слоя».
If agent-stack is installed, building an agent SYSTEM goes through it — the orchestrator's loop and the shape of its work as a graph, what the agent is told (system prompts, tool descriptions, workflow versus agent), the evals that say whether it got better, the protocols it speaks outward (MCP, A2A, the registry, the gateway), and the wallet under reselling LLM access. It owns the failures that surface only under load: a parallel layer consumed with no checker before it, a memory layer that never decays, a trajectory judged by its final answer alone, tokens metered after the provider already charged for them.
The boundary — "an agent system is being BUILT, not used." NOT through it: a single LLM call in a script, the wording of one prompt, the interface a person sees (super-ux, sheleg-design), taking the money — sheleg-dev charges the card and this meters what was burned behind it — and coordinating the agents editing THIS repository, which is agent-sync. Routing every sentence with the word "agent" in it here is how you teach an agent to route around it.
Refusal phrase: «без агентного слоя».
Among the routers: agent-sync says who is holding this file right now; agent-stack is about the agent being built. The first coordinates the work, the second is what the work produces.
/seo-llmo — whether a machine will find it
- when: a logged-out reader can see the surface
- a rule, not a skill — it holds whether or not anything is installed
- decline it: «без SEO».
Every public web surface is designed for two readers at once — a human and the machine that will quote it. Decided AT DESIGN TIME, not audited afterwards: URLs and hierarchy, one question per page, an answer extractable without running JS, markup and entities, facts with a single home, internal links that explain the structure. Redoing this after launch costs more than deciding it once — the addresses have already spread into links and indexes. The check afterwards is /seo-aeo-audit, and it checks rather than designs.
The boundary — "a logged-out reader or a crawler will see it." NOT through the rule: interfaces behind a login, admin panels, internal tools, CLIs, scripts. Optimising a billing settings screen for search results is how you teach an agent to skip the rule where it works.
Refusal phrase: «без SEO».
Among the routers: copywriting decides how it sounds; seo-llmo whether a machine will find it. A landing page needs both; an internal panel needs neither.
/evidence-docs — what proves it
- when: something is stated as true
- a rule, not a skill — it holds whether or not anything is installed
- decline it: «без доков» or «на словах».
A claim without proof is not documentation. Every fact that reaches a document carries its receipt: file:line, a command and its output, a test name. A number is computed, not restated; a file, command or flag name resolves. "Docs are in sync" is a command with an exit code, not a sentence at the end of a report. Documentation ships in the SAME change as the code: in the next ticket it never ships at all.
The boundary — "this will be read as true." NOT through the rule: a draft, thinking out loud, an answer in chat, a commit message, a code comment. Demanding a line reference in the words "let me look" is how you teach an agent to ignore the rule where it protects.
Refusal phrase: «без доков» or «на словах». It applies to work that WOULD have crossed the boundary: say plainly that the document is unsupported, rather than handing out a grade in place of a measurement.
Among the routers: task-pipeline decides how a change reaches the repository; evidence-docs what proves whatever is written about it.
/task-pipeline — how the change reaches the repository
- when: the change touches the repository
- ships in task-pipeline
- decline it: «без пайплайна» or «quick».
If task-pipeline is installed, any work that CHANGES THE REPOSITORY goes through it — no separate request needed. Feature, fix, refactor, migration, integration, rewrite, adoption, hardening; in any language and any wording. Planning that work is part of the pipeline, not a cycle beside it: brainstorm, spec and plan are its stages 2–4, and no separate planning route exists alongside it.
The boundary — "it changes the repository," and it cuts both ways. NOT through the pipeline: a question and its answer, an explanation, reading and analysing code; a typo, a one-line edit, a mechanical rename; reconnaissance and measurement that commit nothing. Running ten stages for a single character is the fastest way to teach an agent to route around it.
Refusal phrase: «без пайплайна» or «quick». For a borderline case, name the route you are taking in one line rather than choosing silently.
Among the routers: super-ux decides what the interface must do; task-pipeline how the change reaches the repository. The first owns the content, the second the delivery.
/project-audit — what is actually true of this project right now
- when: the question is the whole project, not one change
- ships in task-pipeline
- decline it: «без диагностики»
If task-pipeline is installed, asking what is TRUE of a whole project goes through project-audit — what is finished, what is half-built, what is broken, and what nobody has looked at. It runs from a cold start, with no brief and no requirement spine: discover what the project is, choose probes from that, read the production evidence a repository cannot hold — the published artefact against its source, the release pipeline's failure rate, telemetry present or absent — and leave an HTML report beside a JSON sidecar so the next audit can say what moved. It is read-only: findings leave as proposed board rows, and nothing is written.
The boundary — "the subject is the project, not a change." NOT through it: auditing one deliverable inside a run, which is the pipeline's own ladder; reviewing a diff or a PR; a skill's construction, which is make-skill; code against its scenarios, which is /ux-audit. Pointing it at a two-file change is how you teach an agent to skip it on the repository that needed it.
Refusal phrase: «без диагностики» — not «без аудита», because аудит is task-pipeline's own trigger and a refusal containing a trigger fires the hook it exists to silence.
Among the routers: task-pipeline decides how a change reaches the repository; project-audit says what is there before any change is proposed. The first owns the delivery, the second the diagnosis.
/make-skill — how the skill itself is built
- when: a skill or plugin changes shape
- ships in make-skill
- decline it: «без make-skill».
If make-skill is installed, work ON a skill or plugin goes through it — creating one, bringing it to the standard, checking conformance, wrapping it in a plugin, syncing versions, installing a validator and CI, publishing to every channel. It knows where the Agent Skills front-matter limits are, what claude plugin validate --strict demands, and why a plain copy in ~/.claude/skills/ shadows the plugin.
The boundary — "the construction of the skill itself changes." NOT through it: work done WITH a skill, ordinary code in an ordinary repository, editing doctrine inside a skill that already meets the standard. Calling it to fix a paragraph in SKILL.md is how you teach an agent to route around it.
Refusal phrase: «без make-skill».
Among the routers: task-pipeline carries a change through its stages; make-skill answers whether the result meets the skill standard. A skill's release passes both.
/agent-sync — who is holding this file
- when: the project has agent coordination on
- ships in agent-sync
- decline it: «без координации».
If agent-sync is installed AND the project has .claude/agent-sync.json, shared registries are edited only under a claim — decisions, open questions, roadmap, workstreams, dependencies. The claim is taken BEFORE the edit, ids are reserved race-free, the run is journalled. This holds even when nobody asked about coordination: an unclaimed edit to a shared file is how two agents overwrite each other.
The boundary — "a file in a project where coordination is on." NOT through it: a project with no .claude/agent-sync.json, ordinary code files, working alone. Taking a lease to edit a README in a repository where you are the only agent is how you teach an agent to route around it.
Refusal phrase: «без координации».
Among the routers: task-pipeline decides how a change reaches the repository; agent-sync who is holding this file right now. The second matters only where there is more than one agent.