Clinical Trials Database
google-deepmind/science-skills
Query ClinicalTrials.gov via APIv2. An agent skill from google-deepmind/science-skills.
Validate FHIR R4 resources and Bundles against US Core / USCDI profiles with the official HL7 FHIR validator before submitting to an EHR.
Install Validating Us Core
$ npx skills add maziyarpanahi/openmed --skill validating-us-core -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install maziyarpanahi/openmed validating-us-core --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/maziyarpanahi/openmed.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/validating-us-core .claude/skills/validating-us-core && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "validating-us-core" agent skill from https://github.com/maziyarpanahi/openmed/tree/master/skills/validating-us-core into .claude/skills/validating-us-core/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "validating-us-core", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/maziyarpanahi/openmed/tree/master/skills/validating-us-coreType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add maziyarpanahi/openmed --skill validating-us-core -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install maziyarpanahi/openmed validating-us-core --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/maziyarpanahi/openmed.git skills-src && mkdir -p .agents/skills && cp -r skills-src/skills/validating-us-core .agents/skills/validating-us-core && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "validating-us-core" agent skill from https://github.com/maziyarpanahi/openmed/tree/master/skills/validating-us-core into .agents/skills/validating-us-core/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "validating-us-core", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add maziyarpanahi/openmed --skill validating-us-core -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install maziyarpanahi/openmed validating-us-core --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/maziyarpanahi/openmed.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/skills/validating-us-core .cursor/skills/validating-us-core && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "validating-us-core" agent skill from https://github.com/maziyarpanahi/openmed/tree/master/skills/validating-us-core into .cursor/skills/validating-us-core/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "validating-us-core", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/maziyarpanahi/openmed.git --path skills/validating-us-core--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add maziyarpanahi/openmed --skill validating-us-core -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install maziyarpanahi/openmed validating-us-core --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/maziyarpanahi/openmed.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/skills/validating-us-core .gemini/skills/validating-us-core && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "validating-us-core" agent skill from https://github.com/maziyarpanahi/openmed/tree/master/skills/validating-us-core into .gemini/skills/validating-us-core/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "validating-us-core", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install maziyarpanahi/openmed validating-us-coreInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add maziyarpanahi/openmed --skill validating-us-core -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/maziyarpanahi/openmed.git skills-src && mkdir -p .github/skills && cp -r skills-src/skills/validating-us-core .github/skills/validating-us-core && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "validating-us-core" agent skill from https://github.com/maziyarpanahi/openmed/tree/master/skills/validating-us-core into .github/skills/validating-us-core/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "validating-us-core", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add maziyarpanahi/openmed --skill validating-us-core -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install maziyarpanahi/openmed validating-us-core --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/maziyarpanahi/openmed.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/skills/validating-us-core .opencode/skills/validating-us-core && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "validating-us-core" agent skill from https://github.com/maziyarpanahi/openmed/tree/master/skills/validating-us-core into .opencode/skills/validating-us-core/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "validating-us-core", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
validating-us-core- GitHub stars
- 5.5k
- Token cost
- ~1.9k tokens
- SKILL.md length
- 746 words
- Files
- 1
- Skills in repo
- 74
- Repo updated
- First seen
- Licence
- Apache-2.0
At a glance
Validate FHIR R4 resources and Bundles against US Core / USCDI profiles with the official HL7 FHIR validator before submitting to an EHR.
- Works in 6 steps: Export + assemble the Bundle… → Add meta.profile for the US Core profile… → Run validator_cli.jar with -ig… → …
- Mentions US Core
- SKILL.md covers When to use, Quick start: run the official…, Declare the profile you claim and Common conformance gaps (from…, plus 4 more sections
- Calls java and curl; reaches tx.fhir.org and hl7.org
What it does
Validating Us Core is an agent skill from maziyarpanahi/openmed. Validate FHIR R4 resources and Bundles against US Core / USCDI profiles with the official HL7 FHIR validator before submitting to an EHR. Covers running validatorcli.jar (or the public validator.fhir.org), declaring meta.profile, must-support elements, common conformance gaps (missing code/category/status), and turning validator output into a FHIR OperationOutcome. Use after exporting-to-fhir / assembling-fhir-bundles to check OpenMed-produced FHIR for US Core conformance, when the user mentions US Core, USCDI…
Its SKILL.md is about 1.9k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Research & Science, covering Clinical and healthcare research. The repository describes itself as: Local-first healthcare AI: clinical NER & HIPAA PII de-identification that runs 100% on-device. 2,200+ medical models, 21 languages, Apple MLX + Python, no cloud, no patient data…. The licence is Apache-2.0.
When your agent uses it
- Mentions US Core
- Profile validation
- Epic/Cerner ingestion requirements
Example prompts
- “/validating-us-core”
Requirements
- Python 3
Workflow steps
6 steps, taken from the first numbered list in SKILL.md.
- Export + assemble the Bundle (exporting-to-fhir, assembling-fhir-bundles).
- Add meta.profile for the US Core profile each resource targets.
- Run validator_cli.jar with -ig hl7.fhir.us.core and a -tx server.
- Read the issues: error = will be rejected; warning = must-support /
- Re-validate until clean; wire the validator into CI on synthetic fixtures.
- Submit (assembling-fhir-bundles for the transaction POST).
What it can do on your machine
Read from SKILL.md and the folder at commit ea920f3. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
javacurl
From the folder's file list and the shell code blocks in SKILL.md.
Network
Hosts in commands or code, which the agent is likely to contact:
tx.fhir.orghl7.orgunitsofmeasure.orggithub.com
Also links to:
validator.fhir.orghealthit.govconfluence.hl7.org
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Validating Us Core loads about 1.9k tokens when it runs. Until then it costs about 156 tokens; SKILL.md has 746 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from maziyarpanahi/openmed at commit ea920f3, republished under its Apache-2.0 licence (© maziyarpanahi). 746 words, ~1,899 tokens.
Download SKILL.mdSave it as
.claude/skills/validating-us-core/SKILL.md (or your agent's skills folder).- name
- validating-us-core
- description
- Validate FHIR R4 resources and Bundles against US Core / USCDI profiles with the official HL7 FHIR validator before submitting to an EHR. Covers running validator_cli.jar (or the public validator.fhir.org), declaring meta.profile, must-support elements, common conformance gaps (missing code/category/status), and turning validator output into a FHIR OperationOutcome. Use after exporting-to-fhir / assembling-fhir-bundles to check OpenMed-produced FHIR for US Core conformance, when the user mentions US Core, USCDI, must-support, profile validation, or Epic/Cerner ingestion requirements. Pairs after.
- license
- Apache-2.0
- metadata.project
- OpenMed
- metadata.category
- fhir-interop
- metadata.pairs
- after
- metadata.version
- 1.0
Validating US Core
Producing syntactically valid R4 (which exporting-to-fhir and
assembling-fhir-bundles do) is not the same as conforming to US Core — the
HL7 US realm profiles that EHRs (Epic, Cerner/Oracle Health) require for
ingestion and that USCDI mandates for certified exchange. This skill validates
OpenMed-produced FHIR against US Core before you submit it.
When to use
Use it as the gate right before submission, after you have assembled a Bundle. Reach for it when the user says "US Core", "USCDI", "must-support", "will Epic accept this", or "validate my FHIR". It is the conformance counterpart to the mechanical builders — OpenMed builds the JSON; the HL7 validator judges it.
Quick start: run the official validator
The reference implementation is the HL7 validator_cli.jar (the same engine
behind https://validator.fhir.org). Validate against the US Core package by IG:
# One-time: get the validator
curl -L -o validator_cli.jar \
https://github.com/hapifhir/org.hl7.fhir.core/releases/latest/download/validator_cli.jar
# Validate a resource/Bundle against the current US Core IG
java -jar validator_cli.jar condition.json \
-version 4.0.1 \
-ig hl7.fhir.us.core \
-tx https://tx.fhir.org # terminology server for code validation-ig hl7.fhir.us.core pulls the current published US Core package; pin a
version (e.g. -ig hl7.fhir.us.core#6.1.0) for reproducible CI. The validator
exits non-zero on errors and prints issues with FHIRPath locations.
For ad-hoc checks without a JVM, paste the JSON into the public validator UI at https://validator.fhir.org (do not paste real PHI — validate synthetic or de-identified resources only).
Declare the profile you claim
US Core only validates against a profile if the resource claims it via
meta.profile. Add the canonical URL for the profile you target:
{
"resourceType": "Condition",
"meta": {
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-condition-problems-health-concerns"
]
}
}Then java -jar validator_cli.jar condition.json -ig hl7.fhir.us.core checks it
against that profile's constraints, including must-support elements.
Common conformance gaps (from OpenMed output)
OpenMed NER gives you the clinical mention; US Core wants structured context. The recurring gaps when going from raw spans to US Core:
| Gap | US Core expects | Fix in the exporter |
|---|---|---|
Missing code.coding | A coded value (SNOMED/ICD-10 for Condition; LOINC for Observation; RxNorm for medication) | Ground the span; codeable_concept([...]) with a real coding, not just text |
Missing category | encounter-diagnosis/problem-list-item (Condition), laboratory/vital-signs (Observation) | Set category in the resource shell |
Missing clinicalStatus / status | Required status fields | Set them per the exporting-to-fhir cheat-sheet |
Missing subject | A resolvable Patient reference | Reference an in-Bundle Patient; let to_bundle rewrite it |
Unbound valueQuantity.code | UCUM unit code | Use system: http://unitsofmeasure.org + UCUM code |
| Vital signs not on the vitals profile | us-core-vital-signs shape (LOINC code, vital-signs category) | Use the vitals LOINC + category |
"Must-support" means the producer must populate the element when the data exists. The validator flags must-support omissions as warnings; certified systems may reject them.
Workflow
- Export + assemble the Bundle (
exporting-to-fhir,assembling-fhir-bundles). - Add
meta.profilefor the US Core profile each resource targets. - Run
validator_cli.jarwith-ig hl7.fhir.us.coreand a-txserver. - Read the issues: error = will be rejected; warning = must-support / best practice. Fix errors in the exporter, not by hand-editing JSON.
- Re-validate until clean; wire the validator into CI on synthetic fixtures.
- Submit (
assembling-fhir-bundlesfor the transaction POST).
Show full SKILL.md (291 more words)Show less
Turn validator output into an OperationOutcome
If you run validation programmatically, adapt the result into a FHIR
OperationOutcome with OpenMed's helper so the rest of your pipeline speaks one
shape:
from openmed.clinical.exporters.fhir import from_validation_result
# `result` exposes issues, or errors/warnings/information buckets
outcome = from_validation_result(result) # -> R4 OperationOutcome dictfrom_validation_result understands either an issues collection or
errors/warnings/information buckets (strings or issue objects) and emits a
clean R4 OperationOutcome (all-ok when empty). It only reads structural
metadata — keep diagnostics PHI-free.
Hand-off to / from OpenMed
- Validate OpenMed-produced FHIR: the input is the Bundle from
assembling-fhir-bundles; the output is conformance issues you fix back inexporting-to-fhir. - OperationOutcome bridge:
from_validation_result/to_operation_outcome/OperationOutcomeIssue(all inopenmed.clinical.exporters.fhir) convert validator findings to R4. - No PHI in validation: validate synthetic or de-identified resources. If a
narrative might carry PHI, run
openmed.interop.fhir_operations.de_identify_bundlefirst.
Edge cases & gotchas
- No
meta.profile, no profile check. The validator validates base R4 only unless the resource claims the profile (or you force it with-profile <url>). - Terminology binding needs a
-txserver. Without-tx, code-system / value-set bindings are not fully checked; many US Corerequiredbindings will be missed. Point-txathttps://tx.fhir.orgor your own Ontoserver. - Pin the IG version in CI (
hl7.fhir.us.core#<version>). US Core revisions change must-support and bindings; an unpinned run drifts. - Reference resolution in Bundles. Validate the whole Bundle so
urn:uuidreferences resolve; validating a lone resource flags references it cannot see. - USCDI ≠ US Core. USCDI is the data-element regulation; US Core is the FHIR profile set that implements it. Conform to the US Core profile for the matching USCDI class.
- Warnings can still block ingestion. Some EHRs reject must-support omissions even though the validator calls them warnings. Treat must-support as required for production.
Standards & references
- US Core Implementation Guide: https://hl7.org/fhir/us/core/
- US Core profiles list: https://hl7.org/fhir/us/core/profiles-and-extensions.html
- USCDI: https://www.healthit.gov/isp/united-states-core-data-interoperability-uscdi
- HL7 FHIR validator (CLI + docs): https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator
- Public validator: https://validator.fhir.org
- Public terminology server: https://tx.fhir.org
© maziyarpanahi, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
Just SKILL.md in skills/validating-us-core of maziyarpanahi/openmed.
Open the folder on GitHubat commit ea920f3
Compare with similar skills
Validating Us Core next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Validating Us Core this skillmaziyarpanahi/openmed | 5.5k | — | ~1.9k | Automated safety check: Pass | Apache-2.0 | |
| Clinical Trials Databasegoogle-deepmind/science-skills | 3.2k | 3 repos | ~3.2k | Automated safety check: Pass | Apache-2.0 | |
| CHARLS Paper Reproduction Guidexjtulyc/MedgeClaw | 617 | 1 repos | ~1.8k | Automated safety check: Pass | None | |
| Model AssessmentAperivue/medsci-skills | 329 | 1 repos | ~4.5k | Automated safety check: Pass | MIT | |
| Biomedical Analysis Dispatchxjtulyc/MedgeClaw | 617 | 1 repos | ~2k | Automated safety check: Pass | None | |
| Research Proposalluwill/research-skills | 858 | — | ~4.4k | Automated safety check: Notes | None |
Similar skills
CHARLS Paper Reproduction Guide
xjtulyc/MedgeClaw
Guides an agent through reproducing papers built on the CHARLS health and retirement survey, from variable mapping to cognition, depression and isolation scores.
Model Assessment
Aperivue/medsci-skills
A skill your agent uses when validating or evaluating a trained medical-imaging model.
Biomedical Analysis Dispatch
xjtulyc/MedgeClaw
Routes bioinformatics, drug discovery, clinical and multi-omics tasks from a chat interface to Claude Code sessions running K-Dense scientific skills, with a live dashboard per task.
Research Proposal
luwill/research-skills
A skill your agent uses when the user asks to write or draft a PhD / doctoral research proposal, research plan, 研究计划书, or 开题报告 — a forward-looking plan of background, gap, research questions…
Medical Imaging Review
LeonChaoX/qinyan-academic-skills
Write comprehensive literature reviews for medical imaging AI research.
More from maziyarpanahi/openmed
All 74 skills in this repoHIPAA Safe Harbor Coverage Audit
maziyarpanahi/openmed
Checks OpenMed de-identified clinical text against the 18 HIPAA Safe Harbor identifier categories and reports gaps and residual re-identification risk.
OpenMed Model Card Writer
maziyarpanahi/openmed
Fills in a model card for an OpenMed clinical NER or de-identification model from its evaluation reports: intended use, metrics, subgroups and limitations.
HIPAA Pre-Deployment Compliance Check
maziyarpanahi/openmed
Walks a data pipeline against the HIPAA Privacy and Security Rule checklist and produces a gap report before it processes patient data.
ICD-10 Coding Assistant
maziyarpanahi/openmed
Suggests candidate ICD-10-CM diagnosis and ICD-10-PCS procedure codes for clinical text extracted by OpenMed, with rationale for a certified coder to review.
OpenMed ETL to OMOP CDM
maziyarpanahi/openmed
Maps OpenMed-extracted, terminology-coded conditions, drugs and measurements into OMOP CDM v5.4 tables for OHDSI and ATLAS analytics.
Extracting SDOH and Z-Codes
maziyarpanahi/openmed
Finds social risks such as housing instability or food insecurity in clinical notes and proposes matching ICD-10-CM Z-codes for a coder to confirm.
Related
Categories
Questions about Validating Us Core
What does Validating Us Core do?
Validate FHIR R4 resources and Bundles against US Core / USCDI profiles with the official HL7 FHIR validator before submitting to an EHR. Validating Us Core is an agent skill from maziyarpanahi/openmed. Validate FHIR R4 resources and Bundles against US Core / USCDI profiles with the official HL7 FHIR validator before submitting to an EHR.
When should I use Validating Us Core?
Validating Us Core fits situations like: mentions US Core; profile validation; epic/Cerner ingestion requirements.
How do I install Validating Us Core in Claude Code?
Run `npx skills add maziyarpanahi/openmed --skill validating-us-core -a claude-code`. Or copy the skill folder (skills/validating-us-core in maziyarpanahi/openmed) into .claude/skills/validating-us-core in your project. Claude Code loads it when a task matches its description.
How do I install Validating Us Core in Codex?
Run `npx skills add maziyarpanahi/openmed --skill validating-us-core -a codex`. Or copy the skill folder (skills/validating-us-core in maziyarpanahi/openmed) into .agents/skills/validating-us-core in your project. Codex loads it when a task matches its description.
Can I use Validating Us Core in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add maziyarpanahi/openmed --skill validating-us-core -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/validating-us-core, .gemini/skills/validating-us-core, .github/skills/validating-us-core and .opencode/skills/validating-us-core in your project.
What does Validating Us Core need to run?
Going by SKILL.md and its folder, Validating Us Core needs the command-line tools its instructions call (java and curl). Our summary lists: Python 3.
Does Validating Us Core access the network?
SKILL.md names 7 domains. In commands or code: tx.fhir.org, hl7.org, unitsofmeasure.org and github.com; the agent is likely to contact these when it follows the instructions. As links in the text: validator.fhir.org, healthit.gov and confluence.hl7.org. This is read from the text; nothing was executed.
Is Validating Us Core safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Validating Us Core use?
Validating Us Core is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Validating Us Core use?
About 1.9k tokens (SKILL.md is roughly 7.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Validating Us Core?
Skills that share tags, products or a category with Validating Us Core: Clinical Trials Database (google-deepmind/science-skills, 3.2k stars), CHARLS Paper Reproduction Guide (xjtulyc/MedgeClaw, 617 stars), Model Assessment (Aperivue/medsci-skills, 329 stars) and Biomedical Analysis Dispatch (xjtulyc/MedgeClaw, 617 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Validating Us Core?
maziyarpanahi (a GitHub user) maintains it in maziyarpanahi/openmed, which has 5,457 GitHub stars. The repository holds 74 skills in this directory. The repository was last updated on October 7, 2026.
Source: maziyarpanahi/openmed on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.