AgentStack
SKILL verified Apache-2.0 Self-run

Class Generation

skill-openehr-ai-plugins-class-generation · by openEHR

>

No reviews yet
0 installs
8 views
0.0% view→install

Install

$ agentstack add skill-openehr-ai-plugins-class-generation

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Class Generation? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

openEHR Class Documentation Generation (BMM)

openEHR specification class documentation — the per-class definition tables and the UML class/package diagrams embedded in specifications-XX documents — is generated, not hand-written. The source of truth is the component's BMM (Basic Meta-Model) schema, serialised as PBMM JSON, and the generator is the bmm-publisher CLI tool.

> Replaces MagicDraw. Class tables and diagrams were historically extracted from MagicDraw > .mdzip UML models. That mechanism is retired; bmm-publisher is the current BMM-based generator.

Related Skills

  • authoring — document scaffolding and repo layout; explains where generated class docs are included
  • review — the ADOC-03 check enforces that class tables are generated, not hand-written
  • content-patterns — prose around classes (semantics, rationale) that the generated tables do not cover

For the full command, option, and schema reference, see references/bmm-publisher.md.

When to Regenerate

Regenerate class documentation when:

  • A component's BMM schema changes (new/renamed/removed classes, properties, functions, or types)
  • A spec needs its docs/UML/classes/ tables refreshed before a release
  • Class diagrams (SVGs) are stale relative to the model

Never hand-edit the generated output — change the BMM schema upstream and regenerate.

Installation

The tool is distributed as a Docker image that bundles all openEHR BMM schemas and the plantuml CLI. No local PHP, Composer, or checkout is required.

# Discover commands
docker run --rm ghcr.io/openehr/bmm-publisher list

For local development against a cloned bmm-publisher checkout, drive everything through its dev container (no host PHP): make install, make sh, make publish-all. See references/bmm-publisher.md.

Core Commands

| Command | Aliases | Produces | |---------|---------|----------| | asciidoc | adoc | AsciiDoc class/effective/definition tables and rendered SVG class/package diagrams (self-contained) | | legacy-adoc | | Flat per-class definition tables only, in the legacy docs/UML/classes layout (-o to target) | | plantuml | uml, puml | Standalone PlantUML .puml sources only | | embed-svg | | Re-run only the SVG sanitise + publish step | | yaml | | Machine-readable YAML serialisation of each schema | | split-json | | Per-type JSON files | | odin | | ODIN .bmm schema files (the hand-authored BMM format) |

Pass schema id(s) without the .bmm.json suffix (e.g. openehr_base_1.3.0), or all. Use repeatable -d for dependency schemas loaded for cross-references only (not exported), and -v/-vv for progress / detailed logging.

Output Layouts and How Specs Consume Them

bmm-publisher writes two layouts; pick the one the target component uses.

Legacy layout — docs/UML/classes/ (the include model)

legacy-adoc produces one .adoc table per class, named org.openehr....adoc (the class segment is lowercased, e.g. org.openehr.base.base_types.access_group_ref.adoc). These are placed in the component's docs/UML/classes/ directory and pulled into chapter files via the {uml_export_dir} attribute (which resolves to ../UML):

include::{uml_export_dir}/classes/{pkg}composition.adoc[]

This is the layout enforced by the review skill's ADOC-03 check.

Current layout — output/Adoc// (tables + rendered SVGs)

asciidoc produces classes/, effective/, definitions/, plantUML/, and rendered SVGs under images/uml/{classes,diagrams}/. Diagrams are referenced with Antora-style resource macros:

image::ROOT:uml/classes/COMPOSITION.svg[]

Typical Workflow

  1. Identify the schema for the component and version, e.g. openehr_base_1.3.0, openehr_rm_1.2.0

(naming pattern: openehr__).

  1. Generate into a working directory, mapping ownership to the host user:

``bash docker run --rm --user $(id -u):$(id -g) \ -v ./out:/app/output \ ghcr.io/openehr/bmm-publisher asciidoc -v openehr_rm_1.2.0 -d openehr_base_1.3.0 ``

  1. Place the generated classes/*.adoc into the component's docs/UML/classes/ (legacy layout)

or wire the output/Adoc// content per the component's current convention.

  1. Verify by publishing the spec (see the authoring skill) and confirming class tables and

diagrams render and cross-references resolve.

Guardrails

  • Generated output is never hand-edited. Fix the BMM schema and regenerate.
  • resources/*.bmm.json is upstream input — do not modify it unless the task is specifically to

change the model.

  • Provide cross-referenced dependency schemas with -d so type links resolve (e.g. RM depends on BASE).

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.