Skip to content
Get packs

Guide · Agent skill

How to use the Treatment-Plan Documentation Formatter skill

Updated · written with AI from the project's own documentation and checked against our catalogue data

The treatment-plans skill (skill name treatment-plans, from K-Dense-AI's scientific-agent-skills repository) lets an AI agent format and structurally check documentation of clinical decisions that authorized licensed professionals have already made and verified. It does not make clinical decisions. This guide explains what the skill does, how to install it, how to ask for it in plain language, what it needs, and the safety limits you must respect. After reading, you will be able to install the skill, run its template and validation workflow on synthetic data, and understand where clinician review is still required.

Treatment-Plan Documentation FormatterK-Dense-AI/scientific-agent-skills · MIT

Quick start

  1. 1Download and unzip. Download the skill ZIP from this page and unzip it to get the treatment-plans skill folder.
  2. 2Place the skill. Put the folder in ~/.claude/skills/ for personal use or in a project's .claude/skills/ folder, or upload the ZIP under Settings → Capabilities → Skills in the Claude apps.
  3. 3Confirm authority and intended use. Record the accountable clinical owner, authorized signatory, jurisdiction, setting and data classification before processing any content.
  4. 4Generate the template package. Run scripts/generate_template.py with an output directory, a subject reference and a classification, starting with synthetic data.
  5. 5Transcribe and run the checks. Copy only clinician-authored facts with their source references, then run the six local validation scripts against the package path.

What does the treatment-plans skill make the agent do?

The skill helps an agent organize and check records of decisions a clinician has already made. It provides six generic JSON templates, guides the agent to copy clinician-authored facts with their source references, and runs local scripts that check structure, traceability, completeness and privacy process.

Every output carries a draft notice: DRAFT, NOT MEDICAL ADVICE, DOCUMENTATION-ONLY, AUTHORIZED CLINICIAN SIGN-OFF REQUIRED. Passing the checks does not remove this notice, and only the authorized local workflow can set the release gate.

  • Generates a package of six JSON templates (source fact manifest, clinician-authored intervention, goals and monitoring checkpoints, informed preference and shared decision, transition reconciliation, and intended-use handoff).
  • Records source locators, versions or dates, author role, verification role and verification time for supplied facts.
  • Runs deterministic local checks and produces a schedule only from dates already supplied.
  • Does not diagnose, recommend therapies, choose doses, check interactions, triage or give clinical advice.

How do you install the treatment-plans skill?

Download the skill ZIP from this page and unzip it. Place the resulting skill folder in your personal skills directory, ~/.claude/skills/, or in a project's .claude/skills/ directory if you want the skill available only to that project.

If you use the Claude apps, you can instead upload the ZIP under Settings → Capabilities → Skills.

  • Personal install: unzip into ~/.claude/skills/.
  • Project install: unzip into the project's .claude/skills/ folder.
  • Claude apps: Settings → Capabilities → Skills, then upload the ZIP.
~/.claude/skills/

How do you trigger the skill with natural requests?

You do not need a special command. Describe the documentation task in plain language and name the kind of record you need. The skill's description covers source traceability, clinician-authored intervention records, goals and checkpoints, shared-decision records, reconciliation handoffs and release gates.

Be explicit that the decisions already exist. The skill is built to refuse requests that ask it to decide what a patient should receive.

  • Example: Create a synthetic treatment-plan package for case SYNTHETIC-CASE-001 with the generic templates.
  • Example: Transcribe the clinician-verified intervention below into the intervention template, keeping each source reference exactly as written.
  • Example: Check this package for traceability gaps and list the rule codes and field paths that fail.
  • Example: Format a shared-decision record that the responsible clinician has already documented.

How do you generate a template package and run the checks?

From the skill directory (skills/treatment-plans in this repository), generate a package with the generator. It copies all six templates into the output directory and does not overwrite existing files. The generator does not create clinical content.

Then copy only clinician-authored facts from verified local sources, leaving missing fields unresolved. Afterwards run the validation scripts against the local package path.

  • Use --classification synthetic for practice and tooling work.
  • Leave gaps unresolved rather than filling them from general knowledge.
  • Run all six checks: validate_treatment_plan.py, validate_traceability.py, check_completeness.py, privacy_process_check.py, check_consistency.py and timeline_generator.py.
python3 scripts/generate_template.py \ --output-dir ./local-plan-package \ --subject-ref SYNTHETIC-CASE-001 \ --classification synthetic

What do the validation scripts check and what do they not check?

The scripts reject URL or UNC path syntax, leaf symlinks, duplicate JSON keys, unknown fields, oversized inputs, excessive nesting and unbounded collections. They report counts, rule codes, document types and field paths rather than clinical values.

They cannot authenticate a signature, professional authority, completed review or source content. The completeness check always reports handoff_authorized_by_script as false, so a clean run is not an approval.

  • Date fields must use YYYY-MM-DD.
  • Timestamps must use YYYY-MM-DDTHH:MM:SS[.ffffff]Z or a numeric ±HH:MM offset.
  • Schedule dates keep the supplied local calendar date with no timezone conversion.
  • The scripts never assess diagnosis, medication safety, interactions, urgency, prognosis or guideline concordance.
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

What are the safety and privacy notes for scripts and network use?

The bundled scripts require Python 3.11+ and only the standard library. They use no network. The skill's compatibility notes say they need no external services, models, images, credentials, environment variables or third-party packages. The scripts have no network client, credential lookup, dynamic execution, pickle, subprocess, image or LLM processing.

Patient data is the main risk. Use synthetic or qualified de-identified data for examples. For any real or patient-derived data, work only in an authorized local environment under institutional privacy and security policy, and do not send content to a model, search engine, API or telemetry service. Passing a script does not establish de-identification or HIPAA compliance.

  • Do not paste patient names, record numbers, contact details, dates of birth, addresses or free-text notes into prompts or examples.
  • Run scripts only against local paths.
  • Get qualified privacy review before treating patient-derived material as de-identified or releasing it.
  • If a concern may be urgent, route it through your institution's clinical escalation process instead of this workflow.

What tips help you get reliable results?

Start with synthetic data until your team has agreed the workflow. Keep the release gate blocked until every required review is complete. Treat the schedule output with the same controls as its source package.

Read the reference files in the order the skill lists them, starting with safety_scope.md and privacy_governance.md, before you process any patient-derived material.

  • Keep empty template arrays and pending attestations as they are; they are intentional release blockers.
  • Record the intended use, authorized roles and local policies before transcribing decisions.
  • Do not relabel real data as synthetic.

What people use it for

  • Building and testing a local, synthetic-data tool that validates JSON treatment-plan templates before clinician review.
  • Checking that each clinician-authored intervention record carries complete source references and verification roles.
  • Preparing a shared-decision record and reconciliation handoff for a clinical documentation team to review.
  • Producing a schedule from explicit dates already present in a structurally consistent package.

Frequently asked questions

Is the treatment-plans skill free to use?

The skill is published under the MIT licence, as stated on this page and in its SKILL.md. Check the licence file in the downloaded package for the full terms before you redistribute it.

What do I need to run the treatment-plans skill?

You need Python 3.11 or later. The bundled scripts use only the standard library and require no network access, external services, credentials or third-party packages. The skill works with local JSON files.

Can I use the skill to get treatment advice for a patient?

No. The skill is designed to refuse clinical decisions. It will not recommend therapies, doses, urgency levels or interactions. It only formats and validates decisions that authorized licensed professionals have already made and verified.

Can I use real patient data with this skill?

Only in an authorized local environment under your institution's privacy, security and retention policies, and after qualified privacy review. The skill warns against sending patient-derived content to models or external tools. Use synthetic templates if these conditions are not documented.

Why does the completeness check say handoff_authorized_by_script is false?

The scripts cannot authorize a handoff. They check declared fields only and cannot verify a signature, professional authority, completed review or source content. Clinician sign-off through the authorized local workflow is still required.

Why does a validation script reject my package?

Common causes include URL or UNC path syntax, leaf symlinks, duplicate JSON keys, unknown fields, oversized inputs, excessive nesting, unbounded collections, and dates that are not in YYYY-MM-DD or timestamp format. The report lists rule codes and field paths so you can find the problem.

New agent skills, repos and AI tools — every week

The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.

Our verdict

Choose this skill if you are a clinical documentation or quality team working in an authorized local environment, or a developer building local, synthetic-data tooling that validates treatment-plan templates before clinician review. Pick something else if you are a patient or caregiver seeking treatment advice, or if you need a system that makes or checks clinical decisions, since this skill is built to refuse them.

Download the skill