skills/privacy-surface-review/SKILL.md

---
name: privacy-surface-review
description: Use when adding, changing, reviewing, or releasing a Clara workflow or hosted integration to record what Codex can read, every boundary beyond Codex, and the source-backed access and retention position before packaging.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Privacy Surface Review

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

Do not initiate feedback merely because this release check was run.

This is a developer and release workflow. It is not a customer-case intake step.
A normal Clara run does not display a privacy notice or ask for privacy consent
merely because Codex reads professional material.

## Review workflow

1. Resolve the Clara root and list every sibling directory in `skills/` that has
   a `SKILL.md`. Every user-facing workflow except this review skill must have a
   matching record in `privacy/workflows/`.
2. Read the workflow's complete skill and every relevant script, reference,
   payload builder, connector, browser route, and embedded component. For
   Attribute Reporting and Brand Fit, resolve `modules/attribute-reporting` in a
   packaged plugin or the sibling repository component.
3. Record the information that may enter Codex context. Real client, participant,
   employee, source, transcript, deck, and business data may enter that context.
   Do not describe model-read material as local-only because its source file or
   final artifact remains on the user's computer.
   For ordinary Codex model processing, keep the common policy explicit: the
   user-selected ChatGPT/Codex account is the processing arrangement; Clara adds
   no separate recipient, does not automatically anonymise, and may filter or
   aggregate locally only when useful. Clara cannot inspect or enforce the plan.
4. Record every boundary beyond Codex in the workflow manifest. Link every
   Mparanza route to one record in `privacy/hosted-services/`. Public research,
   public image retrieval, external connectors, and send or publish actions stay
   in the workflow manifest.
5. For a hosted service, record only payload, access, and retention facts that
   inspected governed source supports, including the relevant Mparanza service
   and legal copy. If those sources do not establish hosted retention or
   deletion, say so. Link expiry is not proof that stored material is deleted.
6. The user's explicit choice of a hosted, connector, send, or publish route is
   the confirmation for that route. Ask separately only when the external action
   is optional and the user has not already chosen it. Do not ask twice.
7. Record only source-enforced security controls and the user's ChatGPT/Codex
   account boundary. An empty security-control array is accurate when the
   workflow has no control of its own. Do not relabel local storage, output
   review, source preservation, ordinary route choice, policy wording, or a
   procedural instruction as security. Clara cannot inspect or enforce the
   user's plan, model-training data controls, or retention/deletion controls. The
   firm or user checks those before professional use and when the account or
   terms change, not in a per-case form.
8. Update the workflow and hosted-service manifests, then refresh only after the
   substantive review is complete:

```bash
python skills/privacy-surface-review/scripts/validate_privacy_surfaces.py \
  --refresh <workflow-or-service-id>
```

9. Validate the complete register and run the Clara privacy tests before
   packaging:

```bash
python skills/privacy-surface-review/scripts/validate_privacy_surfaces.py
pytest -q tests/plugins/test_clara_privacy_surfaces.py
```

## Judgment boundary

Use deterministic code for registered-workflow coverage, JSON shape, allowed
boundary kinds, hosted-service references, confirmation consistency, exact file
hashing, and stale-review detection.

Do not add automatic anonymisation, personal-data detection, deterministic
deletion, a `minimum useful context` classifier, per-prompt declarations, or
routine consent screens. Local Python may filter or aggregate information when
that improves the professional work; that is not a claim that everything read
by Codex was anonymised.

This register is an engineering record. It is not legal advice, a DPIA, an
account-configuration audit, or a certification of GDPR compliance.

## Codex-Native Run UX

Keep a short developer checklist for workflow coverage, hosted-service coverage,
source review, fingerprint refresh, schema validation, and focused tests.

Before source review, show a compact Run Intake table with the changed workflow
or service ID, governed paths, related manifests, and whether the change adds or
alters a boundary beyond Codex. Show a Decision Table only when source evidence
leaves a real boundary, access, or retention fact unresolved; record an unknown
instead of guessing.

Default output policy: update the affected manifest, refresh its fingerprint,
and validate the complete register. These are not choices to propose when the
user asks for the normal privacy-surface review.

Before refreshing fingerprints, use one execution checkpoint naming the changed
workflow or service, governed paths, and manifests. Never edit generated ZIPs by
hand; release artifacts are rebuilt from source.

End with an Artifact Card listing the validated register, any intentionally
unknown hosted arrangement, and the test result. Create `codex_run_review.md`
only when the review needs a local note about blocked source evidence, a schema
gap, or repeated manual cleanup. Do not create customer-facing notices or case
artifacts.