Skill-Details
health-init
Bootstraps regulatory and audience context for healthcare projects.
Vor Nutzung prüfen
Die automatische Prüfung bewertet Relevanz, nicht Sicherheit oder Empfehlung. Lies vor der Nutzung die Quellanweisungen.
SKILL.md
Dieser Auszug wurde bei der Prüfung gespeichert. Die externe Quelle enthält die vollständige und aktuelle Version.
--- name: health-init description: Bootstrap reusable healthcare project context from repository evidence. Use when an agent needs to determine jurisdiction, primary audience, or whether a target repo is greenfield or existing, then persist that context in .health-context.yaml for future skills. --- # 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 1. Read `.health-context.yaml` if it already exists. 2. Scan the repository for evidence, consulting the reference files as needed: - `references/jurisdiction-signals.md` — for jurisdiction evidence patterns - `references/audience-signals.md` — for primary audience evidence patterns - `references/stage-signals.md` — for project stage evidence patterns 3. Propose values for `jurisdiction`, `primary_audience`, and `project_stage`. 4. Record confidence and concrete evidence for each field. 5. Present the proposed values before writing: - if confidence is high and signals are clean, present the result for quick confirmation - if confidence is low or any field resolves to `unclear`, `mixed`, or `unknown`, call that out explicitly and invite correction 6. Write or update `.health-context.yaml` only after confirmation or override. 7. Reuse the stored context on later runs unless repository evidence or user input indicates it should change. ## Field Rules ### `jurisdiction` Allowed values: - `us` - `eu` - `us+eu` - `unclear` Use concrete repository evidence such as HIPAA, CMS, ONC, USCDI, US Core, NPI, Medicare, Medicaid, GDPR, EHDS, MDR, IVDR, NIS2, or AI Act references. If both US and EU evidence are materially present, use `us+eu`. Do not force a single-market answer when the repo clearly spans both. ### `primary_audience` Allowed values: - `provider` - `patient` - `payer` - `administrative` - `mixed` - `unknown` Infer audience from workflows, role names, UI copy, documentation, permissions, and integration language. If multiple audiences are first-class and no single one dominates, use `mixed`. If the repo does not reveal who the healthcare product serves, use `unknown` and ask the user to confirm or correct it before writing `.health-context.yaml`. ### `project_stage` Allowed values: - `greenfield` - `existing` - `unclear` Determine this from what is on disk, not from aspirational language. Application source, tests, CI, lockfiles, migrations, deployment config, and operational documentation usually indicate `existing` when they are tied to real product implementation. Template-only, proposal-only, spec-only, mostly empty repos, or repos that contain only agent-tooling / assistant-config directories usually indicate `greenfield` or `unclear`. Generic CI, skill hashes, prompt assets, or repo metadata alone are not enough for `existing`. ## Operating Rules - Never scaffold application code, infrastruVollständige Quelle auf GitHub lesen (öffnet externe Seite)