14 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, errors, sign-in or speed is being wired | sheleg-dev |
| agent-stack | how an agent system is built, judged and metered — and the wire it speaks outward | the thing being built is an agent, or a server one connects to | agent-stack |
| telegram-dev | which Telegram API a surface speaks, and what it costs | the thing being built lives inside Telegram | telegram-dev |
| xr-dev | how a Quest product moves from platform choice to launch and operation | the thing being built runs on a Meta Quest headset | xr-dev |
| web3d-dev | how a realtime 3D scene on the web runs, ships its assets and moves | a three.js or React Three Fiber scene renders in the page | web3d-dev |
| 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: no scenarios
If super-ux is installed, ALL product/interface work goes through its chain, scenarios first — decisions, funnels, onboarding, payments: any user and path. docs/ux/scenarios.md owns truth; absent → offer /ux before UI. Update scenarios in the SAME user-facing change; /ux-audit checks code with file:line.
The boundary. NOT through it: internal scripts, interface-free migrations, data work, infrastructure.
Refusal phrase: "no scenarios" or «без сценариев».
Among the routers: super-ux owns what the interface does; sheleg-design its look; copywriting its sound.
/sheleg-design — how it looks and moves
- when: there is a visual layer
- ships in sheleg-design
- decline it: no design
If sheleg-design is installed, the visual layer goes through it — all surfaces: tokens/themes, typography/rhythm, motion and calm fallback, brand, Figma variables and design-to-code without hand-copied values. Before design/redesign/layout/front-end/mobile UI, run npx sshlg-skills pack design: lane owners and exact missing-tool install commands; reports, never installs. Accessibility has NO family owner; listed tools are not additional entry points.
The boundary — "HOW it looks is being decided." NOT through it: structure (super-ux), text (copywriting), backend, internal scripts.
Refusal phrase: "no design" or «без дизайна».
Among the routers: super-ux owns the wireframe; sheleg-design the visual layer and motion.
/copywriting — how it sounds
- when: text a user of the product will read
- ships in super-ux
- decline it: no brand or draft it
If super-ux is installed, product-facing text goes through copywriting — UI strings/errors/empty states, landing pages, pricing, blog, changelog, posts, store listings, ads, email. First read docs/brand/voice.md, terminology.md, facts.md; absent pack → /brand-init before writing.
The boundary — "it ships to a user of the product." NOT through it: commit/PR descriptions, code comments, developer README, internal docs, an answer in chat.
Refusal phrase: "no brand" or "draft it" — «без бренда», «черновиком». For otherwise in-scope work, write directly and disclose the requested pack skip.
Among the routers: sheleg-design owns looks, copywriting words; both run independently from shared scenarios; compare their outputs on a shared screen before shipping. A landing page takes both plus task-pipeline; a social post takes copywriting alone, no repo change.
/sheleg-dev — what it runs on to charge, track and sign in
- when: money, tracking, errors, sign-in or speed is being wired
- ships in sheleg-dev
- decline it: no wiring
If sheleg-dev is installed, WIRING integrations goes through it — cards (stripe-billing), crypto (crypto-payments), pixels/server events (ad-tracking), errors (error-tracking), sign-in (google-signin, google-auth), speed (frontend-performance). The webhook proves payment; the redirect only a browser. Share one event_id across both event channels or count revenue twice.
The boundary. NOT through it: paywall behavior/tiers (super-ux), checkout look (sheleg-design), words (copywriting), price (a business decision, never a skill's).
Refusal phrase: "no wiring" or «без обвязки» — avoid «без интеграций»: интеграция triggers task-pipeline.
Among the routers: super-ux owns the payment step; sheleg-dev its charge.
/agent-stack — how an agent system is built, judged and metered — and the wire it speaks outward
- when: the thing being built is an agent, or a server one connects to
- ships in agent-stack
- decline it: no agent layer
If agent-stack is installed, building an agent SYSTEM goes through it — loops/work-graphs, system prompts/tools, workflow vs agent, evals, MCP/A2A, registry/gateway, and the wallet behind resold LLM access.
The boundary. NOT through it: one LLM call in a script, one prompt's wording, person-facing UI (super-ux, sheleg-design), charging money (sheleg-dev), agents editing THIS repo (agent-sync). sheleg-dev charges; agent-stack meters LLM use.
Refusal phrase: "no agent layer" or «без агентного слоя».
Among the routers: agent-sync coordinates file ownership; agent-stack owns the agent system being built.
/telegram-dev — which Telegram API a surface speaks, and what it costs
- when: the thing being built lives inside Telegram
- ships in telegram-dev
- decline it: no telegram
If telegram-dev is installed, Telegram surfaces go through it — Bot API bots, MTProto accounts, Mini Apps. update_id is an update's only idempotency key; a session file is a logged-in person, revocable and bannable. For Mini Apps, validate raw initData on the backend; never trust initDataUnsafe.
The boundary — "Telegram is the platform, not the transport." NOT through it: a one-call bot alert to yourself, bot behavior (super-ux), Mini App look (sheleg-design), card charges (sheleg-dev).
Refusal phrase: "no telegram" or «без телеграма».
Among the routers: sheleg-dev owns card rails; telegram-dev owns Stars, bot tokens, accounts and their risks.
/xr-dev — how a Quest product moves from platform choice to launch and operation
- when: the thing being built runs on a Meta Quest headset
- ships in xr-dev
- decline it: no xr
If xr-dev is installed, Meta Quest products go through it — native OpenXR/Spatial SDK/WebXR choice, frame budget per refresh rate, toolchain, headset, Store submission, monetization, launch and operation. quest-lifecycle maps each stage to an owner, evidence and next action.
The boundary. NOT through it: ordinary browser 3D (web3d-dev), phone/desktop apps, Unity/Unreal internals (vendor skills), delivery (task-pipeline).
Refusal phrase: "no xr" or «без xr».
Among the routers: web3d-dev owns web scenes; xr-dev their headset lifecycle. A three.js scene in Quest Browser takes both.
/web3d-dev — how a realtime 3D scene on the web runs, ships its assets and moves
- when: a three.js or React Three Fiber scene renders in the page
- ships in web3d-dev
- decline it: no web3d
If web3d-dev is installed, realtime web 3D goes through it — three.js/React Three Fiber runtime (web3d-runtime: WebGPU/WebGL2 fallback, TSL, compute, frame loop), assets within a written budget (web3d-assets: glTF, KTX2, meshopt, licences), animation (web3d-animation: rigs, clips, blending, retargeting). Pin every fact to one three.js release.
The boundary. NOT through it: scroll motion/heroes (sheleg-design), rendered video, headset sessions (xr-dev), Unity/Unreal.
Refusal phrase: "no web3d" or «без web3d».
Among the routers: sheleg-design owns the page's look/motion; web3d-dev its embedded 3D scene.
/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: no SEO
Design every public web surface for humans AND machines, AT DESIGN TIME — URLs/hierarchy, one question per page, JS-free extractable answers, markup, entities, single-home facts, explanatory internal links. /seo-aeo-audit checks afterwards, never designs; seo-llmo is a standing rule in no pack.
The boundary. NOT through it: logged-in interfaces, admin panels, internal tools, CLIs, scripts.
Refusal phrase: "no SEO" or «без SEO».
Among the routers: copywriting owns sound, seo-llmo discoverability. Landing pages need both; internal panels 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: no docs or on my word
Every documented fact needs proof: file:line, a command with output, or a test name. Compute numbers; resolve every named file/command/flag; "docs are in sync" requires an exit code. Ship docs in the SAME change as code.
The boundary — "this will be read as true." NOT through it: drafts, thinking aloud, an answer in chat, commit messages, code comments.
Refusal phrase: "no docs" or "on my word" — «без доков», «на словах». For otherwise in-scope work, state that the document is unsupported.
Among the routers: task-pipeline owns delivery; evidence-docs its proof.
/task-pipeline — how the change reaches the repository
- when: the change touches the repository
- ships in task-pipeline
- decline it: no pipeline
If task-pipeline is installed, substantial repository changes go through it — feature, fix, refactor, migration, integration, rewrite, adoption, hardening, in any language. Planning is part of the pipeline: brainstorm, spec and plan occupy stages 2–4, never a parallel planning cycle.
The boundary. NOT through it: questions, explanations, reading/analysing code; typos, one-line edits, mechanical renames; reconnaissance/measurement that commit nothing.
Refusal phrase: "no pipeline" or «без пайплайна». Name the chosen route for borderline cases.
Among the routers: super-ux owns interface behavior; task-pipeline 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: no diagnosis
If task-pipeline is installed, whole-project truth goes through project-audit — finished, partial, broken or unexplored. Cold start/no brief: discover the project and production evidence beyond Git; produce HTML + JSON. Read-only: findings become proposed board rows, not project edits.
The boundary. NOT through it: a run's deliverable audit, diff/PR review, skill construction (make-skill), code vs scenarios (/ux-audit).
Refusal phrase: "no diagnosis" or «без диагностики» — avoid «без аудита»: аудит triggers task-pipeline.
Among the routers: project-audit diagnoses before changes; task-pipeline delivers them.
/make-skill — how the skill itself is built
- when: a skill or plugin changes shape
- ships in make-skill
- decline it: no make-skill
If make-skill is installed, skill/plugin construction goes through it — create, retrofit, conformance audit («аудит скилов»), plugin wrapping, version sync, validator+CI, all-channel publication. It owns front-matter limits, claude plugin validate --strict, and plain ~/.claude/skills/ shadowing.
The boundary. NOT through it: USING a skill, ordinary repo code, doctrine edits in a conformant skill.
Refusal phrase: "no make-skill" or «без make-skill».
Among the routers: make-skill checks construction; task-pipeline delivers. A skill release takes both.
/agent-sync — who is holding this file
- when: the project has agent coordination on
- ships in agent-sync
- decline it: no coordination
If agent-sync is installed AND .claude/agent-sync.json exists, claim shared registries BEFORE editing — decisions, open questions, roadmap, workstreams, dependencies. Reserve ids race-free and journal the run, even without a coordination request.
The boundary. NOT through it: projects without that config, ordinary code files, working alone.
Refusal phrase: "no coordination" or «без координации».
Among the routers: task-pipeline owns delivery; agent-sync file ownership when multiple agents work.