client-vs-internal

Client vs Internal

Style: Mode-B-lite. Artifact-gated by default — inert unless docs/audience.md exists or the operator explicitly requests the posture check.

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 defined at onboarding (or the audience the operator states when explicitly requesting the check).

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 and no explicit operator request → 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 or the audience stated in an explicit operator posture-check request	STOP — no-op only when both are absent. Do not create the file; onboarding (/onboard) creates it.
Surface being built	current task	nothing to classify; exit

Procedure

1. Existence gate (FIRST STEP). No docs/audience.md and no explicit operator posture-check request → exit silently. If the operator explicitly requested the check and stated the audience, continue with that audience without creating the file.
2. Read docs/audience.md when present (which surfaces are client-facing vs internal; per-audience needs); otherwise use the audience stated in the explicit operator request.
3. Classify the surface in scope: client-facing, internal, or shared.
4. Apply the matching posture checklist (§ Posture checklists below): client-facing, internal, or shared — walk every row for the surface in scope; each row is pass / fail / N-A, not vibes.
5. Persist — the classification must not evaporate in chat. If a spec is in flight (or being drafted) for this surface, hand the result to requirements-specification: the posture + each applicable checklist row becomes a numbered spec AC citing its ID (e.g., "AC7 — client-facing surface: destructive actions confirm with object + consequence before executing (client-vs-internal C2)"), alongside the QP-xx ACs from app-quality-patterns (C2/C4 overlap the QP delete-policy and empty/loading/error patterns — cite both IDs on one AC line, don't duplicate the AC). No spec in flight → record posture + failed rows in the design brief or change-note so Implement and code-review inherit them.
6. Flag mismatches (e.g. exposing internal complexity to a client surface) and recommend the audience-appropriate alternative.
7. Ambiguous audience → ask the operator (FR-19).