/omh-data-share-review

name: "omh-data-share-review"
description: "[omh] Before data leaves the team -- a dataset, log, ticket export or transcript excerpt bound for a vendor, a public issue, a model provider or a training corpus: classify every field, minimize first, pseudonymize with the mapping kept local, and call it redacted only after an observed residual scan. Use when the user says: data-share-review, data share review, pii redaction, redact pii, pseudonymize, de-identify, anonymize the dataset, residual pii."
license: MIT
author: "oh-my-hermes maintainers"
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, review]
    category: review
    phase: data-share-review
    role: reviewer
    quality_tier: observed-residual-scan
    related_skills: [omh-legal-compliance-review, omh-security-safety-review, omh-data-analysis, omh-github-issue-intake, omh-model-finetuning, omh-support-operations]

Data Share Review

This is a Hermes-native `data-share-review` workflow skill.

Why This Exists

`data-share-review` exists because data leaving the team had no owner: Hermes redacts identifiers in gateway chat and secrets in tool output, `omh-security-safety-review` reviews an agent's own exposure, and `omh-legal-compliance-review` reads the obligations, while nothing minimized a file's fields, kept its pseudonym mapping local, and refused to call it redacted before a scan of what actually leaves.

First Steps

• Ask where the file goes and what the destination needs it for before touching a field.
• Inventory the fields from the header and the schema before planning any masking.

Do Not Use When

• Whether the data may lawfully leave at all -- the lawful basis, a DPA, consent, or a cross-border transfer -- is a contract and compliance question; use `omh-legal-compliance-review`, then return here for the fields.
• The exposure is an agent's tool permissions, a secret in code, or a prompt-injection path rather than a file about to leave; use `omh-security-safety-review`.
• The ask is analysing the dataset itself -- trends, a cleanup, a chart; use `omh-data-analysis`.
• Filing the issue once its attachment is clean -- the title, labels, and reproduction steps; use `omh-github-issue-intake`.
• Building the training set or deciding whether to train once the corpus is clean; use `omh-model-finetuning`.
• Working the support queue -- triaging or answering tickets rather than exporting them; use `omh-support-operations`.

Examples

Good example:

• Prompt: the analytics vendor wants last month's ticket export, take the customer details out first
• Expected behavior: Ask what the vendor needs, inventory the columns from the header and per-column shape counts, drop the ones it does not need, pseudonymize the customer id with the mapping kept in a local folder, count emails, phone numbers, names, and secrets in the output with a scan that prints counts only, and write the share record.
• Why: A masking step that was never followed by a scan of the shipped file has not shown that anything came out.

Bad example:

• Prompt: I ran find and replace on the emails, so the file is clean, right
• Expected behavior: Hold the verdict at not_observed: count every class in the exact file that leaves, free-text fields included, before calling it redacted.
• Why: A find and replace covers the shapes it was given; names and account numbers in a notes column stay.

Completion Checklist

• Every field has a class and an action, and each kept field names the destination's need for it.
• The pseudonym mapping, if any, sits at a local path outside the shipped file.
• The residual scan ran on the exact file that leaves and counted every class, free text included.
• The verdict is redacted only with that scan observed; otherwise it reads not_observed.
• The share record holds destination, date, fields, row count, and digest, and no value from the file.

Recovery Notes

• If the scan cannot run in this session, hand the user the per-class scan and keep the verdict not_observed until the counts come back.
• If a class still has hits after masking, fix the field or the free text and scan again; never ship on an explained hit that was not accepted by name.

Workflow Lane

• Current lane: **Research and company ops** (`product-docs`, `source-finder`, `web-research`, `research`, `model-optimization`, `inference-serving`, `model-finetuning`, `research-brief`, `+21 more`) - research, signals, ops, and briefings.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `skill_view(name='omh-routing', file_path='references/skill-common-rail.md')`.

When to Use

Use when a dataset, log bundle, ticket or CRM export, or transcript excerpt is about to leave the team -- to a vendor or contractor, a public issue, a model provider, or a training corpus -- and its personal data, identifiers, and secrets must come out first. The output is a field inventory with each field's class, a minimization plan, a residual scan of the file that leaves with counts per class, and a metadata-only record of what left; OMH uploads nothing and keeps no raw data.

Strong routing signals: `data-share-review`, `data share review`, `pii redaction`, `redact pii`, `pseudonymize`, `de-identify`, `anonymize the dataset`, `residual pii`, `redact the pii`, `redact personal data`, `strip pii`, `strip the pii`, `remove pii`, `remove the pii`, `scrub pii`, `scrub the pii`, `mask pii`, `mask personal data`, `remove personal data`, `scan for pii`, `pseudonymise`, `pseudonymizing`, `pseudonymization`, `pseudonymisation`, `de-identifying`, `deidentify`, `quasi-identifier`, `quasi-identifiers`, `direct identifiers`, `anonymize this dataset`, `anonymize the data`, `anonymize the logs`, `redact the logs`, `redact these logs`, `개인정보`, `개인 정보`, `고객 정보`, `고객정보`, `민감정보`, `민감 정보`, `식별 정보`, `식별정보`, `식별자`, `주민번호`, `주민등록번호`, `전화번호`, `연락처`, `계좌번호`, `카드번호`, `실명`, `이메일 주소`,