AGENT SKILL

treatment-plans

Format and structurally validate local treatment-plan documentation after clinical decisions have already been supplied and verified by authorized licensed professionals. Use for source traceability, clinician-authored intervention records, goals and checkpoints, shared-decision records, reconciliation handoffs, and release gates—not for clinical decision-making.

License 许可
MIT
最近更新
2026-11-14
Stars
★ 1.6k
Forks
491

01 前言 Front Matter

name
treatment-plans
license
MIT
metadata
{ "tags": "treatment plans, clinical documentation, medicine, healthcare", "version": "2.2", "category": "clinical-and-health", "maintainer": "Kalaris Labs" }
description
Format and structurally validate local treatment-plan documentation after clinical decisions have already been supplied and verified by authorized licensed professionals. Use for source traceability, clinician-authored intervention records, goals and checkpoints, shared-decision records, reconciliation handoffs, and release gates—not for clinical decision-making.
compatibility
Python 3.11+ standard library; local JSON files only. Bundled CLIs require no network, external services, models, images, credentials, environment variables, or third-party packages.

02 资源文件 22

03 SKILL.md 正文

Treatment-Plan Documentation

Hard safety boundary

This skill only formats and validates documentation of decisions already made, supplied, and verified by authorized licensed professionals.

Never use it to:

  • diagnose, assess, classify, or screen a person;
  • select, rank, recommend, substitute, or compare therapies;
  • choose a medication, dose, route, frequency, duration, or monitoring threshold;
  • start, stop, hold, resume, titrate, taper, or deprescribe anything;
  • check interactions, allergies, contraindications, organ-function suitability, or treatment eligibility;
  • infer missing clinical content, intervals, dates, targets, escalation criteria, or instructions;
  • triage, determine urgency, provide emergency advice, or create a safety plan;
  • predict outcomes, prognosis, response, benefit, harm, or clinical appropriateness;
  • replace medication reconciliation, pharmacist review, informed consent, clinician review, or an authorized clinical system;
  • claim FDA approval, HIPAA compliance, legal compliance, completeness of care, clinical safety, or standard-of-care conformity.

If a request crosses a boundary, stop. Ask for a locally verified clinician-authored record or route the matter to the responsible licensed professional. Do not redirect to another skill to obtain a patient-specific recommendation.

If a concern may be urgent or emergent, stop this workflow and route it through the institution's current clinical escalation or emergency process. This skill does not decide urgency and does not provide emergency instructions.

Required visible notice

Every component and derived schedule must display:

DRAFT — NOT MEDICAL ADVICE — DOCUMENTATION-ONLY — AUTHORIZED CLINICIAN SIGN-OFF REQUIRED

Structural success never removes this notice. Only the authorized local workflow may set the release gate.

Data gate

Prefer synthetic or qualified de-identified structured manifests. Do not place patient names, medical-record numbers, contact details, dates of birth, addresses, free-text notes, images, or other direct identifiers in examples.

For any real-patient or patient-derived data:

  1. Work only in a locally authorized environment under the institution's current privacy, security, retention, and access policies.
  2. Use the minimum information necessary for the documented purpose, even when a legal exception may apply.
  3. Do not send content to a model, search engine, API, image service, telemetry service, or any other external tool.
  4. Do not copy content into chat prompts, command history, logs, test fixtures, examples, screenshots, or reports.
  5. Run bundled scripts only against local paths. Their reports identify rule codes and field paths, not clinical values.
  6. Require qualified privacy review before treating patient-derived material as de-identified or releasing it.

If these conditions are not documented, do not read or process the content. Use synthetic templates only.

Allowed inputs

Accept only bounded UTF-8 JSON objects built from these generic templates:

  • assets/source_fact_manifest_template.json
  • assets/clinician_authored_intervention_template.json
  • assets/goals_monitoring_checkpoint_template.json
  • assets/informed_preference_shared_decision_template.json
  • assets/transition_reconciliation_template.json
  • assets/intended_use_handoff_template.json

The templates contain no disease-specific recommendations, example patients, clinical intervals, doses, targets, thresholds, or inferred care pathways. Empty template arrays and pending attestations are intentional release blockers.

Workflow

1. Establish authority and intended use

  • Confirm the accountable clinical owner and authorized licensed signatory.
  • Confirm that every clinical decision already exists in a verified local source.
  • Record jurisdiction, institution, setting, document owner, local policies, retention rule, and intended recipients.
  • Record whether the package is synthetic, qualified de-identified, or real-patient minimum-necessary data.
  • Keep the release gate blocked until every required review is complete.

Read references/safety_scope.md and references/privacy_governance.md before processing patient-derived material.

2. Generate a generic package

python3 scripts/generate_template.py \
  --output-dir ./local-plan-package \
  --subject-ref SYNTHETIC-CASE-001 \
  --classification synthetic

The generator copies all six templates. It does not create clinical content and does not overwrite existing files.

3. Transcribe supplied decisions without inference

  • Copy only clinician-authored facts and interventions from verified local sources.
  • Preserve source locators, versions/dates, author role, verification role, and verification time.
  • Record goals, monitoring items, checkpoint dates, and transition dates exactly as supplied.
  • Record options, benefits, harms, uncertainty, preferences, and the outcome only as documented by the responsible clinician.
  • Leave missing fields unresolved. Never fill them from general knowledge.
  • For medication content, record the clinician-authored text and current local source references; do not interpret or validate it.

See references/documentation_workflow.md, references/source_boundaries.md, and references/shared_decision_handoff.md.

4. Run deterministic local checks

From the skill directory:

