CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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 use", "model documentation", "governance", "limitations section", "datasheet", or "FDA/ONC transparency" for an OpenMed model.

71

Quality

89%

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

78%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 a well-structured, domain-specific guide: a runnable quick start, a concrete seven-step workflow, and genuinely non-obvious gotchas (subgroup silence as a finding, no raw PHI, quantized variants need their own line) with no filler concepts. Weakest spots are the unspecified final render step, the missing intended-use section in the example card, and validation being delegated to the gate rather than stated as an explicit checkpoint.

Suggestions

Make the final step of the Quick start concrete instead of a comment — e.g. show the one-liner or small function that renders the `card` dict into the card front matter + body, or name the HF card template to use.

Add the `intended_use` and `out_of_scope` keys to the example `card` dict (or point to where their text comes from), since the workflow calls them the most common failure mode and the example currently stops at metrics.

Insert an explicit validation checkpoint in the workflow, e.g. "before finishing, re-run the gate's `manifest_coherence` / `model_card` checks and confirm license/task/languages match `models.jsonl`" with a fix-and-retry loop, rather than only noting that the gate enforces it.

DimensionReasoningScore

Conciseness

The body is dense and assumes competence — field names, gate checks, and gotchas with no padding — but the intro spends a few sentences on motivational framing Claude does not need ("A model card is the honest spec sheet for a model: what it's for, how well it works, where it breaks" and "an undocumented de-id model is one nobody can sign off on"). Trimming that editorial framing would reach the lean anchor.

4 / 5

Actionability

The Quick start is near copy-paste ready — full imports, concrete `run_suite`/`ReleaseGate`/`fairness_report`/`error_report` calls with arguments, and an explicit card dict mapping fields to sources — plus a paste-and-adapt disclaimer block. Minor gaps keep it below the top anchor: the final rendering step is only a comment ("# Render `card` into Markdown front matter + body") and the example dict omits the intended-use / out-of-scope sections the workflow itself calls load-bearing.

4 / 5

Workflow Clarity

The 7-step workflow is clearly sequenced with prerequisites stated up front ("Run the evals first") and each step named concretely ("Fill model details from the GateReport identity fields", "Report metrics with their floors"). Validation is delegated to external gate checks ("manifest_coherence and model_card checks enforce this", "Card/manifest drift fails the gate") rather than given as an explicit inline verify-then-fix checkpoint, which is a minor gap against the explicit-feedback-loop anchor.

4 / 5

Progressive Disclosure

A clean overview structure with one clearly signaled, one-level-deep reference: "See `references/model-card-sections.md` for the full section-to-source map" and the file exists with exactly that content, so the full section table lives out of line while the body keeps a concise summary. External standards links are appropriately separated and the body stays navigable.

5 / 5

Total

17

/

20

Passed

Description

96%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.

A strong description: it states a concrete, multi-part deliverable, gives both an explicit "Use when" clause and a separate trigger-term list with good synonyms, and scopes itself to the OpenMed domain. The only weakness is that a couple of the trigger terms ("governance", "model documentation") are broad enough to overlap with general documentation/governance skills outside the OpenMed niche.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — "Generate a model card ... documenting intended use, quantitative metrics, subgroup performance, limitations, and a medical-device disclaimer" and "turn OpenMed eval outputs (release gate report, fairness_report, error_report) into the card's metrics and limitations sections" — covering the deliverable comprehensively with no vague filler. Voice is third-person throughout ("Generate", "Use when the user wants"), so no person-voice penalty applies.

5 / 5

Completeness

Explicitly answers both questions: the "what" is generating a model card with named sections and the "when" is stated twice — "Use when the user wants to write or update a model card ... or governance documentation, or to turn OpenMed eval outputs ... into the card's metrics and limitations sections" plus an explicit trigger list. This matches the top anchor exactly.

5 / 5

Trigger Term Quality

Natural trigger coverage is comprehensive and includes synonyms users would actually say: "model card", "intended use", "model documentation", "governance", "limitations section", "datasheet", "FDA/ONC transparency", plus phrasing like "write or update a model card, a README model section, or governance documentation". No relevant natural term is obviously missing.

5 / 5

Distinctiveness Conflict Risk

The niche is clear — twice scoped to "an OpenMed clinical NER or de-identification model" and the trigger list ends with "for an OpenMed model" — with distinctive triggers like "datasheet" and "FDA/ONC transparency". Minor overlap risk remains because broad triggers such as "governance" and "model documentation" could also fire for non-OpenMed or general model-documentation skills, which keeps it below the minimal-conflict anchor.

4 / 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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

maziyarpanahi/openmed

Path

skills/authoring-model-cards/SKILL.md

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.