content-patterns — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited content-patterns (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill captures the recurring prose patterns found across all openEHR specification documents in the specifications-XX repositories (RM, AM, BASE, LANG, PROC, SM, QUERY, CNF, TERM, ITS-*), derived from the existing library and its shared infrastructure in specifications-AA_GLOBAL. Apply them when writing new chapters or sections to match the quality and consistency of the existing specification library. They do not apply to non-openEHR specifications or general technical documentation.
references/prose-patterns.md for the full structure,AsciiDoc template, real example, and conventions for each pattern indexed below.
../authoring/references/cross-references.md forhow to find and use {openehr_*} attributes when writing cross-references in spec prose.
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-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 | Only reference names from the published RM/AM/BASE |
| Explaining every attribute of a class in prose | Class definition tables are auto-generated; 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 |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.