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

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).

Worked example

Operator: "This billing settings page is client-facing; run the posture check."

1. Classify Billing settings as client-facing from the explicit request.
2. Apply C2 because cancellation is destructive.
3. Spec AC: AC4 — Cancellation confirms the subscription and consequence before executing (client-vs-internal C2).

Output: client-facing posture + AC4 handed to requirements-specification.

Posture checklists

Apply per classified surface. Row IDs (C/I/S-n) are citable in spec ACs (step 5).

Client-facing — simple, guided, trust-first:

Internal — robust, efficient, transparent:

Shared surfaces (both audiences):

Output artifacts

Failure cases

Escalation path

• Ambiguous audience → ask operator (FR-19).
• Audience model needs updating → project-onboarding.

Anti-patterns

• Do not activate when docs/audience.md is absent unless the operator explicitly requests the posture check and states the audience; never create the file from this skill.
• Do not make client surfaces Salesforce-complex.
• Do not strip necessary controls from internal surfaces for "simplicity".
• Do not leave the classification chat-only when a spec is in flight — posture rows become ACs (step 5) or they evaporate.

Clean-room note

Original Fusebase Flow content. See docs/source-map.md. No third-party code, prompts, or skill files copied.