fhir-jira

fhir-jira-toolkit

A Claude Code marketplace containing the fhir-jira plugin — end-to-end tooling that takes HL7 FHIR JIRA tickets from "open" to "PR with green CI" across the base FHIR specification, the FHIR Extensions Pack, and FHIR Implementation Guides. Each spec lives in its own GitHub repository; the plugin auto-resolves which repo a ticket targets.

What you get

After installing the fhir-jira plugin from this marketplace:

Slash commands

• /fhir-jira FHIR-NNNN — single-ticket workflow. Auto-resolves whether the ticket is against HL7/fhir, HL7/fhir-extensions, or an IG, and operates in the right repo.
• /fhir-jira-batch <filter-id|FHIR-NNNN,FHIR-NNNN,...> — batch workflow. Groups tickets by target repo and produces one PR per repo touched, with one commit per ticket inside each.

Skill

• fhir-jira-workflow — the procedural body. Auto-triggers when you ask Claude to work on a FHIR JIRA ticket even outside the slash commands.

Helper scripts

• fetch_ticket.py — HL7 JIRA REST fetcher (no auth needed for public FHIR tickets), filter resolution, normalized summaries.
• resolve_repo.py — maps a ticket to its target GitHub repo via Specification field and Related URL patterns. Has a --group mode for batch resolution across repos.
• parse_qa.py — parses output/qa.json and computes a delta against a baseline. Exits non-zero on regression.
• format_messages.py — generates commit messages and PR bodies in the canonical format. Single-ticket and batch modes.

Config

• Default repo map ships with FHIR core, Extensions Pack, US Core, IPS, and Genomics Reporting.
• ~/.config/fhir-jira-toolkit/repo-map.json — user override (recommended for adding IGs and setting your clone root).
• ./repo-map.local.json — project-local override (highest priority).

See plugins/fhir-jira/skills/fhir-jira-workflow/references/repo-map.md for the schema and how to add IGs.

Installation

From GitHub (recommended)

In Claude Code:

/plugin marketplace add jdlnolen/fhir-jira-toolkit
/plugin install fhir-jira@fhir-jira-toolkit

Optionally override the default clone root if your HL7 repos aren't at ~/dev/hl7/:

mkdir -p ~/.config/fhir-jira-toolkit
echo '{"version": 1, "default_clone_root": "/your/path"}' \
  > ~/.config/fhir-jira-toolkit/repo-map.json

Then in a chat:

/fhir-jira FHIR-12345

From a local directory

If you prefer a local install (or are developing the plugin):

git clone https://github.com/jdlnolen/fhir-jira-toolkit.git ~/.claude/marketplaces/fhir-jira-toolkit

Then in Claude Code:

/plugin marketplace add ~/.claude/marketplaces/fhir-jira-toolkit
/plugin install fhir-jira@fhir-jira-toolkit

See INSTALL.md for the full step-by-step including prerequisites (git, gh, python3, IG Publisher) and per-repo QA baseline setup.

How it works

1. The skill calls fetch_ticket.py to pull the ticket JSON from JIRA.
2. resolve_repo.py matches the ticket's Specification field (or, as a fallback, the URLs in its Related URL and description) against the repo map to determine which repo to operate in.
3. Claude cds into that repo, syncs, branches, and reads the disposition.
4. Claude makes the edit. Non-trivial edits pause for user approval.
5. The IG Publisher runs locally; parse_qa.py confirms errors did not increase (per-repo baseline).
6. Claude writes the synopsis (only after the publisher passes).
7. format_messages.py produces the commit message and PR body.
8. Claude commits, pushes, opens the PR via gh, and watches CI.

For batch mode with tickets spanning multiple repos, this whole flow runs once per repo, and a final summary lists every PR opened.

HTML verification (optional)

After the publisher runs, the workflow can use the Playwright MCP plugin to render the published HTML and verify that the intended change actually appears in the output. This catches mechanical failures — wrong file edited, publisher caching issues, stale build — that the QA error-count check alone would miss.

How it works

1. On the first run per session, while still on the default branch with a fresh publisher build, the workflow captures baseline screenshots and accessibility snapshots of the page(s) referenced by the ticket.
2. After the edit and publisher re-run on the feature branch, it captures the current output of the same pages.
3. Claude compares the two, checking whether the ticket's intended change is visible and no visual regressions were introduced.
4. If the check fails, Claude stops and asks whether to fix or override.

Prerequisites

Install the Playwright plugin in Claude Code (it's a separate plugin from the official marketplace — fhir-jira does not install it automatically):

/plugin install playwright@claude-plugins-official

No other setup is needed.