Client Vs Internal

---
name: client-vs-internal
description: Use ONLY when docs/audience.md exists (audiences defined during onboarding) OR the operator explicitly asks to optimize a surface for client-facing vs internal use. Steers app surfaces differently — client-facing = simple/guided/trust-first; internal = robust controls/power-features. If docs/audience.md is absent and the operator did not explicitly request the posture check, this skill does nothing (silent no-op) — do NOT create the file. Not for projects without defined audiences.
source_inspiration: conceptual-only
license_status: clean-room-original
fusebase_flow_version: 3.5
risk_level: low
invocation: automatic
expected_outputs:
  - per-surface audience classification (client-facing vs internal)
  - simplicity/robustness guidance applied to the surface being built
  - posture checklist rows persisted as spec ACs (via requirements-specification, alongside QP-xx)
related_workflows:
  - eight-phase-flow.md
hook_dependencies:
  - none
---

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

## 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:**

| ID | Check | Concretely |
|---|---|---|
| C1 | No internal jargon or raw IDs | Labels/errors/emails use the client's domain words; no record IDs, status enums, table names, or team slang on any client-visible string |
| C2 | Confirm before destructive | Delete/cancel/send/submit-final actions show an explicit confirm naming the object + consequence; no one-click irreversible ops (overlaps QP delete-cascade ACs — cite both) |
| C3 | Guided defaults | Happy path completes with pre-filled sensible values and zero configuration; advanced options collapsed behind an explicit affordance |
| C4 | Reassuring empty/error/loading states | Empty = what this is + the first step to take; error = plain words + what to do next, never stack traces or status codes; loading = visible progress (overlaps QP UI-polish patterns — cite both) |
| C5 | No admin affordances | No bulk-delete, impersonation, raw-data export, config, or diagnostics reachable from client routes — removed, not hidden |
| C6 | Portal-embed + permission scoping | Surface works embedded in the client portal (CLI skill `fusebase-portal-specific-apps`); every query scoped to the client's own records — verify the permission model, never assume |

**Internal — robust, efficient, transparent:**

| ID | Check | Concretely |
|---|---|---|
| I1 | Bulk operations | Multi-select + bulk edit/delete/export wherever lists exist |
| I2 | Audit visibility | Who/when/what on records; change history visible, not buried |
| I3 | Keyboard + density efficiency | Dense tables, keyboard nav, fast filters; optimize for repeat power use, not first-run hand-holding |
| I4 | Full error detail | Real causes + IDs surfaced — internal users debug; don't over-soften |

**Shared surfaces (both audiences):**

| ID | Check | Concretely |
|---|---|---|
| S1 | Role-gated affordances | Internal-only controls rendered only for internal roles — gate by permission check, never by CSS hiding or an unlinked route |
| S2 | Progressive disclosure | Client-simple default view; power controls behind an explicit "advanced" affordance that internal roles see |

## Output artifacts

| Artifact | Location | Mode |
|---|---|---|
| Audience classification + posture guidance | chat / design brief | Mode A / Mode-B-lite |
| Posture checklist ACs (C/I/S IDs cited) | `docs/specs/<slug>/spec.md` via `requirements-specification` | Mode B |

## Failure cases

| Failure | Detection | Response |
|---|---|---|
| Artifact absent with no explicit operator request | step 1 | silent no-op (correct) |
| Client surface over-complex | step 6 | flag; recommend simplification |

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