python3 scripts/validate_treatment_plan.py ./local-plan-package
python3 scripts/validate_traceability.py ./local-plan-package
python3 scripts/check_completeness.py ./local-plan-package
python3 scripts/privacy_process_check.py ./local-plan-package
python3 scripts/check_consistency.py ./local-plan-package
python3 scripts/timeline_generator.py ./local-plan-package \
  --output ./local-plan-package/explicit-date-schedule.json

The scripts:

  • reject non-local paths, symlinks, duplicate JSON keys, unknown fields, oversized inputs, excessive nesting, and unbounded collections;
  • never use network access, environment variables, dynamic execution, pickle, subprocesses, images, or LLMs;
  • never assess diagnosis, medication safety, interactions, contraindications, clinical appropriateness, urgency, prognosis, or guideline concordance;
  • schedule only dates already supplied in the package and never derive recurrence or clinical intervals;
  • minimize reports to counts, rule codes, document types, and field paths.

5. Human review and release

Require the accountable authorized team to:

  • compare every transcribed item with its signed source;
  • perform medication reconciliation and all clinical checks in approved systems;
  • verify current FDA labeling, Medication Guide, REMS materials, and local formulary/policy when applicable;
  • resolve every discrepancy and missing item;
  • review shared-decision and informed-preference documentation;
  • review transition recipients, ownership, pending results, and local escalation routing;
  • complete privacy, security, legal, regulatory, records, and institutional review as applicable;
  • sign, date, and release through the authorized record system.

The final handoff must retain provenance and unresolved-item routing. A script pass is not authorization to use the package for care.

Source boundaries

  • Use FDA labeling databases, current Medication Guides, and REMS materials as authoritative source records only when an authorized clinician or pharmacist verifies applicability. This skill does not interpret them.
  • Use WHO or Joint Commission transition guidance only for process structure such as information transfer, reconciliation documentation, ownership, and checklists.
  • Use AHRQ, NICE, or applicable professional guidance to document that shared decision-making occurred; do not generate options or risk estimates.
  • Apply CMS documentation requirements only when the exact program, provider type, jurisdiction, and current local policy are confirmed.
  • Route safety events, product reports, privacy incidents, and other reportable matters through current local governance. This skill records a route; it does not submit reports.

See references/source_ledger.md for the dated official-source ledger.

Verification

PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover \
  -s tests/treatment-plans -p 'test_*.py' -v

Run AST parsing without bytecode:

PYTHONDONTWRITEBYTECODE=1 python3 -c \
  "import ast,pathlib; [ast.parse(p.read_text()) for p in pathlib.Path('scripts').glob('*.py')]"

Reference map

  • references/README.md — scope and navigation
  • references/safety_scope.md — refusal, routing, and release boundaries
  • references/privacy_governance.md — local handling and de-identification limits
  • references/documentation_workflow.md — package lifecycle and review gates
  • references/source_boundaries.md — FDA labeling, REMS, and governance boundaries
  • references/shared_decision_handoff.md — informed preferences, reconciliation, and transitions
  • references/source_ledger.md — dated authoritative sources
  • references/security_validation.md — baseline findings and validation record

Agent operating procedure

  1. Check the environment. Confirm data access permissions, de-identification status and the governing regulations or protocols.
  2. Pin down the inputs. Confirm formats, identifiers and parameters from the data or the user. Ask rather than guess any value that changes the result.
  3. Run a small version first. Work on a de-identified sample or synthetic data first.
  4. Execute the full task using the instructions and references above.
  5. Validate the result. Check outputs against clinical guidelines and reporting standards; have a qualified human review clinical content.
  6. Report. State what was run (versions, commands, parameters), what was checked, and what is still uncertain.
If this happens Do this
Data appears to contain identifiable patient information Stop and ask the user before processing further.
A function, flag or endpoint in these instructions is missing in the installed version Check the installed version's own documentation (help(), --help, official docs), adapt, and tell the user. Never invent an API.
A required input, identifier or parameter is ambiguous Ask the user, or state the assumption explicitly before running.

Integrity rules

  • Never fabricate results, parameters, identifiers, citations or statistics. If something cannot be run or verified, say so plainly.
  • Outputs are decision support for qualified professionals, not medical advice; never present them as diagnoses or orders.
  • Treat version-specific details here as possibly outdated: confirm them against the official documentation for the installed version.
  • Ask before actions that cost money, consume shared GPUs or cloud quota, touch personal or patient data, or cannot be undone.

Related skills

  • clinical-decision-support: Prepare and validate research-only clinical decision-support evaluation, evidence-profile, cohort, survival, biomarker/model, privacy, and…
  • ara-research-manager: Records research provenance at the end of a coding or research session by scanning the conversation and writing decisions, experiments, dea…

04 同仓库更多 Skills

hashgraph-online
hashgraph-online/awesome-codex-plugins

migrate-to-e2e

Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for /migrate-to-e2e, "migrate our tests to e2e", "port these Maestro flows", "move our TesterArmy tests", or when a project has an e2e config and an older suite still running.

★ 1.6k
hashgraph-online
hashgraph-online/awesome-codex-plugins

e2e

Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.

★ 1.6k
hashgraph-online
hashgraph-online/awesome-codex-plugins

create-verification-skill

Generate a project-local verify-<app> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for /create-verification-skill, "make a verification skill for this repo", or when a project has no scripted way to prove UI behavior.

★ 1.6k
hashgraph-online
hashgraph-online/awesome-codex-plugins

deja-search

deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.

★ 1.6k
hashgraph-online
hashgraph-online/awesome-codex-plugins

deja-reflect

End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.

★ 1.6k
hashgraph-online
hashgraph-online/awesome-codex-plugins

revid

Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.

图像与多媒体Skill与智能体开发
★ 1.6k