Source profileQuality 84/100

maziyarpanahi/openmed/skills/authoring-model-cards/SKILL.md

authoring-model-cards

Generate a model card for an OpenMed clinical NER or de-identification model documenting intended use, quantitative metrics, subgroup performance, limitations, and a medical-device disclaimer for clinical AI governance. Use when the user wants to write or update a model card, a README model section, or governance documentation, or to turn OpenMed eval outputs (release gate report, fairness_report, error_report) into the card's metrics and limitations sections. Trigger on "model card", "intended

Source repository stars
4,847
Declared platforms
0
Static risk flags
0
Last source update
2026-08-04
Source checked
2026-08-04

Decision brief

What it does—and where it fits

A model card is the honest spec sheet for a model: what it's for, how well it works, where it breaks, and who it might fail. For clinical models this is governance-critical — an undocumented de-id model is one nobody can sign off on. This skill fills a model card directly from O…

Best for

  • You're publishing or updating an OpenMed model and need its card.
  • You have eval artifacts (GateReport, fairnessreport, errorreport) and
  • A clinical AI governance / model-risk review needs a transparency document.

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/maziyarpanahi/openmed --skill "skills/authoring-model-cards"
Safe inspection promptEditorial

Inspect the Agent Skill "authoring-model-cards" from https://github.com/maziyarpanahi/openmed/blob/e412ae8f3b04ae79b13663d34a422efc22109a3a/skills/authoring-model-cards/SKILL.md at commit e412ae8f3b04ae79b13663d34a422efc22109a3a. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Quick start — fill the card from eval outputs

    python from openmed.eval import ( runsuite, ReleaseGate, fairnessreport, errorreport, )

    python from openmed.eval import ( runsuite, ReleaseGate, fairnessreport, errorreport, )report = runsuite("eval/gold/test.json", suite="golden", modelname="OpenMed/Privacy-PII-Detection", device="cpu", metadata={"family": "PII", "tier": "base", "policy": "hipaasafeharbor"})gate = ReleaseGate(milestone="v1.6", policy="hipaasafeharbor").evaluate(report) fair = fairnessreport("OpenMed/Privacy-PII-Detection", "golden") errs = errorreport("OpenMed/Privacy-PII-Detection", "eval/gold/test.json")
  2. 02

    Workflow

    1. Gather artifacts. Gate report, fairness report, error report — all from a pinned model + synthetic eval set. 2. Fill model details from the GateReport identity fields so the card, models.jsonl, and the README cannot drift (the gate's manifestcoherence and modelcard checks enf…

    Gather artifacts. Gate report, fairness report, error report — all from aFill model details from the GateReport identity fields so the card,Write intended use narrowly. Name the clinical task, language(s), and the
  3. 03

    When to use this skill

    Run the evals first (see evaluating-with-leakage-gates, benchmarking-clinical-ner, auditing-subgroup-fairness); this skill documents their results — it does not generate the numbers.

    You're publishing or updating an OpenMed model and need its card.You have eval artifacts (GateReport, fairnessreport, errorreport) andA clinical AI governance / model-risk review needs a transparency document.
  4. 04

    Card sections (Mitchell et al., + clinical extensions)

    See references/model-card-sections.md for the full section-to-source map. The load-bearing sections for an OpenMed model:

    Model details — repo id, family, tier, format, params, milestone, licenseIntended use — the clinical task and the deployment envelope.Out-of-scope / misuse — explicitly: not a medical device; not for autonomous
  5. 05

    Render card into Markdown front matter + body (or the HF card template).

    errorreport and fairnessreport carry no plaintext PHI (offsets + hashes), so their output is safe to paste into a public card.

    Gather artifacts. Gate report, fairness report, error report — all from aFill model details from the GateReport identity fields so the card,Write intended use narrowly. Name the clinical task, language(s), and the

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score84/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars4,847SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
maziyarpanahi/openmed
Skill path
skills/authoring-model-cards/SKILL.md
Commit
e412ae8f3b04ae79b13663d34a422efc22109a3a
License
Apache-2.0
Collected
2026-08-04
Default branch
master
View the original SKILL.md

Authoring Model Cards

A model card is the honest spec sheet for a model: what it's for, how well it works, where it breaks, and who it might fail. For clinical models this is governance-critical — an undocumented de-id model is one nobody can sign off on. This skill fills a model card directly from OpenMed eval outputs so the numbers are reproducible, not aspirational.

When to use this skill

  • You're publishing or updating an OpenMed model and need its card.
  • You have eval artifacts (GateReport, fairness_report, error_report) and need to turn them into intended-use, metrics, and limitations sections.
  • A clinical AI governance / model-risk review needs a transparency document.

Run the evals first (see evaluating-with-leakage-gates, benchmarking-clinical-ner, auditing-subgroup-fairness); this skill documents their results — it does not generate the numbers.

Card sections (Mitchell et al., + clinical extensions)

See references/model-card-sections.md for the full section-to-source map. The load-bearing sections for an OpenMed model:

  • Model details — repo id, family, tier, format, params, milestone, license (Apache-2.0). Pull from the GateReport identity fields.
  • Intended use — the clinical task and the deployment envelope.
  • Out-of-scope / misuse — explicitly: not a medical device; not for autonomous clinical decisions; de-id is verified, not assumed.
  • Metrics — entity-level P/R/F1 and, for de-id, residual leakage + per-label recall floors and the gate decision.
  • Quantitative analysis (subgroups) — per-group leakage/recall from fairness_report, including which groups lack data.
  • Limitations — error patterns from error_report; calibration assumptions.
  • Caveats & disclaimer — the medical-device disclaimer.

Quick start — fill the card from eval outputs

from openmed.eval import (
    run_suite, ReleaseGate, fairness_report, error_report,
)

report = run_suite("eval/gold/test.json", suite="golden",
                   model_name="OpenMed/Privacy-PII-Detection", device="cpu",
                   metadata={"family": "PII", "tier": "base",
                             "policy": "hipaa_safe_harbor"})

gate = ReleaseGate(milestone="v1.6", policy="hipaa_safe_harbor").evaluate(report)
fair = fairness_report("OpenMed/Privacy-PII-Detection", "golden")
errs = error_report("OpenMed/Privacy-PII-Detection", "eval/gold/test.json")

card = {
    "model_details": {
        "repo_id": gate.repo_id, "family": gate.family, "tier": gate.tier,
        "format": gate.format, "license": "Apache-2.0",
    },
    "metrics": {
        "exact_span_f1": report.metrics["exact_span_f1"]["f1"],
        "residual_leakage_rate": gate.residual_leakage_rate,
        "critical_leakage_count": gate.critical_leakage_count,
        "per_label_recall": dict(gate.per_label_recall),
        "release_decision": gate.decision,            # RELEASABLE / QUARANTINED
    },
    "subgroup_analysis": fair.to_dict(),              # per-group leakage/recall
    "limitations": errs.to_dict()["confusion_matrix"],
}
# Render `card` into Markdown front matter + body (or the HF card template).

error_report and fairness_report carry no plaintext PHI (offsets + hashes), so their output is safe to paste into a public card.

Workflow

  1. Gather artifacts. Gate report, fairness report, error report — all from a pinned model + synthetic eval set.
  2. Fill model details from the GateReport identity fields so the card, models.jsonl, and the README cannot drift (the gate's manifest_coherence and model_card checks enforce this).
  3. Write intended use narrowly. Name the clinical task, language(s), and the deployment envelope. Over-broad intended-use is the most common card failure.
  4. State out-of-scope and the disclaimer plainly (see template below).
  5. Report metrics with their floors. For de-id, lead with leakage and the gate decision, not F1.
  6. Report subgroups honestly, including the documentation gap: if race/ ethnicity isn't available, say so rather than implying parity.
  7. List limitations from real errors, not boilerplate — cite the confusion matrix's worst cells.

Disclaimer block (paste & adapt)

This model assists clinical text processing and is not a medical device. It does not make autonomous clinical decisions. De-identification output must be independently verified before any data is shared; residual PHI risk is never zero. Validate on your own population before deployment.

Hand-off to / from OpenMed

  • From evaluating-with-leakage-gates (GateReport), benchmarking-clinical-ner (error_report), and auditing-subgroup-fairness (fairness_report): these are the card's evidence.
  • To building-with-openmed / models.jsonl: keep card front matter (license, task, languages) coherent with the manifest — the gate checks it.
  • Pairs with gating-deid-leakage: cite the green gate as the card's release evidence.

Edge cases & gotchas

  • Don't claim numbers you can't reproduce. Every metric in the card should trace to an eval artifact and a pinned eval-set hash.
  • Intended use ≠ capability. Document the supported envelope; mark everything else out-of-scope.
  • Subgroup silence is a finding. Omitting race because it wasn't collected is itself a limitation to state — don't let absence read as equity.
  • Card/manifest drift fails the gate. License/task/language mismatches between the card and models.jsonl trip manifest_coherence.
  • No raw PHI examples. Use the offset/hash examples from error_report; never paste real patient strings as "qualitative examples".
  • Quantized variants need their own line. Report INT8/INT4 recall deltas (G4) per format; don't reuse the fp32 numbers.

Standards & references

Alternatives

Compare before choosing