aidbox-hl7v2-example

Check recent HL7v2 processing errors in Aidbox, diagnose root causes, suggest fixes. Use when asked to check errors, diagnose failures, or troubleshoot message processing.

Look up FHIR R4 resource/datatype fields, types, cardinality, reference targets, and coded enums (including custom resources like IncomingHL7v2Message, OutgoingBarMessage). Use when writing converters or verifying FHIR compliance.

Build a new HL7v2→FHIR message converter or extend an existing one. Orchestrates requirements gathering, then delegates to `/plan` and `/work`.

Create a checkbox task plan for a feature or fix. Output is a markdown file that `/work` executes one task at a time.

Execute a plan produced by `/plan` — one task at a time, with tests and an independent review after each task.

Authenticate ad-hoc curl requests to the local Aidbox using the root Client secret from docker-compose.yaml. Use for debugging and one-off queries from the shell (not from app code — `src/aidbox.ts` already wraps auth).

Look up HL7v2 segment fields, datatypes, components, tables, and message structures. Use when writing converters, checking field positions/optionality, or verifying HL7v2 spec compliance.

Check whether an HL7v2 message is already supported by this pipeline (parse → preprocess → convert, prints verdict). Use before building a new converter, triaging "is this supported?", or verifying a parsing/conversion_error fix.

Review design or implementation of a feature or fix. Returns findings; never modifies files.

Verify the developer's machine has everything required to run this project (Bun, Docker, bash on Windows, free ports, .env). Use when the user asks to "set up", "check prerequisites", "what do I need installed", or is onboarding to the project.