How do I install the Fhir CI Quality skill?

Run npx skillmds@latest add sigistry/fhir-ci-quality in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Fhir CI Quality safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Fhir CI Quality?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Fhir CI Quality free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Fhir CI Quality?

sigistry (@sigistry) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Fhir CI Quality by sigistry — Agent Skill

Name: Fhir CI Quality
Author: sigistry

Fhir CI Quality

Generate or review FHIR validator CI workflows and derive candidate healthcare data-quality rules from local FHIR examples. Use when the user asks to add FHIR validation to GitHub Actions or another CI/CD system, create conformance quality gates, infer project conventions, or turn recurring validation expectations into reviewed automation.

sigistry Updated Sep 17, 2026

File contents

FHIR CI and Quality

Create repeatable checks without turning observed sample data into unreviewed clinical policy.

Bundled paths

Resolve <skill-root> to the directory containing this SKILL.md and <plugin-root> two directories above it. Shared deterministic tools live under <plugin-root>/skills/fhir-validation/scripts. Never resolve them relative to the user's workspace.

Workflow

Inspect the existing project scripts, package files, generated-artifact policy, and CI conventions.
Diagnose runtime/package readiness with $fhir-project-doctor before generating a workflow when the runtime is unclear.

Derive candidate rules and generate a starting workflow:

node "<plugin-root>/skills/fhir-validation/scripts/derive-quality-rules.mjs" <resource-directory>
node "<plugin-root>/skills/fhir-validation/scripts/generate-ci.mjs" --json --dir <resource-directory>

Review every inferred rule. Treat identifiers, code systems, profiles, cardinalities, and status values as domain policy unless directly required by a loaded FHIR profile. Write only artifact.content from the CI generator to the proposed workflow path.
Pin third-party CI dependencies, use least-privilege permissions, avoid printing full resources, and keep hosted/API validation behind explicit privacy approval.
Validate the workflow syntax and run the local validation command before handing it back.

Modes

Use local Records CLI by default.
Add --sushi when the repository owns FSH and must rebuild generated resources.
Add --api only when the user approves hosted validation and CI secrets are already in scope.
Add --upload-artifact only for redacted or non-PHI reports.

Output

Report runtime assumptions, privacy boundary, reviewed versus rejected candidate rules, changed CI files, and the exact local verification performed. Preserve the tools' contract and never describe inferred rules as authoritative without review.

---name: fhir-ci-qualitydescription: Generate or review FHIR validator CI workflows and derive candidate healthcare data-quality rules from local FHIR examples. Use when the user asks to add FHIR validation to GitHub Actions or another CI/CD system, create conformance quality gates, infer project conventions, or turn recurring validation expectations into reviewed automation.---# FHIR CI and QualityCreate repeatable checks without turning observed sample data into unreviewed clinical policy.## Bundled pathsResolve `<skill-root>` to the directory containing this `SKILL.md` and `<plugin-root>` two directories above it. Shared deterministic tools live under `<plugin-root>/skills/fhir-validation/scripts`. Never resolve them relative to the user's workspace.## Workflow1. Inspect the existing project scripts, package files, generated-artifact policy, and CI conventions.2. Diagnose runtime/package readiness with `$fhir-project-doctor` before generating a workflow when the runtime is unclear.3. Derive candidate rules and generate a starting workflow: ```bash node "<plugin-root>/skills/fhir-validation/scripts/derive-quality-rules.mjs" <resource-directory> node "<plugin-root>/skills/fhir-validation/scripts/generate-ci.mjs" --json --dir <resource-directory> ```4. Review every inferred rule. Treat identifiers, code systems, profiles, cardinalities, and status values as domain policy unless directly required by a loaded FHIR profile. Write only `artifact.content` from the CI generator to the proposed workflow path.5. Pin third-party CI dependencies, use least-privilege permissions, avoid printing full resources, and keep hosted/API validation behind explicit privacy approval.6. Validate the workflow syntax and run the local validation command before handing it back.## Modes- Use local Records CLI by default.- Add `--sushi` when the repository owns FSH and must rebuild generated resources.- Add `--api` only when the user approves hosted validation and CI secrets are already in scope.- Add `--upload-artifact` only for redacted or non-PHI reports.## OutputReport runtime assumptions, privacy boundary, reviewed versus rejected candidate rules, changed CI files, and the exact local verification performed. Preserve the tools' contract and never describe inferred rules as authoritative without review.

Frequently asked questions