serving-openmed-rest-api

Stand up OpenMed's FastAPI REST service for clinical NER, PII extraction, and de-identification, with health checks, model keep-alive/unload, optional dynamic batching, and no-PHI logging. Use when the user wants to serve OpenMed over HTTP, deploy a de-id/NER REST API, run an inference endpoint for clinical text, add a /analyze or /pii/deidentify route, or containerize OpenMed as a service. Covers the service extra, launching create_app with uvicorn, the real endpoints (/health, /analyze, /pii/extract, /pii/deidentify, /models/loaded, /models/unload), request/response shapes, ServiceRuntime env-var configuration, and self-hosted auth/CORS/TLS notes.

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Quality

Content

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

A tight, executable deployment skill with copy-paste commands, a clear sequenced workflow, and well-structured sections. Minor room to add health-check error-recovery guidance and to consider splitting the endpoint/env-var reference into bundle files.

Suggestions

Add an explicit feedback loop in the workflow for a failed /health check (e.g. inspect uvicorn logs, verify OPENMED_PROFILE / preload model names, restart) to push workflow clarity to the top anchor.

Consider moving the full endpoint request-field reference and env-var table into a references/ file (e.g. ENDPOINTS.md) referenced from SKILL.md, keeping the body as a concise overview.

The 'Covers the service extra, launching create_app with uvicorn, the real endpoints...' sentence in the description restates body content; trim it to reduce redundancy.

Dimension	Reasoning	Score
Conciseness	Dense, lean body that assumes Claude's competence — no explanation of what FastAPI/NER/PII are; endpoint and env-var tables and the Dockerfile earn every token without padding.	5 / 5
Actionability	Fully copy-paste-ready guidance throughout: pip install + uvicorn launch, create_app snippet, curl examples for every endpoint, an env-var launch line, and a complete Dockerfile covering the common deployment case.	5 / 5
Workflow Clarity	A clear six-step sequence with a health-check/warm verification step, but it lacks explicit error-recovery feedback loops (e.g. what to do when /health fails), keeping it just below the top anchor.	4 / 5
Progressive Disclosure	Well-organized into clearly headed sections with one-level-deep pointers to source files and external standards; no bundle files exist, and the inline endpoint/env-var reference tables are substantial enough that a larger version could warrant splitting, leaving a minor organization gap.	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.

A high-quality, third-person description that concretely states capabilities and gives explicit, varied 'Use when...' triggers with clear skill boundaries. The only minor gap is a few additional natural synonyms for the serving use case.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — 'clinical NER, PII extraction, and de-identification, with health checks, model keep-alive/unload, optional dynamic batching, and no-PHI logging' — giving comprehensive coverage of the service's capabilities.	5 / 5
Completeness	Explicitly answers both what ('Stand up OpenMed's FastAPI REST service for clinical NER, PII extraction, and de-identification...') and when ('Use when the user wants to serve OpenMed over HTTP, deploy a de-id/NER REST API...') with concrete trigger phrases.	5 / 5
Trigger Term Quality	Strong natural triggers ('serve OpenMed over HTTP', 'deploy a de-id/NER REST API', 'run an inference endpoint', 'add a /analyze or /pii/deidentify route', 'containerize OpenMed as a service') but a few common phrasings like 'REST API server' or 'web service' are absent, so it sits just below the comprehensive anchor.	4 / 5
Distinctiveness Conflict Risk	Occupies a clear niche (self-hosted OpenMed REST serving) with distinct triggers and explicit boundaries against the batch-processing and MCP skills, minimizing wrong-skill activation.	5 / 5
	Total	19 / 20 Passed

Validation

100%

Warnings & errors only

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/serving-openmed-rest-api/SKILL.md
Commit: 80da98c

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.