super-ux

Shape: static. The chain is fixed — foundation, flows, screens, scenarios — and every layer is a committed file. `/ux-audit` batches on the fly, and the batch list is printed before the run so what executed is recoverable.

vision

Use when a project needs the layer ABOVE personas and jobs - what the product IS, why it exists, and what it refuses to become. Writes docs/ux/vision.md in nine layers (essence, core idea, system behaviour, user role, principles, anti-vision, horizon, the one sentence, and the alignment test) and installs a vision-alignment rule into the project's own instruction file so later features get checked against it.

ux-foundation

Use when defining or revising WHO the users are and WHY they use the product - personas, Jobs to Be Done, customer journey maps, user stories with acceptance criteria. A journey covers the end-to-end experience including what happens after the first session - where a user comes back, where user retention is won, and where churn actually starts. Maintains docs/ux/foundation.md, the WHY layer that UX scenarios trace to.

ux-flows

Use when designing or improving HOW users move through the product - user flows, a screen and its states, wireframes, Figma mockups, task analysis, heuristic UX evaluation and redesign proposals. A paid-acquisition funnel is one of these flows - its step chain, branches and paywall step, read against reference screens from the same category. Maintains docs/ux/flows.md between foundation (stories) and scenarios. Visual system and Figma variables belong to sheleg-design.

ux-scenarios

Use when creating or updating UX scenarios, starting ANY new feature or project (an empty project starts a layer up, with vision and ux-foundation), making ANY change to user-facing behavior, or onboarding an existing codebase into scenario-driven development. Maintains docs/ux/scenarios.md as the source of truth for all user-facing behavior.

ux-audit

Use when verifying the codebase against the UX scenario base - runs a batched, evidence-backed scenario audit and writes a versioned report to docs/ux/audits/.

brand-voice

Use when defining, calibrating or checking how a product speaks — tone of voice, brand voice, verbal identity, the words the product owns and the words it bans, canonical facts, per-surface register, locales. For writing the actual text, see copywriting.

copywriting

Use when writing, rewriting or editing any text a user will read — interface strings, buttons, errors, empty states, landing and pricing pages, app store listings, blog posts, changelogs, social posts and captions, short-video scripts and their hooks, ads, lifecycle email. For defining the voice itself, see brand-voice.

/super-ux — what the interface must do

• when: there is user-facing behaviour
• 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.

/copywriting — how it sounds

• when: text a user of the product will read
• 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.