client-vs-internallisted

# Client vs Internal > **Style:** Mode-B-lite. **Artifact-gated** — inert unless `docs/audience.md` exists. ## Purpose Client-facing teams build for two very different audiences. Clients need simplicity and trust (never Salesforce-complex); internal teams need robust controls and power-features. This skill applies the right posture to each surface, using the audiences the operator defined at onboarding. ## When to invoke - `docs/audience.md` exists AND a UI/app surface is being designed or built. - Operator says "is this for clients or internal", "simplify for the client", "this is an internal tool". ## Do not invoke when - **`docs/audience.md` absent** → silent no-op; do not activate or create it. - Non-UI / backend-only work with no audience-facing surface. ## Required inputs | Input | Where it lives | If missing | |---|---|---| | Audience definitions | `docs/audience.md` | **STOP — no-op.** Onboarding (`/onboard`) creates it. | | Surface being built | current task | nothing to classify; exit | ## Procedure 1. **Existence gate (FIRST STEP).** No `docs/audience.md` → exit silently. Do not create it. 2. **Read** `docs/audience.md` (which surfaces are client-facing vs internal; per-audience needs). 3. **Classify** the surface in scope: client-facing, internal, or shared. 4. **Apply posture:** client-facing → simplest viable flow, guided, minimal options, trust-critical interactions real; internal → fuller controls, power-features, admin affordances. 5. **Flag mismat