원클릭으로 Manus에서 모든 스킬 실행

spec-lookup

스타3

포크0

업데이트2026년 7월 17일 12:15

Finds and reads the authoritative openEHR spec text for a topic (an RM class, attribute, invariant, REST endpoint, AQL construct, data type, status-code rule, or CNF test case) in the vendored specs at docs/specs/openehr/. Use before implementing or reviewing any spec-facing behaviour, when a spec question comes up, or when the user asks "what does the spec say about X".

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

rubentalstra

rubentalstra/ehrbase-rs

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

/spec-lookup

Answer spec questions from the vendored normative text at docs/specs/openehr/ — never from memory. Every answer cites file + section.

Procedure

Route to the owning component(s) (map in docs/specs/openehr/README.md):
- RM classes / invariants / versioning semantics → RM/docs/ (ehr, common, data_types, data_structures, demographic, support)
- Primitives, ISO 8601, intervals, identifiers (OBJECT_VERSION_ID, …) → BASE/docs/
- REST endpoints, status codes, headers, representations → ITS-REST/ and SM/docs/openehr_platform/ (the abstract service model behind the REST API)
- AQL grammar/semantics/functions/result set → QUERY/docs/AQL/
- Archetypes, templates, OPT 1.4, ADL, AOM constraints → AM/docs/
- FLAT / STRUCTURED / SDT / web template → SM/docs/serial_data_formats/, SM/docs/simplified_im_b/
- Terminology code sets / term sets → TERM/docs/SupportTerminology/
- BMM / ODIN → LANG/docs/
- Canonical JSON schema shapes → ITS-JSON/components/
- Conformance expectations (what a CNF-conformant server must return) → CNF/docs/platform_test_schedule/master*.adoc + the executable Robot suites in CNF/tests/platform/robot/<API_GROUP>/
Grep the exact spec-cased name (e.g. DV_QUANTITY, preceding_version_uid, LATEST_VERSION) across the component's docs/**/*.adoc; specs use openEHR upper-snake class names. Try attribute names and section keywords if the class name is too noisy.
Read the surrounding section, not just the matching line: the class definition table, its invariants, inherited-class semantics (check the ancestor's section too), and any "business rules" prose near it.
Cross-check CNF whenever the topic is server behaviour: find the test case ids covering it and note the exact expected status codes/payloads.
Answer with citations: docs/specs/openehr/<component>/docs/<file>.adoc
- the section heading (and CNF test-case ids where applicable). If the spec is genuinely silent or ambiguous, say so explicitly — that is the signal to record a // NOTE: decision, with EHRbase consulted only as prior art.

이 저장소의 다른 Skills

같은 저장소

phase-done

rubentalstra/ehrbase-rs

Closes a tracker issue: verifies the work is genuinely done (exit criteria, gates, docs, changelog), writes the close narrative into the PR description, ensures the PR declares `Closes #N`, posts the handoff comment, and deletes the implemented plan file. Use when the user says a work item is complete or asks to close it out.

2026-07-263

run-conformance

rubentalstra/ehrbase-rs

Runs the CNF 2.0 conformance pipeline (scripts/conformance.sh) — the reference runner over the committed machine-readable catalogue and the acceptance instrument — against the Docker-composed server (or any BYO SUT). Use when the user asks to check conformance, run the conformance/CNF suite, verify spec compliance, or at phase close for the zero-drift gate.

2026-07-243

spec-audit

rubentalstra/ehrbase-rs

Audits an implemented subsystem, endpoint group, or diff against the vendored openEHR spec text and the CNF Platform Conformance Test Schedule (docs/specs/openehr/), producing a findings list of divergences with spec citations. Use when the user asks "are we following the spec", "audit X against the spec/CNF", before closing a spec-facing phase, or after a conformance failure.

2026-07-243

next-task

rubentalstra/ehrbase-rs

Reads the tracker (GitHub Issues), picks the pinned/top open issue (or the issue the user names), and restates it as a concrete in-session work plan naming the files and crates involved. Use when the user asks "what's next" or "what should I work on".

2026-07-243

phase-status

rubentalstra/ehrbase-rs

Prints the tracker's open issues (pinned first), any linked plan file's unchecked tasks, and a short git status. Use when the user asks "where are we", "what's in flight", or at the start of a work session to orient.

2026-07-243

crate-scaffold

rubentalstra/ehrbase-rs

Creates a new workspace crate directory (crates/, app/, or tools/) with a Cargo.toml wired to the workspace (inherited package fields, [lints] workspace = true, path deps per the docs/architecture.md dependency arrows), a doc-comment-only lib.rs/main.rs, and the crate's nested CLAUDE.md. Use when a plan calls for standing up a crate that does not exist yet.

2026-07-223

name	spec-lookup
description	Finds and reads the authoritative openEHR spec text for a topic (an RM class, attribute, invariant, REST endpoint, AQL construct, data type, status-code rule, or CNF test case) in the vendored specs at docs/specs/openehr/. Use before implementing or reviewing any spec-facing behaviour, when a spec question comes up, or when the user asks "what does the spec say about X".
allowed-tools	["Read","Grep","Glob","Bash"]
argument-hint	<class / attribute / endpoint / AQL construct / topic>

/spec-lookup

Answer spec questions from the vendored normative text at docs/specs/openehr/ — never from memory. Every answer cites file + section.

Procedure

Route to the owning component(s) (map in docs/specs/openehr/README.md):
- RM classes / invariants / versioning semantics → RM/docs/ (ehr, common, data_types, data_structures, demographic, support)
- Primitives, ISO 8601, intervals, identifiers (OBJECT_VERSION_ID, …) → BASE/docs/
- REST endpoints, status codes, headers, representations → ITS-REST/ and SM/docs/openehr_platform/ (the abstract service model behind the REST API)
- AQL grammar/semantics/functions/result set → QUERY/docs/AQL/
- Archetypes, templates, OPT 1.4, ADL, AOM constraints → AM/docs/
- FLAT / STRUCTURED / SDT / web template → SM/docs/serial_data_formats/, SM/docs/simplified_im_b/
- Terminology code sets / term sets → TERM/docs/SupportTerminology/
- BMM / ODIN → LANG/docs/
- Canonical JSON schema shapes → ITS-JSON/components/
- Conformance expectations (what a CNF-conformant server must return) → CNF/docs/platform_test_schedule/master*.adoc + the executable Robot suites in CNF/tests/platform/robot/<API_GROUP>/
Grep the exact spec-cased name (e.g. DV_QUANTITY, preceding_version_uid, LATEST_VERSION) across the component's docs/**/*.adoc; specs use openEHR upper-snake class names. Try attribute names and section keywords if the class name is too noisy.
Read the surrounding section, not just the matching line: the class definition table, its invariants, inherited-class semantics (check the ancestor's section too), and any "business rules" prose near it.
Cross-check CNF whenever the topic is server behaviour: find the test case ids covering it and note the exact expected status codes/payloads.
Answer with citations: docs/specs/openehr/<component>/docs/<file>.adoc
- the section heading (and CNF test-case ids where applicable). If the spec is genuinely silent or ambiguous, say so explicitly — that is the signal to record a // NOTE: decision, with EHRbase consulted only as prior art.