health-init
Healthcare Project Context
When To Use
Invoke to bootstrap reusable project context for a healthcare repository. Use once per project, or when jurisdiction, audience, or project stage are unclear, so downstream healthcare skills (health-compliance-review, health-docs, health-product-discovery, health-refactor) don’t need to re-derive the same answers independently.
Overview
Healthcare skills repeatedly need the same project-level answers before they can give good guidance:
- Which regulatory market applies: US, EU, both, or unclear?
- Who does the product primarily serve: provider, patient, payer, administrative, mixed, or unknown?
- Is the target repository an existing system or a greenfield effort?
This skill answers those questions from repository evidence first, then persists the result in .health-context.yaml at the target repository root so future healthcare skills can reuse it instead of re-deriving it every time.
Do not force a confident classification from repo-shape alone. Sparse repos, scaffolds, and agent-tooling-only directories such as .agents/, .claude/, .codex/, or .gemini/ are weak evidence and usually mean one or more fields should remain unclear.
Workflow
More from reason-healthcare/health-skills
health-fhir-api-design
Design FHIR R4 API interactions — search queries, operations ($), validation, workflow patterns, and custom SearchParameter / OperationDefinition resources. The user provides requirements; the skill recommends a concrete R4 approach with trade-offs.
15health-docs
Audit and consolidate documentation for healthcare engineering systems. Supports two modes — analyze (coverage audit — writes only .health-docs/analysis.md) and document (consolidate existing docs + fill gaps). Detects applicable jurisdiction overlays and regulatory regimes from codebase signals, composes existing skills as subagents for deep-dimension analysis, and produces a structured handoff artifact consumed by document mode.
11health-product-discovery
Healthcare product discovery skill that maps incentive structures, adoption dynamics, and clinical workflow constraints before shaping solutions. Uses a jurisdiction-neutral core workflow plus explicit US and EU market overlays. Supports explore and document modes for early-stage ideation, consulting, pilot scoping, and strategic planning.
11health-human-factors
Review healthcare and EHR software interfaces against a comprehensive design style guide grounded in NIST, FDA, IEC 62366, ISO 9241, ISO 14971, WCAG 2.1, ONC SAFER, and HL7 FHIR standards. Produces a report-only assessment without modifying code or designs. Use when an agent needs to evaluate clinical UI screens, data display, forms, alerts, or workflows for patient-safety, usability, accessibility, and data-clarity compliance.
11health-refactor
Produce a scope-bounded, plan-only refactoring assessment for healthcare codebases. Resolves a bounded file set via git range, file area, or symbol/dependency context, proposes `us`, `eu`, or `us+eu` overlays from evidence, then orchestrates healthcare-aware refactoring, human-factors review, and regulatory review into a unified plan. Never modifies code.
10health-fhir-modeling
Map domain concepts to FHIR R4 resources and understand profile compliance. Select the right base resources, read US Core and QI Core profile constraints, model relationships, find existing extensions, and apply terminology bindings correctly. Outputs annotated example instances — not StructureDefinition or profile artifacts.
9