CtrlK
BlogDocsLog inGet started
Tessl Logo

auditing-deidentification-runs

Produce a signed, reproducible, no-PHI audit trail for an OpenMed de-identification run via deidentify(audit=True). Use when the user needs compliance evidence, a tamper-evident record of what was redacted and why, to verify nothing was changed, to retain proof for HIPAA/GDPR audits, or to review de-id decisions without exposing plaintext PHI. Covers the AuditReport / AuditSignature / AuditSpan / DetectorInfo fields, why audits store offsets+hashes+provenance+residual-risk and never plaintext, signing with .sign(key), and verifying with .verify(key). Pairs with OpenMed deidentifying-clinical-text and auditing-safe-harbor-checklist.

73

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

88%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is actionable and well-sequenced with explicit validation checkpoints, and avoids generic padding. The main gaps are minor: a few rationale paragraphs could be tightened, and the inlined field-reference table could be split into a bundle file for cleaner progressive disclosure.

Suggestions

Tighten the 'Why audits store offsets + hashes + provenance, never plaintext' section to a few bullets, trimming rationale prose that repeats the design intent.

Move the AuditReport/AuditSpan/DetectorInfo/AuditSignature field listings into a separate references file (e.g., AUDIT_FIELDS.md) and link to it one level deep, keeping only the most-used fields inline.

Consider a short 'verifying an existing report' sub-example that loads deid_audit.json back into an AuditReport before calling .verify(), since the quick start only covers verify on the in-memory object.

DimensionReasoningScore

Conciseness

Largely efficient and free of generic-concept padding, but a few rationale paragraphs (e.g., 'The whole point of de-identification is to not retain identifiers') slightly over-explain skill-specific context that could be trimmed.

4 / 5

Actionability

The quick start provides fully executable, copy-paste-ready code covering the common sign/verify/persist end-to-end case, supplemented by concrete field tables and specific API calls.

5 / 5

Workflow Clarity

The six-step workflow has explicit validation checkpoints (inspect residual_risk before release, verify on retrieval) and a feedback loop (cross-check with the safe-harbor checklist), satisfying the top anchor.

5 / 5

Progressive Disclosure

Well-organized into clear sections, but at ~130 lines it exceeds the under-50-line simple-skill exception and inlines a sizable field-reference table that could live in a separate bundle file with one-level-deep navigation.

4 / 5

Total

18

/

20

Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is specific, complete, and distinctive, clearly stating both what the skill does and when to use it with concrete trigger phrases. Its only minor weakness is trigger-term breadth, where a few natural synonyms or extension cues could be added.

DimensionReasoningScore

Specificity

Lists multiple concrete actions ('Produce a signed, reproducible, no-PHI audit trail', 'signing with .sign(key)', 'verifying with .verify(key)', 'review de-id decisions') with comprehensive coverage, matching the anchor for multiple specific concrete actions.

5 / 5

Completeness

Explicitly answers both what ('Produce a signed, reproducible, no-PHI audit trail...') and when ('Use when the user needs compliance evidence... HIPAA/GDPR audits...') with concrete trigger phrases.

5 / 5

Trigger Term Quality

Good natural keyword coverage ('compliance evidence', 'HIPAA/GDPR audits', 'tamper-evident record', 'verify nothing was changed') but lacks the synonym/extension breadth of the top anchor; a few natural variations are missing.

4 / 5

Distinctiveness Conflict Risk

A clear niche (OpenMed de-identification auditing) with distinct triggers and named sibling skills, giving minimal conflict risk with other skills.

5 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
maziyarpanahi/openmed
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.