Skip to content
Back to skills

Content Patterns

ASecurity

Patterns for writing openEHR specification prose (package overviews, class/concept semantics, design rationale, clinical examples, requirements sections, deprecated/TBD markers, and figure introductions) in `specifications-XX` repos. This skill should be used when the user asks how to phrase, draft, or improve spec prose, or about openEHR spec writing style. Not for document structure (use authoring), convention checks (use review), amendment records (use amendment-record), ITS-REST descripti...

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 9, 2026
ai-agents

Works with

  • cli

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned October 9, 2026

npx -y skills add openEHR/ai-plugins --skill content-patterns --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Content Patterns?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Content Patterns
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/openehr-content-patterns/badge)](https://www.skillsdirectory.com/skills/openehr-content-patterns)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: content-patterns
description: >
  Patterns for writing openEHR specification prose (package overviews, class/concept semantics,
  design rationale, clinical examples, requirements sections, deprecated/TBD markers, and figure
  introductions) in `specifications-XX` repos. This skill should be used when the user asks how to
  phrase, draft, or improve spec prose, or about openEHR spec writing style. Not for document
  structure (use authoring), convention checks (use review), amendment records (use
  amendment-record), ITS-REST descriptions (use its-rest), or non-openEHR writing.
---

# openEHR Specification Content Patterns

Apply these recurring prose patterns when writing new chapters or sections, to match the quality
and consistency of the existing specification library. They are derived from the openEHR
specification documents in the `specifications-XX` repositories (RM, AM, BASE, LANG, PROC, SM,
QUERY, CNF, TERM, ITS-*) and the shared infrastructure in `specifications-AA_GLOBAL`.

## References

- **Prose pattern catalog**: see `references/prose-patterns.md` for the full structure,
  AsciiDoc template, real example, and conventions for each pattern indexed below.
- **Cross-reference attribute guide**: see `../authoring/references/cross-references.md` for
  how to find and use `{openehr_*}` attributes when writing cross-references in spec prose.
- **Admonitions, code blocks, tables**: see `../authoring/references/asciidoc-syntax.md` for the
  syntax of a note, a code example, or a table in a chapter.

## General Principles

- **Formal register**: third person, present tense, no contractions, no hedging.
- **Declarative facts first**: lead with what the model defines, not how the reader should interpret it.
- **Design rationale where non-obvious**: explain why, not just what.
- **Ground every claim**: reference RM classes, archetype paths, or external standards. Never invent identifiers; after drafting, dispatch the `identifier-grounding` subagent to verify each class, attribute, and function name against the published specifications.
- **Clinical examples**: use concrete clinical scenarios to illustrate abstract model concepts.

## Pattern Catalog

Pick the pattern that matches the section being written and read its detailed entry in
**`references/prose-patterns.md`**.

| # | Pattern | Use when writing… |
|---|---------|-------------------|
| 1 | Package/Chapter Overview | the opening of a chapter that describes a model package (opening paragraph → UML diagram → package/class enumeration) |
| 2 | Class/Concept Semantics | the prose for a class or major concept (purpose, typing, identification, structure, lifecycle, relationships) |
| 3 | Design Rationale | an explanation of *why* a non-obvious design choice was made (problem/requirement → chosen design → rejected alternatives) |
| 4 | Clinical/Practical Examples | a concrete clinical scenario that grounds an abstract model concept |
| 5 | Requirements Sections | an explicit numbered-requirements section preceding a design (common in Data Types, EHR IM) |
| 6 | Deprecated and TBD Markers | `[.deprecated]` or `[.tbd]` annotations for legacy or pending content |
| 7 | Figures and Diagrams in Context | any diagram — always introduced by text and followed by explanation |

## Anti-Patterns to Avoid

| Anti-Pattern | Correct Approach |
|-------------|-----------------|
| "This section describes..." | State what the package/class defines directly |
| "We decided to..." | "The design uses..." / "The approach taken is..." |
| Passive hedging ("it might be...") | Declarative statements ("it is..." / "this enables...") |
| Inventing class or attribute names | Reference only names found in the published RM/AM/BASE (see "Ground every claim" above) |
| Explaining every attribute of a class in prose | Class definition tables are generated (see `class-generation`); prose covers semantics and rationale |
| Orphan figures (no intro or follow-up text) | Always introduce and explain diagrams |
| Hardcoded URLs | Use `{openehr_*}` attributes from reference_definitions.adoc |

Files in this skill

  • SKILL.md4 KB
  • references/prose-patterns.md8.6 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.